Как работают @Observable / Observation framework и чем он отличается от ObservableObject?

Как работает @Observable

При объявлении класса с @Observable компилятор автоматически добавляет геттеры и сеттеры с вызовами _$observationRegistrar. Это позволяет системе точно фиксировать зависимости: если представление читает только model.title, а изменяется model.count, перерисовки не происходит.

import Observation

@Observable
final class CounterModel {
    var count: Int = 0
    var title: String = "Counter"
}

struct CounterView: View {
    // Не нужен @StateObject или @ObservedObject
    @State private var model = CounterModel()

    var body: some View {
        VStack {
            Text(model.title)
            Text("\(model.count)")
            Button("+") { model.count += 1 }
        }
    }
}

Observation framework и @Observable

Начиная с iOS 17 и Swift 5.9, Apple представила макрос @Observable из модуля Observation. Он заменяет протокол ObservableObject и устраняет его главные недостатки. Компилятор разворачивает макрос в код, который отслеживает чтение конкретных свойств и уведомляет только те представления, которые реально обращались к этим свойствам.

Отличия от ObservableObject

С протоколом ObservableObject модель обязательно должна быть классом, а каждое свойство помечается @Published. Любое изменение любого @Published-свойства вызывает objectWillChange, что перерисовывает все подписанные представления целиком.

// Старый подход — ObservableObject
import Combine

final class LegacyCounterModel: ObservableObject {
    @Published var count: Int = 0
    @Published var title: String = "Counter"
}

struct LegacyCounterView: View {
    @StateObject private var model = LegacyCounterModel()
    // При изменении count перерисовывается ВСЕ представление,
    // даже если оно читает только title
    var body: some View {
        Text(model.title)
    }
}

Ключевые отличия:

• Гранулярность: @Observable отслеживает конкретные свойства, ObservableObject публикует единый сигнал на весь объект.
• Аннотации: с @Observable не нужен @Published — все хранимые свойства отслеживаются автоматически. Чтобы исключить свойство, используется @ObservationIgnored.
• Зависимости от Combine: ObservableObject использует Combine, @Observable — нет.
• Передача через тело представления: с @Observable можно передавать объект как обычный аргумент — SwiftUI сам определит зависимости. С ObservableObject нужен @EnvironmentObject или @ObservedObject.
• Environment: с @Observable используется .environment(model) и @Environment(CounterModel.self) вместо .environmentObject и @EnvironmentObject.

// Передача через environment с @Observable
struct RootView: View {
    @State private var model = CounterModel()
    var body: some View {
        ContentView()
            .environment(model)
    }
}

struct ContentView: View {
    @Environment(CounterModel.self) private var model
    var body: some View {
        Text("\(model.count)")
    }
}

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

• @Observable работает только с классами; структуры и перечисления не поддерживаются.
• При смешивании ObservableObject и @Observable в одном проекте легко перепутать @EnvironmentObject и @Environment(T.self) — это приводит к краш-ошибке в рантайме.
• Свойства с @ObservationIgnored не вызывают перерисовку — если забыть эту аннотацию на кэше или вспомогательном поле, появятся лишние ре-рендеры.
• Computed properties не отслеживаются автоматически; если они зависят от отслеживаемых свойств, нужно обращаться к ним напрямую в теле body.
• Макрос требует Swift 5.9+ и iOS 17+; для поддержки iOS 16 и ниже всё равно нужен ObservableObject.
• Использование @Bindable вместо @Binding при работе с @Observable объектом — частая ошибка у тех, кто переходит со старого API.
• Наблюдение не работает через границы actor isolation без дополнительной осторожности — мутации должны происходить на главном акторе.

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.