Swiftui через 7 лет: обещания и реальность

Семь лет назад Apple показала SwiftUI на WWDC, и зал аплодировал стоя. Декларативный синтаксис, единый источник данных, встроенные анимации, превью в реальном времени — всё это звучало как революция. Звучит знакомо? Вот только революция так и не случилась.

Проблема в том, что я наблюдаю эту картину не по слухам. На прошлой неделе скачал официальный туториал Apple по SwiftUI — тот, что они рекомендуют новичкам. Запустил проект на последнем Xcode и macOS. Боковая панель в демо сломана. Уже два года как сломана.

Это не баг одной версии. Это симптом системный.

Что обещали в 2019 году

Apple не просто выпустила фреймворк — она объявила войну Auto Layout. Больше никаких констрейнтов, никакой магии с констрейнтами. Вместо этого — декларативный синтаксис, где ты описываешь что хочешь получить, а система сама разбирается с расположением.

Звучит логично. React Native и Flutter уже показали, что декларативный подход работает. Кроссплатформенность тоже обещали — один код для iOS, macOS, watchOS. Красота.

Но в реальности Apple решала не только свои задачи. К середине 2010-х React стал стандартом веба, React Native и Flutter захватывали мобайл. Писать нативные приложения становилось всё менее привлекательно. А на Mac App Store мало кто заходил — веб-приложения и Electron казались проще.

SwiftUI был ответом на обе угрозы: удержать разработчиков в нативной экосистеме и упростить портирование с iOS на Mac.

СТРУКТУРА ДАННЫХ В SWIFTUI: ЭВОЛЮЦИЯ ЗА 7 ЛЕТ
────────────────────────────────────────────────
2019:  @State + @Binding + @ObservedObject
       ├─ Проблема: постоянные перерисовки
       └─ Решение: Observation framework

2024:  @Observable (макрос)
       ├─ Компилятор оптимизирует
       └─ Но layout всё равно непредсказуем

2026:  ??? (ждём следующий подход)

Поток данных: чёрный ящик

В теории единый источник данных — это мечта. В SwiftUI это кошмар. Система property wrappers, макросов и фреймворков поддержки менялась несколько раз. Начинали с @State, @Binding и @ObservedObject. Потом Apple поняла, что производительность катастрофическая — представления перерисовывались постоянно. Выкатили Observation framework и макрос @Observable. Пытались решить проблему через оптимизации компилятора, но этого не хватило.

Теперь самое главное: в SwiftUI вы никогда не знаете точно, сколько раз представление обновится и почему. Даже недокументированные отладочные API не дают полной картины. Реактивность SwiftUI — это реактивность в неправильных направлениях. Он реагирует на изменения, которые стоило бы игнорировать, и игнорирует те, что важны. Предсказуемое поведение? Забудьте.

Система layout: постоянные сюрпризы

Дошли до архитектуры. SwiftUI использует систему size negotiation — «согласование размеров». На бумаге звучит логично. На практике попробуйте построить плавающее окно или кастомный сайдбар.

Стандартный сайдбар из туториала Apple? Он сломан с 2024 года. UTM — отличный проект, но зависимость от SwiftUI делает интерфейс похожим на прототип. В итоге все используют GeometryReader. И это капитуляция. Вы теряете все преимущества декларативного подхода и начинаете считать координаты вручную — с ещё большей многословностью, чем в Auto Layout. И нет гарантии, что в следующем обновлении не придётся переписывать всю математику.

ОБЕЩАНИЕ VS РЕАЛЬНОСТЬ SWIFTUI
───────────────────────────────
Обещание:                    Реальность:
┌──────────┐                ┌──────────┐
│ Деклара- │                │ Геометрия│
│ тивный   │───────────────▶│  Reader  │
│  подход  │                │  everywhere
└──────────┘                └──────────┘
        │                         ▲
        ▼                         │
┌──────────┐                ┌──────────┐
│ Меньше   │                │  Shim'ы  │
│  кода    │                │ для совм.│
└──────────┘                └──────────┘
        │                         ▲
        ▼                         │
┌──────────┐                ┌──────────┐
│ Превью   │                │ Периоди- │
│  вживую  │                │ ческие   │
                            │ баги     │
                            └──────────┘

Стабильность API бесконечная гонка за совместимостью

Посмотрите на любой современный SwiftUI-проект — он забит проверками if #available. Смешно? Нет, грустно. Кто-то в 2019 году говорил про меньше кода и лучше код.

Семь лет прошло. С dismiss клавиатуры при скролле — нужен iOS 16. Кастомизация toolbar окна — пришла только через несколько лет. Показ картинок из сети — AsyncImage появился в iOS 15. Кэширование этих картинок? До сих пор бета.

Когда Apple наконец выпускает API, который десятилетиями существовал в AppKit или UIKit, приходится поддерживать несколько реализаций. А если API существовал с первой версии SwiftUI? Скорее всего, его уже переименовали или заменили. NavigationView был баговатым — вместо исправления заменили на NavigationStack. Теперь отдельные ветки для разных версий iOS.

Это «меньше кода» или «лучше код»? Я не знаю.

Где swiftui реально работает

Честность требует признать: SwiftUI не бесполезен. Быстрая прототипизация действительно быстрая. Несложные экраны и списки писать приятно. Превью в Xcode — это круто, когда работает. И это определённо будущее Apple-платформ.

Но это не полная замена UIKit. Для сложных интерфейсов, где нужна предсказуемость и контроль, UIKit остаётся рабочим инструментом.

Практический вывод

Семь лет — это много. Это время между iPhone и iOS 7. Это целая эпоха в разработке. И всё равно SwiftUI ощущается как бета-версия с костылями.

Проблема не в том, что фреймворк плохой. Проблема в том, что он не достиг зрелости, которую обещали. Каждый новый релиз приходит с сюрпризами. Каждый фикс ломает что-то ещё.

Для команд: используйте SwiftUI там, где он удобен. Но не стройте всю архитектуру на обещаниях Apple. Оставьте запасной выход — знание UIKit, возможность переключиться на более предсказуемые инструменты.

SwiftUI хорош для стартапа, прототипа, несложного приложения. Для production-level проекта с командой — считайте риски заранее.

Ссылки

• SwiftUI After 7 Years: A Story of Mediocrity — статья Yakov Manshin о проблемах SwiftUI