Что такое SwiftUI и чем его декларативный подход отличается от императивного подхода UIKit?

Что такое SwiftUI

SwiftUI — декларативный UI-фреймворк Apple, представленный в 2019 году. Разработчик описывает что должно быть на экране через структуры, соответствующие протоколу View, а среда выполнения сама решает как и когда обновить дерево нативных элементов. Поддерживаются iOS 13+, macOS 10.15+, watchOS 6+, tvOS 13+ и visionOS.

Декларативный SwiftUI vs императивный UIKit

В UIKit разработчик вручную управляет объектами: создаёт UILabel, добавляет в иерархию, вызывает setNeedsLayout(), обновляет text при изменении данных. Код описывает последовательность действий.

В SwiftUI разработчик описывает функцию от состояния к UI. При каждом изменении источника истины (@State, @StateObject, @ObservableObject и т.д.) SwiftUI вызывает body, получает новое дерево значимых структур и сравнивает его с предыдущим — это называется diffing. Только изменившиеся части находят отражение в реальных нативных слоях (UIKit под капотом на iOS).

import SwiftUI
import Combine

// --- Модель ---
@Observable
final class CounterModel {
    var count = 0
    func increment() { count += 1 }
}

// --- UIKit-стиль (императивно) ---
// final class CounterViewController: UIViewController {
//     private let label = UILabel()
//     private var model = CounterModel()
//     override func viewDidLoad() {
//         super.viewDidLoad()
//         view.addSubview(label)
//         label.text = "\(model.count)"
//     }
//     @objc func buttonTapped() {
//         model.increment()
//         label.text = "\(model.count)"  // вручную синхронизируем UI
//     }
// }

// --- SwiftUI-стиль (декларативно) ---
struct CounterView: View {
    @State private var model = CounterModel()

    var body: some View {
        VStack(spacing: 20) {
            Text("Count: \(model.count)")
                .font(.largeTitle)
                .accessibilityLabel("Current count is \(model.count)")

            Button("Increment") {
                model.increment()   // меняем состояние — UI обновится сам
            }
            .buttonStyle(.borderedProminent)
        }
        .padding()
        .task {
            // Структурированная конкурентность: задача отменяется
            // автоматически при уходе view из иерархии
            await loadInitialCount()
        }
    }

    private func loadInitialCount() async {
        // Имитация сетевого запроса
        try? await Task.sleep(for: .seconds(1))
        model.count = 42
    }
}

// --- Предпросмотр ---
#Preview {
    CounterView()
}

Жизненный цикл body и инвалидация

Когда источник истины меняется, SwiftUI помечает зависимые View как dirty и на следующем проходе рендера вызывает их body. Само по себе это дёшево — структуры создаются на стеке. Дорогостоящим может стать слишком широкая зависимость: если один большой @ObservableObject публикует все изменения через objectWillChange, весь экран перерисовывается при любом изменении любого поля.

С @Observable (iOS 17+, Swift 5.9 Observation framework) гранулярность отслеживания стала автоматической: SwiftUI подписывается только на те свойства, которые реально читает body.

Сравнение моделей

Подводные камни

• Чрезмерная инвалидация через @ObservableObject. Один @Published на весь экран приводит к перерисовке всего дерева при каждом изменении. Решение: дробить модели или переходить на @Observable (iOS 17+).
• Неправильный выбор хранилища состояния. @State создаётся заново при удалении view из иерархии. Если состояние должно пережить навигационный переход, оно должно жить в @StateObject или в родительском view.
• Сильные ссылки в замыканиях внутри body. Захват self в Button/.task может задержать освобождение класса. View-структуры не имеют [weak self], поэтому при работе с акторами и классами нужно явно контролировать время жизни.
• Дорогие вычисления в body. body может вызываться несколько раз в секунду. Форматирование строк, сортировки и фильтрации следует выносить в модель или кэшировать через let-константы снаружи body.
• Конфликт идентичности при анимации. SwiftUI идентифицирует элементы списка по значению (Identifiable) или позиции. Использование UUID как id, генерируемого каждый раз, ломает анимацию и вызывает полный rebuild списка вместо diff-анимации.
• Блокировка main actor. @MainActor-код исполняется в главном потоке. Синхронные операции с диском или тяжёлые JSON-парсинги внутри методов, вызываемых из body, замораживают UI — даже при декларативном коде.
• Потеря состояния при смене размера окна / Split View. На iPad при переходе в Slide Over view может пересоздаться, а @State — сброситься. Персистентное состояние следует хранить в модели, а не в локальном @State.
• Несовместимость UIViewRepresentable и SwiftUI-жизненного цикла. При оборачивании UIKit-компонентов через UIViewRepresentable обновления SwiftUI могут вызывать updateUIView неожиданно часто. Нужно явно сравнивать старый и новый контекст, чтобы не перезапускать анимации.

• Сводить «SwiftUI и чем его декларативный подход отличается от императивного подхода UIKit» к синтаксису и не объяснять инвалидация body.
• Игнорировать жизненный цикл, основной поток или момент освобождения ресурсов в сценарии swiftui-1.
• Выбирать API по привычке, не проверяя состояние, ошибки, доступность и платформенные ограничения.

• Формулирует точную модель для «SwiftUI и чем его декларативный подход отличается от императивного подхода UIKit» и подтверждает ее корректным примером.
• Умеет связать ответ с navigation state, тестированием и отладкой на устройстве.
• Называет ограничения подхода swiftui-1, включая производительность, память и сопровождение.