SwiftUI в 2026 — стоит ли уходить с UIKit на новых проектах?

[mstrbates]

Начинаем новый iOS-проект (B2C, что-то вроде трекера привычек с виджетами и Live Activities). Старший разработчик настаивает на UIKit + программный autolayout — 'надёжно, предсказуемо, знаем подводные камни'. Я хочу SwiftUI — быстрее разрабатывать, виджеты нативно на SwiftUI, меньше бойлерплейта. Как убедить тимлида или, наоборот, где я не прав?

[regexveteran]

SwiftUI для виджетов и Live Activities — это не вопрос выбора, это обязательное требование Apple. WidgetKit работает только со SwiftUI. Если в вашем проекте есть виджеты — аргумент 'UIKit надёжнее' уже не полный. Можно делать гибрид: UIKit для основного приложения, SwiftUI для виджетов и новых экранов.

[tastytim]

Тимлид в чём-то прав. SwiftUI до сих пор имеет баги с NavigationStack на iOS 16-17, List с большими данными периодически подтупливает, анимации иногда ведут себя непредсказуемо между версиями OS. На iOS 18+ большинство проблем пофиксили, но если ваш деплоймент таргет ниже 17 — будьте готовы к боли.

[marianna]

Я переписывал приложение с UIKit на SwiftUI два года назад. Скорость разработки новых экранов выросла примерно вдвое. Но отладка SwiftUI-стейта поначалу сводит с ума — инструменты Xcode для дебага SwiftUI до сих пор хуже чем для UIKit. @State/@Binding/@StateObject — нужно хорошо понимать ownership иначе получите рассинхронизацию данных.

[softlurker]

Для трекера привычек с виджетами — однозначно SwiftUI. Это именно тот use-case, для которого его делали. App Intents, WidgetKit, Live Activities, Shortcuts — всё это первоклассный SwiftUI. Если бы вы делали сложный кастомный UI с рисованием (графики, карты) — разговор другой.

[Esp32Smith]

Минимальный деплоймент таргет поднимите до iOS 17. В 2026 году доля iOS 16 уже менее 5% по данным Apple. Старший разработчик, скорее всего, имел опыт с ранними версиями SwiftUI (до iOS 16) — там действительно было больно. Сейчас ситуация другая.

[sdag]

Компромисс: пишите новое приложение на SwiftUI с архитектурой, которая позволяет вынести логику отдельно (Observable + чистые модели). Если SwiftUI начнёт давать сбои на каком-то экране — заверните в UIHostingController и перепишите этот конкретный экран на UIKit. Такой подход снижает риск и даёт опыт обеим сторонам.

[prometheusandy]

Вопрос на самом деле не технический, а политический. Сеньор не хочет учить новый фреймворк и прикрывается словом надёжность. Виджеты и Live Activities всё равно придётся писать на SwiftUI, то есть он будет ревьюить код на технологии которую не знает, вот это реальный риск проекта, а не баги NavigationStack. Сядьте вдвоём, напишите по одному экрану на обоих стеках и сравните по времени и читаемости. Обычно после этого спор заканчивается сам.

[gdgdgd]

@tastytim, про List справедливо, но лечится. LazyVStack в ScrollView вместо List на больших данных и подтупливание уходит. А в трекере привычек больших списков нет в принципе, 20-30 ячеек максимум. Так что для конкретно этого проекта аргумент не работает, хотя сам по себе верный.

[davkar]

@sdag, гибрид красиво звучит на бумаге. На практике навигация между UIKit и SwiftUI экранами это отдельная боль: UIHostingController внутри пуша ок, а вот пушнуть UIKit контроллер из SwiftUI это уже танцы с координаторами. Плюс у hosting controller свои приколы с safe area и клавиатурой. Я бы не закладывался что заворачивание спасёт, проще сразу честный SwiftUI без запасных аэродромов.