SwiftUI Apple спустя семь лет: разработчик называет фреймворк «вечной бетой»

Инженер опубликовал развёрнутый критический разбор SwiftUI (текст, расшифровка авторского видео) под названием «SwiftUI After 7 Years». Его тезис: спустя семь лет после анонса на WWDC 2019 SwiftUI так и не стал зрелым, готовым к продакшну фреймворком, каким его обещала Apple, а по-прежнему ощущается как «вечная бета».

Автор напоминает, зачем вообще появился SwiftUI: к середине 2010-х React стал стандартом де-факто в вебе, следом React Native и Flutter начали захватывать мобильную разработку, и бизнесу стало выгоднее держать один кодбейс на iOS и Android, чем писать нативные приложения отдельно. Вторая причина, по мнению автора, упадок Mac App Store: многие приложения на Mac живут в браузере или в виде обёрток Electron, а App Store приносит Apple 30% с каждой транзакции. SwiftUI должен был удержать разработчиков в нативной экосистеме и упростить перенос приложений на Mac, обещая декларативный синтаксис, единый источник истины, встроенную анимацию, мгновенные превью и переиспользование кода между платформами.

По словам автора, ни одно из этих обещаний не реализовано в полной мере. Поток данных, задуманный как единый источник истины, на практике превратился в мешанину из property wrapper'ов, макросов и постоянно меняющихся вспомогательных фреймворков: сначала @State, @Binding и ObservedObject, затем, после того как выяснилось, что производительность из-за постоянных перерисовок никуда не годится, фреймворк Observation и макрос @Observable. По утверждению автора, даже недокументированные средства отладки не дают полной картины того, сколько раз обновится представление и почему.

Лэйаут-система, построенная на идее согласования размеров (size negotiation), по оценке автора крайне непредсказуема: он утверждает, что она разваливается при попытке собрать нестандартный плавающий элемент или боковую панель, а разработчики в итоге оборачивают всё в GeometryReader, то есть вручную считают координаты, теряя весь смысл декларативного подхода. В качестве иллюстрации автор ссылается на официальный обучающий проект Apple по SwiftUI (Landmarks): по его словам, боковая панель в собранном по инструкции демо-проекте выглядит сломанной, и этот дефект он впервые заметил больше двух лет назад, с тех пор ничего не изменилось. Также он упоминает приложение UTM как пример реального продукта, который, по его мнению, страдает от хрупкости SwiftUI-раскладок.

Отдельная претензия, нестабильность API и отставание от функциональности UIKit и AppKit. Автор приводит примеры: скрытие клавиатуры при скролле (в UIKit доступно с iOS 7) в SwiftUI заработало только с iOS 16; загрузка изображений по сети через AsyncImage появилась лишь в iOS 15; а API для кеширования таких изображений, по его словам, по состоянию на июль 2026 года всё ещё находится в статусе бета. Компонент NavigationView, известный своими багами, Apple заменила на NavigationStack, из-за чего разработчикам приходится поддерживать отдельные ветки кода для старых и новых версий SwiftUI. Для контраста автор указывает на Jetpack Compose в Android: это, по его словам, обновляемый через менеджер зависимостей пакет, который встраивается прямо в исполняемый файл и обеспечивает одинаковый интерфейс на устройствах вплоть до 2014 года выпуска.

По производительности автор приводит собственное сравнение UIKit и SwiftUI на простой галерее изображений в старой версии своего pet-проекта: несмотря на оптимизации вроде декодирования картинок в фоновом потоке, прокрутка сетки в SwiftUI, по его наблюдению, ощутимо менее плавная, чем в UIKit-версии, и тест он намеренно проводил на не самом новом iPhone. Численных метрик (кадры в секунду, время загрузки) в тексте не приводится, только качественная оценка. Текст обрывается на разделе про кросс-платформенность SwiftUI, вывод и примеры на эту тему в доступном материале отсутствуют, реакции Apple на критику в тексте тоже нет.

Ключевые факты

