SwiftUI просто фантастичен. Это отличный способ быстро создавать приложения, и, похоже, это будущее разработки для iOS. Предварительный просмотр фантастический, а скорость производства кажется беспрецедентной.
Мы видим, что Apple выпускает множество руководств и видеороликов для SwiftUI. радостно смотреть, как сообщество развивается вокруг этой технологии.
Итак, вы закончили один проект и должны начать новый в следующий понедельник.
Давайте рассмотрим некоторые из основных причин опасаться перехода на SwiftUI в 2022 году. Полное обоснование, которое вы можете представить своему техническому директору? Нет. Поверхностная экскурсия с остановками для размышлений о некоторых вещах.
Утечки памяти? Нет проблем
Представьте себе использование версии Xcode с серьезной утечкой памяти, связанной со SwiftUI. Если это, например, Xcode 13, можно думать, что это нормально, они исправят ее в 13.1. Что вы говорите, они исправили это только в Xcode 13.2.1?
Если для вас это важно, возможно, вы отнесетесь к этому со всем вниманием. Или, по крайней мере, будете относится все те месяцы, пока у вас будет утекать память.
Интересно, скажут ли мне в комментариях, что мне не следует использовать Geometry Reader. Я не использую Geometry Reader.
Apple не думает, что SwiftUI готов
Apple использует SwiftUI в своих собственных приложениях! Да, я считаю, что приложение-калькулятор использует SwiftUI. Я думаю, что приложение-переводчик использует SwiftUI. Другие приложения? В основном они написаны на Objective-C, и это многое говорит вам о внутреннем устройстве Apple, не так ли?
UIKit не исчезнет
Когда мы уходим от технологии, мы не обязательно оставляем ее позади. Для некоторых проектов может иметь смысл создание проекта с использованием хорошо задокументированной технологии, которая (глубокий вздох) все еще находится в разработке.
Навигация
Я хочу отделить навигацию от представлений. Я не хочу использовать UIHostingController, так как хочу создать полностью родное приложение на SwiftUI. Мне нужен легкий доступ к представлениям с использованием глубоких ссылок, когда экраны зависят от сложного состояния и могут быть доступны из нескольких частей приложения.
Конечно, есть множество ресурсов Apple по этому вопросу. Ох, люди должны делать это в продакшене, поэтому мы пойдем по наиболее распространенному пути. Ох.
Никогда не оставляйте пользователей позади
Существует множество статей, в которых утверждается, что SwiftUI готов к работе с версии 14.0. Великолепно, но сколько ваших пользователей используют 13+?
SwiftUI может быть правильным для вашей версии языка, может быть правильным для разработки вашего продукта.
Но вот вам нужно создать экран входа в систему (и вы знаете, что делать).
Вам понадобится property wrapper @FocusState, чтобы выбрать следующий TextField. Он работает только в iOS 15.
Сколько у вас пользователей, которые не используют iOS 15?
Никогда не отказывайтесь
Множество ютуберов зарабатывают на SwiftUI. Они продолжают создавать контент, мы продолжаем его потреблять. Критические и все меняющие изменения? Осенью появится новый курс.
Если вы выберете SwiftUI, в нем все еще могут быть критические изменения. Готовы потратить время на разработку, чтобы убедиться, что ваш код не работает в новой версии? Как соло-разработчик? Как подрядчик, которому оплачивают стоимость проекта? Как команда разработки фич?
Убедитесь, что у вас есть белое пальто и шляпа для переговоров с заказчиками.
Вывод
SwiftUI — это компромисс между тем, что вы можете делать, и тем, что мы можем делать в UIKit. Мы также должны учитывать навыки команды, проект, сроки и другие переменные, когда думаем о том, какую технологию использовать для той или иной задачи.
Понятно, что Apple хочет упростить разработку кроссплатформенных приложений, и SwiftUI является одним из компонентов в достижении этой цели. Что касается того, готов он или нет, это ваше решение в качестве ________ [введите название должности здесь].
Еще один случай «it depends» в ответ на вопросы о чем-то, связанном с программированием? Именно так.