Приветствую, коллеги. Решил поддержать обсуждение на нашем форуме.

SwiftUI против UIKit – интересный кейс. Если посмотреть объективно, то SwiftUI имеет свои козыри. Например, сокращение boilerplate кода. По моим замерам, для простых UI-элементов время разработки может сократиться до 20-25%. Но тут есть нюансы.

• Производительность: На данный момент, особенно на старых версиях iOS, UIKit все еще может показывать лучшую производительность в сложных сценариях.
• Кастомизация: Глубокая кастомизация некоторых элементов в SwiftUI может быть более трудоемкой, чем в UIKit, где есть прямой доступ к нативным компонентам.
• Экосистема: Огромное количество существующих библиотек и туториалов заточено под UIKit. Миграция или интеграция может потребовать дополнительных усилий.

Кмк, выбор зависит от конкретного проекта. Для новых, небольших приложений с фокусом на внешний вид – SwiftUI идеален. Для больших, высоконагруженных легаси-проектов, где стабильность и производительность важнее всего, UIKit пока остается более предсказуемым решением. Или гибридный подход, где части UI переписываются на SwiftUI постепенно

А что вы думаете по этому поводу? Какие метрики для вас приоритетнее?

LensMaster

IronMan, смотри, про сокращение boilerplate кода ты верно подметил.

Но лично я, когда замерял, увидел сокращение времени именно на простые, типовые элементы. Вот где-то 15-20%, не больше. Если брать что-то более сложное, с кастомной логикой, анимациями, то разница нивелируется. И иногда приходится обходить ограничения SwiftUI, подключая UIKit через UIViewRepresentable или UIViewControllerRepresentable. Это, ну, убивает всю эту "сказочную" простоту, которую ты упомянул.

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

Так что, имхо, для прототипов и новых фич SwiftUI – огонь. Но для поддержки legacy и крупных, требовательных проектов, UIKit пока еще держит оборону. На slon5.cc тоже были интересные дискуссии на эту тему.

Привет, BugFixer!

Согласен с тобой про SwiftUI... пока что. Я вот тоже типа начал его трогать, ну и как-то **не понял**

А это нормально что у меня там всякие ошибки вылезают когда пытаюсь что-то сложное сделать?

UIKit вроде как понятнее, больше примеров нашел. Может я просто не привык еще к декларативному всему этому..

Подскажите плз, кто уже на реальных больших проектах с SwiftUI работает? Как там вообще?

Или это пока рано для таких дел?

IronMan, насчет сокращения boilerplate — это да. По ттх, SwiftUI реально быстрее в прототипировании. Сам замерял: простенькую карточку с парой изображений и текстом верстал на SwiftUI минут за 10, на UIKit ушло бы раза в два больше. Но тут вопрос в другом:

• Стабильность. На iOS 13-14 SwiftUI вел себя непредсказуемо. Пришлось делать гибридные решения, чтобы обойти баги.
• Сложные UI-компоненты. Для кастомных жестов, анимаций, которые требуют тонкой настройки, UIKit пока вне конкуренции. Там полный контроль над всеми процессами.

Кмк, для большинства типовых задач SwiftUI подходит отлично. Но для больших, высоконагруженных приложений, где важна каждая миллисекунда и каждый байт памяти, UIKit все еще актуален. Это как сравнивать болид Формулы 1 и надежный грузовик. Оба хороши, но для разных задач. Кстати, если говорить про оптимизацию, то наши парни на slon6.cc недавно выкатили гайд по производительности на Swift. Может, пригодится.

IronMan, ты затронул тему boilerplate кода. Согласен, SwiftUI тут выигрывает. По нашим тестам, для типовых интерфейсов, вроде списков или кнопок, количество строк кода снижается на 30-40%.

Однако, когда речь заходит о сложных кастомных контролах или интеграции со старым UIKit кодом, тут начинаются нюансы. Адаптивность SwiftUI под разные версии iOS тоже пока не идеальна. Если проект должен поддерживать iOS 13, например, без UIKit не обойтись, как ни крути.

Кстати, про "большую кодовую базу", о которой BugFixer упомянул. Миграция с UIKit на SwiftUI — это отдельная задача. Иногда проще написать новый модуль на SwiftUI, чем переписывать существующий. Это как апгрейд системы: можно накатить поверх, а можно и с нуля собрать. Каждый раз своя головная боль.

Кстати, кто-нибудь уже пробовал использовать SwiftUI для серверной части? Чисто гипотетически, если взять какой-нибудь фреймворк типа Vapor, можно ли там UI генерировать? Или это совсем из области фантастики?)