Семь лет спустя после анонса на WWDC 2019 автор называет SwiftUI «вечной бетой», а не зрелым продакшн-фреймворком
Поток данных SwiftUI, по его оценке, непредсказуем: несколько сменявших друг друга подходов (@State/@Binding/ObservedObject, затем Observation и @Observable) не решили проблему лишних перерисовок
Лэйаут-система на основе согласования размеров разваливается на нестандартных интерфейсах, вплоть до бага в собственном официальном туториале Apple, не исправленного больше двух лет
Базовые возможности приходят с многолетним опозданием: скрытие клавиатуры при скролле, только с iOS 16, AsyncImage, с iOS 15, API кеширования изображений на июль 2026 всё ещё в бете
В прямом сравнении на простой галерее изображений прокрутка в SwiftUI, по наблюдению автора, заметно менее плавная, чем в UIKit, несмотря на ручные оптимизации

Почему это важно

SwiftUI, основной инструмент Apple для разработки интерфейсов на iOS, macOS, iPadOS, watchOS и tvOS, и компания годами позиционирует его как будущее платформы. Материал ставит под сомнение центральное обещание 2019 года, что декларативный подход и единый источник истины избавят разработчиков от боли Auto Layout. Автор утверждает, что спустя семь лет фреймворк так и не достиг паритета по функциональности с «легаси»-UIKit и AppKit, а часть базовых возможностей, доступных в UIKit десятилетиями, в SwiftUI появилась лишь недавно или до сих пор в статусе беты.

Кому это важно

В первую очередь, iOS- и macOS-разработчикам, которые выбирают между SwiftUI и UIKit/AppKit для новых и существующих проектов, и техническим лидам, планирующим миграцию кодовой базы на SwiftUI. Также материал будет интересен разработчикам, работающим с аналогичными декларативными UI-фреймворками на других платформах (React, React Native, Flutter, Jetpack Compose), которых автор упоминает как ориентир.

Как это применить

Материал не содержит инструкций или пошаговых рекомендаций, это авторская критическая оценка. Из практических наблюдений, которые в нём приводятся: отладка причин лишних перерисовок в SwiftUI требует недокументированных средств вроде Self._printChanges(), а работа со сложными нестандартными раскладками нередко сводится к GeometryReader и ручному расчёту координат. Также автор упрекает Apple в том, что производительность SwiftUI компания демонстрирует только на новейшем «железе», а не в реальных условиях эксплуатации.

Можно ли доверять

Это личная, эмоционально окрашенная оценка одного инженера (материал изначально сделан как видео, здесь, его расшифровка), а не независимое исследование или официальная позиция Apple: реакции компании на критику в тексте нет. Часть утверждений подкреплена конкретными и проверяемыми деталями, версии iOS, в которых появились те или иные API, официальный обучающий проект Apple со сломанной, по словам автора, боковой панелью. Другая часть, включая сравнение производительности SwiftUI и UIKit, качественное наблюдение автора на собственном pet-проекте без опубликованных числовых метрик (FPS, времени загрузки), то есть проверить его напрямую по тексту нельзя. Доступный фрагмент материала обрывается до раздела о кросс-платформенности, поэтому выводы автора по этой части неизвестны.

Риски и подводные камни

Главный риск, принять эмоциональный авторский разбор за нейтральный технический отчёт: часть оценок (непредсказуемость лэйаута, «мешанина» в потоке данных, менее плавный скролл), субъективные впечатления одного разработчика, не подкреплённые бенчмарками. Материал также не отражает точку зрения Apple и не описывает, решает ли компания эти проблемы в актуальных релизах SwiftUI за пределами того, что упомянуто в тексте. Доступный фрагмент обрывается на полуслове в разделе про кросс-платформенность, итоговый вывод автора по этой теме в материале отсутствует.

«Все эти проблемы должны были решить ещё в 2019-м, ну ладно, в 2020-м. А спустя семь лет SwiftUI так и не достиг паритета по функциональности с «легаси»-фреймворками.»

— автор материала