iOS-разработка становится сложнее — обсуждение на Reddit

Интересная точка зрения. Для контекста, я занимаюсь разработкой iOS, исключительно SwiftUI. Сегодня мне кажется, что все проще, чем когда-либо раньше. Я чувствую, что могу двигаться намного быстрее с сегодняшними фреймворками, и код намного чище. (Особенно использование async/await вместо делегатов. Continuation — это необходимое зло для перехода от одного к другому).

Некоторые части вашего вопроса действительно находят отклик — мне кажется, что Xcode становится хуже. Отладчик очень медленный и ненадежный. Возникают фантомные ошибки. Он очень плохо работает с пакетами Swift, несмотря на то, что это собственное решение Apple. Мне регулярно приходится жертвовать простотой, чтобы заставить его разрешить все мои версии пакетов.

Кроме того, некоторые вещи сейчас очень непрозрачны. Лучшие практики использования параллелизма в Swift мне неизвестны (таски, приоритеты, MainActor vs not и т.д.) Я просмотрел все видео с WWDC, но, как вы и сказали, там полный бардак. Apple не дает реальных примеров, например, сетевых вызовов во ViewModel.

Я также настоятельно рекомендую PointFree.

Я думаю, что они делают все «проще» для начинающих разработчиков, но когда что-то идет не так или что-то не поддерживается, это усложняет ситуацию, поскольку появляется дополнительный уровень абстракции. Для меня Combine и SwiftUI оба кажутся очень сладкими, но я видел много проблем с ними. Даже на форумах разработчиков Apple люди жалуются на них.

Это зависит от того, что вы считаете трудным. В любом случае, когда вы пытаетесь выучить новый язык, который заменяет тот, с которым вам было комфортно работать, это может стать препятствием.

Однако для меня работа с необработанными данными была мучением в Swift, в основном с заменой байтов, упаковкой данных и т.д. Невозможность обернуть структуру в bytes(), как в Python, — это боль, а также некоторые математические функции, например, невозможность возвести в квадрат просто ‘**‘.

Структурированный параллелизм поначалу пугал, но я обнаружил, что можно создавать обычные функции, не прибегая к try/await. Как только вы столкнетесь с первым «мне нужно, чтобы эта функция ждала такого-то ответа от API», тогда все станет понятно. В Swiftful Thinking есть замечательные видеоролики с объяснениями. Просто погрузитесь и проследите за тем, что он делает на игровой площадке, и у вас все получится.

Будучи знакомым и с UIKit, и с SwiftUI, скажу, что SwiftUI значительно упрощает создание быстрых интерактивных пользовательских интерфейсов, как только вы преодолеете обёртки свойств и синтаксис. Проблемы, с которыми я сталкиваюсь, — это редкие и болезненные ситуации, когда SwiftUI не делает того, что должен, или того, что вам нужно.

SwiftData все еще немного нова, поэтому я обычно даю Apple год или два, прежде чем использовать то, что у них есть. Realm — моя любимая библиотека данных, и она работает очень хорошо.

Я думаю, что в SwiftUI очень легко запутаться. Просто делайте по одному шагу за раз. Посмотрите одно видео о том, чего вы не понимаете, попробуйте это на игровой площадке и продолжайте. Каждый день я продолжаю узнавать что-то новое о Swift и о том, как это реализовать.

Нет. Структурированный параллелизм гораздо чище и проще, чем альтернативы, которые вы могли использовать раньше, такие как блоки диспетчеризации или очереди операций.

Серьезно, сделайте шаг назад и посмотрите на типичное приложение, написанное с использованием libdispatch и колбеков — это запутанный беспорядок. Только потому, что вы знакомы с таким подходом, он кажется нормальным, но после использования async/await вы поймете, что у вас стокгольмский синдром.

Combine сложен, но я думаю, что его можно рассматривать как деталь реализации и в основном игнорировать. Как технология для создания приложений она кажется в лучшем случае тупиковой причудой или уклонением в сторону. Я не вижу никакого реального толчка к ее внедрению со стороны Apple.

