Последние полгода каждый второй клиент с новым iOS-проектом задаёт нам один и тот же вопрос: SwiftUI или UIKit? Универсального ответа нет, но за три года в проде SwiftUI мы накопили достаточно данных, чтобы давать аргументированный.
Что у SwiftUI с зрелостью на конец 2022
SwiftUI 4 (iOS 16) - первая версия, на которой можно вести продакшн-проект без десятков обходных путей. До этого приходилось проваливаться в UIKit для половины базовых компонентов: коллекций, сложных анимаций, кастомных переходов. Сейчас остался короткий список вещей, ради которых нужен UIKit.
Где SwiftUI выигрывает
- Скорость разработки на типовых сценариях: формы, списки, карточки. В 1.5–2 раза быстрее UIKit.
- Live preview в Xcode: дизайнер и разработчик быстрее сходятся по UI.
- Простая поддержка тёмной темы, динамической типографики, локализаций.
- Декларативный стиль - легче ревьюить, легче править через полгода после написания.
- Кросс-платформенность внутри Apple-экосистемы: один компонент на iOS, iPadOS, macOS, watchOS.
Где SwiftUI ещё провисает
- Сложные коллекции с кастомными layout: до Layout protocol было больно, после - терпимо, но не идеально.
- Камера, видео, AR - здесь SwiftUI всё ещё обёртка над AVFoundation/ARKit, лучше работать напрямую через UIKit.
- Глубокая кастомизация системных компонентов (TextField, Picker) - приходится писать собственные.
- Производительность на длинных списках с тяжёлыми ячейками - UICollectionView пока быстрее.
Наш практический рецепт
Для нового приложения с минимальной поддержкой iOS 16 берём SwiftUI как основной стек. Там, где он не вытягивает, - заворачиваем UIKit-компоненты через UIViewRepresentable. Архитектурно держим UI-слой чистым на SwiftUI, бизнес-логику - в отдельном слое на чистом Swift, чтобы при необходимости можно было переключиться.
Если приложение должно поддерживать iOS 14 и старше - пока ещё рекомендуем UIKit как основу. Слишком много полезных API SwiftUI появились только в iOS 15–16.