SwiftUI — ключевые понятия, View, State и Data Flow

Что такое SwiftUI?

SwiftUI — декларативный UI-фреймворк Apple, радикально отличающийся от UIKit. Вместо создания контроллеров, вью и ручного управления их жизненным циклом, разработчик описывает интерфейс в виде деклараций: что должно быть на экране, а не как это построить. SwiftUI основан на принципе реактивности: интерфейс — это функция от состояния. При изменении состояния (State) SwiftUI автоматически пересчитывает body всех зависимых View и обновляет только изменившиеся части экрана. SwiftUI доступен на iOS 13+, iPadOS 13+, macOS 10.15+, watchOS 6+, tvOS 13+ и visionOS 1+. Код SwiftUI кроссплатформенный: один файл работает на iPhone, iPad, Mac и Apple Watch с минимальными платформенными адаптациями. По данным Apple WWDC Session 101 (2024), SwiftUI покрывает более 90% стандартных UI-паттернов App Store.

SwiftUI vs UIKit

UIKit — императивный фреймворк (2008): разработчик создаёт UIViewController, настраивает subviews в viewDidLoad, реализует delegate/datasource для UITableView и обновляет экран через reloadData или setNeedsLayout. SwiftUI заменяет контроллеры на простые структуры View, делегаты — на binding и onChange, Auto Layout — на HStack/VStack/ZStack с модификаторами (padding, frame, offset). UIKit требует ручного управления памятью через ARC; SwiftUI — структуры, не требующие подсчёта ссылок. Производительность SwiftUI сопоставима с UIKit: фреймворк использует diffing-алгоритм для минимального набора изменений. В IT Sectr SwiftUI используется для новых проектов с iOS 17+ target; проекты с поддержкой iOS 14–15 требуют UIKit из-за ограниченной совместимости SwiftUI.

Декларативный синтаксис SwiftUI

В SwiftUI интерфейс описывается через ViewBuilder — result builder, трансформирующий набор View в кортеж или Group. Модификаторы (.padding(), .font(), .foregroundColor()) создают новые View с изменёнными настройками, а не мутируют исходный объект. Каждый модификатор возвращает новое View, что позволяет chaining. ViewBuilder поддерживает if/else, switch, ForEach — условная и циклическая отрисовка без отдельных контроллеров. View в SwiftUI — value type (struct), что гарантирует предсказуемое поведение и исключает race conditions.

Протокол View и computed property body

View — протокол с единственным требованием: computed property body типа some View. Каждая структура, соответствующая View, описывает свою часть экрана в body. Тип some View — opaque return type, скрывающий конкретный тип возвращаемого View (спаривание VStack, HStack, ZStack, Text, Image и т. д.). Компилятор Swift выводит конкретный тип на этапе компиляции, сохраняя производительность прямого вызова без стирания типа.

import SwiftUI

struct GreetingView: View {
    var name: String
    
    var body: some View {
        VStack(spacing: 12) {
            Text("Hello, \(name)!")
                .font(.largeTitle)
                .foregroundColor(.primary)
            
            Text("Welcome to SwiftUI")
                .font(.body)
                .foregroundColor(.secondary)
        }
        .padding()
        .background(
            RoundedRectangle(cornerRadius: 12)
                .fill(.ultraThinMaterial)
        )
    }
}

Структура GreetingView принимает параметр name и отображает два текстовых блока в вертикальном стеке. Модификаторы .font, .foregroundColor, .padding и .background настраивают внешний вид. SwiftUI вызывает body каждый раз при изменении входных параметров (name) — перерисовка происходит только для изменившихся частей. В примере используется RoundedRectangle с .ultraThinMaterial — нативный blur-фон, встроенный в SwiftUI.

@State: локальное состояние в SwiftUI

@State — property wrapper, объявляющий локальное состояние, принадлежащее одному View. SwiftUI управляет памятью State автоматически: при изменении значения body перерисовывается, но только для View, использующих это State. State — source of truth для простых типов (String, Int, Bool, enum). Не используйте @State для сложных моделей данных — для них предназначены @StateObject и @ObservedObject. State должен быть private и храниться в самом View, а не передаваться между компонентами.

import SwiftUI