SwiftUI значительно упростил и ускорил разработку пользовательского интерфейса для меня. Недавно PO в моем проекте сказала, что я «до смешного быстр», и я отбросил все ее оценки — в основном это заслуга SwiftUI.

То, как я пишу приложения сейчас, совершенно не похоже на то, как я делал это 5 лет назад, а это было совершенно не похоже на то, как я делал это 10 лет назад. То, что вы испытываете, — это технологический отток — вы находитесь в карьере, где вам придется постоянно заново учиться тому, как делать вещи. Я ожидаю, что все снова полностью изменится — возможно, уже скоро мы будем использовать искусственный интеллект для создания приложений.

Я считаю, что Swift прошел долгий путь по сравнению со своими ранними итерациями.

Навязывание типобезопасного языка поверх динамичного ядра, в котором все может быть чем угодно, было довольно сложной задачей.

Я считаю, что мы обменяли скорость записи на скорость чтения.

Раньше вы могли набивать NSArray любыми объектами, даже не-NSObject’ами, если знали, что делаете. Так что вы могли написать UITableView, а модель данных могла буквально состоять из одного NSArray. Легко!

Однако через 6 месяцев кто-то новый приходит и добавляет новую функцию, и этот NSArray теперь должен поддерживать мутабельность. А еще через 6 месяцев после этого приходит кто-то новый, не может понять, как все это работает, и переписывает это с каким-то сверхинженерным решением.

Теперь, в новом мире Swift с безопасностью типов, массив должен быть единственным типом, определенным во время компиляции. Таким образом, вы вынуждены заранее продумать, как будет работать ваша модель данных табличного представления. Это, вероятно, означает, что вы не можете просто написать все, что захотите, но это также означает, что вам (через 6 месяцев) и будущим разработчикам будет гораздо проще понять, как добавлять функции без необходимости рефакторить все подряд.

Таков мой опыт в целом. Инструментарий и боль при отладке — все это послужило тому, что кодовая база стала намного проще в использовании и обновлении, чем это было возможно во времена дикого запада.

Мне кажется, что все становится проще. В вашем распоряжении больше инструментов, но вы по-прежнему можете использовать все, что могли в прошлом. Новые вещи современны и решают то, что было болью в прошлом (быстрая итерация при разработке UI, многопоточность/асинхронность…), и я не чувствую, что качество языка ухудшается, Swift всегда был несколько более ориентирован на функциональное программирование, чем на классическое ООП.

Что мне больше всего не нравится, так это разные подходы различных фреймворков, например, WidgetKit дико отличается от всего остального.

Лично я не смотрю туториалы, если мне нужно узнать что-то новое, я читаю документацию, которая часто содержит пример проекта, и этого мне достаточно. Иногда я читаю статью о какой-то новой архитектуре, которую кто-то придумал…

Я не думаю, что это становится сложнее. SwiftUI определенно проще, чем UIKit, в нем меньше шаблонного кода, и он также чрезвычайно интуитивен, как только вы его освоите.

Async/await прост, как только вы поймете, что такое акторы и в каком потоке вы работаете. Если у вас есть сложные операции, которые нужно выполнить, это на 100% проще, чем NSOperation.

Да, выбор очень большой. Я думаю, это потому, что UIKit все еще большой, и в UIKit обычно есть реактивный компонент, такой как RXSwift/Combine.

Однако если посмотреть на то, в каком направлении он движется, то останется SwiftUI и async/await. Оба варианта очень пушистые и дружелюбные.

На новое дерьмо вроде SwiftData я не обращаю особого внимания. Для меня это все равно фигня, так как мне не нужна подобная логика в представлении. Не похоже, что это будет очень полезно прямо сейчас, если только вы не собираете одностраничное приложение со списком леденцов в волшебном ванильном SwiftUI, который они используют в своих демках.