struct CounterView: View {
    @State private var count = 0
    
    var body: some View {
        VStack(spacing: 20) {
            Text("Count: \(count)")
                .font(.system(size: 48, weight: .bold))
            
            Button(action: { count += 1 }) {
                Label("Increment", systemImage: "plus.circle")
            }
            .buttonStyle(.borderedProminent)
        }
        .padding()
    }
}

Начальное значение count = 0. Каждое нажатие кнопки инкрементирует count; SwiftUI автоматически перерисовывает CounterView полностью (все View). В UIKit аналогичный сценарий потребовал бы IBOutlet, IBAction и ручного обновления label.text. @State гарантирует, что View перерисовывается только при изменении конкретного State — diffing-алгоритм SwiftUI находит минимальные изменения в tree.

@Binding: двухсторонняя связь между View

@Binding — property wrapper, создающий двухстороннюю связь между View и данными, которыми View не владеет. Binding — это ссылка на State (или другой source of truth), позволяющая дочернему View читать и изменять значение, хранящееся в родителе. Binding обозначается префиксом $: $count передаёт Binding<Int> в дочернее View. Без Binding дочернее View не может изменить данные родителя — только прочитать их.

import SwiftUI

struct StepperControl: View {
    @Binding var value: Int
    let range: ClosedRange<Int>
    
    var body: some View {
        HStack {
            Button(action: { if value > range.lowerBound { value -= 1 } }) {
                Image(systemName: "minus.circle")
            }
            Text("\(value)")
                .frame(minWidth: 40)
            Button(action: { if value < range.upperBound { value += 1 } }) {
                Image(systemName: "plus.circle")
            }
        }
    }
}

struct ParentView: View {
    @State private var quantity = 5
    
    var body: some View {
        StepperControl(value: $quantity, range: 1...10)
    }
}

ParentView владеет State quantity и передаёт Binding через $quantity. StepperControl может изменять value, и quantity в родителе синхронизируется автоматически. Binding — это не копия данных, а мост к источнику истины. Используйте @Binding для кастомных контролов, редакторов и повторно используемых компонентов, которые должны изменять данные родителя.

@ObservedObject и @StateObject: внешние модели данных

@StateObject — property wrapper для создания и владения экземпляром класса, соответствующего ObservableObject. View создаёт объект один раз за жизненный цикл и перерисовывается при изменении его @Published свойств. @ObservedObject — аналогичный wrapper, но View не владеет объектом — объект создаётся и хранится вне View (передаётся через инициализатор). Apple рекомендует @StateObject для source of truth в иерархии View и @ObservedObject для инъекции зависимостей.

import SwiftUI
import Combine

class UserSettings: ObservableObject {
    @Published var username: String = "Guest"
    @Published var isLoggedIn = false
}

struct ProfileView: View {
    @StateObject private var settings = UserSettings()
    
    var body: some View {
        VStack {
            TextField("Username", text: $settings.username)
                .textFieldStyle(.roundedBorder)
            
            Toggle("Logged In", isOn: $settings.isLoggedIn)
            
            if settings.isLoggedIn {
                Text("Welcome, \(settings.username)!")
                    .font(.headline)
            }
        }
        .padding()
    }
}

UserSettings — ObservableObject с двумя @Published свойствами. ProfileView владеет объектом через @StateObject. Изменение username или isLoggedIn автоматически перерисовывает ProfileView. @Published использует Combine Publisher для уведомления SwiftUI об изменениях. Для передачи settings дочерним View используйте @ObservedObject:

Data Flow в SwiftUI: полная картина

Apple определяет четыре уровня Data Flow в SwiftUI: @State (локальное, value type), @Binding (двухстороннее), @StateObject/@ObservedObject (reference type с ObservableObject), @EnvironmentObject (глобальное, внедрение через среду). EnvironmentObject позволяет передавать данные через всю иерархию View без явной передачи в инициализатор. Дополнительно @AppStorage работает с UserDefaults, @SceneStorage — с состоянием сцены, @FetchRequest — с Core Data. Выбор уровня Data Flow определяет архитектуру приложения: простые экраны используют State/Binding, модульные — ObservedObject, масштабные — EnvironmentObject + Redux-подобные решения (TCA, Composable Architecture).