@StateObject: Was es ist, Erstellung und Verwaltung von ObservableObject

Was ist @StateObject in SwiftUI

@StateObject ist ein Property Wrapper, der in iOS 14 eingeführt wurde und es einer View ermöglicht, eine Instanz einer Klasse zu erstellen und zu besitzen, die dem ObservableObject-Protokoll entspricht. Im Gegensatz zu @State, das mit Wertetypen (Structs) arbeitet, ist @StateObject für Referenztypen konzipiert — Klassen, die SwiftUI über Änderungen ihrer Eigenschaften benachrichtigen können.

Wenn eine View @StateObject var viewModel: MyViewModel verwendet, erstellt SwiftUI automatisch eine Instanz von MyViewModel, wenn die View zum ersten Mal angezeigt wird, und speichert sie in einem speziellen Framework-Speicher. Bei jeder Aktualisierung der View (z. B. wenn sich der Elternstatus ändert) erstellt SwiftUI das Objekt nicht neu — es verwendet die vorhandene Instanz, bis die View aus der Hierarchie entfernt wird.

Laut Apple WWDC Session 10137 (2024) löst @StateObject das Datenverlustproblem, das in iOS 13 beim Neuerstellen von Views bestand, bei dem Entwickler gezwungen waren, ObservableObject in der übergeordneten View zu erstellen und über den Initialisierer zu übergeben. Dies führte zu Code-Duplizierung und dem Risiko einer versehentlichen Neuerstellung des Objekts.

import SwiftUI

class CounterViewModel: ObservableObject {
    @Published var count: Int = 0
    
    func increment() {
        count += 1
    }
}

struct CounterView: View {
    @StateObject var viewModel = CounterViewModel()
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment", action: viewModel.increment)
        }
    }
}

Wie @StateObject funktioniert

Der Mechanismus von @StateObject basiert auf der Integration von SwiftUI mit dem Combine-Framework. Wenn ein ObservableObject seine Eigenschaften mit dem @Published-Attribut markiert, abonniert SwiftUI automatisch Änderungen über den in das ObservableObject-Protokoll integrierten Publisher. Wenn sich eine veröffentlichte Eigenschaft ändert, sendet das Objekt ein Signal über den objectWillChange-Publisher, was eine Neuzeichnung aller Views auslöst, die dieses Objekt beobachten.

SwiftUI speichert die ObservableObject-Instanz in einem speziellen Speicher, der an eine bestimmte View-Instanz gebunden ist. Dieser Speicher wird beim ersten Rendern einmal erstellt und existiert, bis die View zerstört wird. Aus diesem Grund garantiert @StateObject Referenzstabilität — SwiftUI verwaltet den Speicher automatisch, ohne auf den Initialisierer der View angewiesen zu sein.

Laut objc.io — Thinking in SwiftUI (2025) verwendet die interne Implementierung von @StateObject einen ähnlichen Mechanismus wie @State, jedoch für Referenztypen: SwiftUI erstellt einen Boxing-Wrapper um das Objekt und verwaltet seinen Lebenszyklus über einen eigenen Allokator, der für häufige Neuaufbauten der View-Hierarchie optimiert ist.

Lebenszyklus von @StateObject

• Erstellung — wenn die View zum ersten Mal auf dem Bildschirm erscheint, ruft SwiftUI den Initialisierer des Objekts auf und speichert die Referenz.
• Neuerstellung — wenn die übergeordnete View aktualisiert wird, wird das Objekt nicht neu erstellt; die vorhandene Instanz wird verwendet.
• Zerstörung — wenn die View den Bildschirm verlässt und aus der Hierarchie entfernt wird, ruft SwiftUI den Deinit des Objekts auf.

@StateObject vs @ObservedObject: Hauptunterschiede

Der Hauptunterschied zwischen @StateObject und @ObservedObject liegt darin, wer das Objekt besitzt. @StateObject erstellt und speichert das Objekt — es ist der Eigentümer. @ObservedObject beobachtet nur das Objekt, das an anderer Stelle erstellt und über den Initialisierer oder eine Eigenschaft übergeben wurde.

Die Regel ist einfach: Wenn die View das ObservableObject erstellt — verwende @StateObject. Wenn die View nur ein bereits erstelltes Objekt vom Elternteil erhält — verwende @ObservedObject. Ein Verstoß gegen diese Regel führt entweder zu Datenverlust (bei Verwendung von @ObservedObject für den Besitz) oder zu übermäßiger Objekterstellung (bei Verwendung von @StateObject für die Beobachtung).

Wann @StateObject verwenden

@StateObject sollte in Views verwendet werden, die die Quelle der Wahrheit für einen bestimmten Datensatz sind. Typische Szenarien umfassen Bildschirme mit eigenem View Model, Root-Bildschirme von Navigationsstapeln und modale Präsentationen, die ihren eigenen Zustand verwalten.

• Bildschirm mit View Model — jeder Bildschirm, der seine eigenen Daten und Logik verwaltet, sollte sein View Model über @StateObject erstellen.
• Root-View — in einer NavigationStack- oder TabView-Hierarchie erstellt das Root-Element die Daten, und untergeordnete Elemente erhalten sie über @ObservedObject.
• Modale Fenster — .sheet und .fullScreenCover benötigen oft ein eigenes @StateObject, um ein Formular oder einen Prozess zu verwalten.
• Bearbeitbare Liste — jede Listenzeile, die ein Bearbeitungsformular enthält, sollte ein eigenes @StateObject haben.

struct ProfileView: View {
    @StateObject var viewModel = ProfileViewModel()
    
    var body: some View {
        NavigationStack {
            Form {
                TextField("Name", text: $viewModel.name)
                TextField("Email", text: $viewModel.email)
                Button("Save") {
                    viewModel.saveProfile()
                }
            }
            .navigationTitle("Profile")
        }
    }
}

@StateObject mit Parametern initialisieren

Die Initialisierung von @StateObject mit Parametern erfordert eine spezielle Syntax, da SwiftUI die Objekterstellung selbst verwaltet. Sie können nicht einfach Parameter an den Initialisierer übergeben — Sie müssen einen Escape-Closure oder eine separate Factory-Methode verwenden.

Laut Swift by Sundell (2024) ist der sauberste Ansatz die Verwendung einer Factory-Methode oder eines Closures, das SwiftUI beim ersten Erstellen des Objekts aufruft. Ein alternativer Ansatz besteht darin, das ObservableObject in der übergeordneten View zu initialisieren und es über @StateObject mit dem Standard-Initialisierer zu übergeben.

class UserViewModel: ObservableObject {
    @Published var user: User
    
    init(user: User) {
        self.user = user
    }
}

struct UserDetailView: View {
    @StateObject var viewModel: UserViewModel
    
    init(user: User) {
        _viewModel = StateObject(wrappedValue: UserViewModel(user: user))
    }
    
    var body: some View {
        Text(viewModel.user.name)
    }
}

Es ist wichtig zu beachten, dass der View-Initialisierer mit @StateObject einen Unterstrich vor dem Eigenschaftsnamen (_viewModel) verwenden sollte, um auf den Property Wrapper selbst zuzugreifen, nicht auf seinen Wert. Dies ist ein standardmäßiges Swift-Muster für die Arbeit mit Property Wrappern in Initialisierern.

Häufige Fehler mit @StateObject

Der häufigste Fehler ist die Verwendung von @ObservedObject anstelle von @StateObject für eine View, die das Objekt besitzen sollte. In diesem Fall wird das Objekt bei jeder Neuerstellung des Elternteils neu erstellt, was zum Verlust aller angesammelten Daten führt. Dieser Fehler ist besonders tückisch in komplexen Hierarchien mit NavigationStack oder TabView.

• Datenverlust bei Navigation — wenn ein untergeordneter Bildschirm @ObservedObject für sein eigenes View Model verwendet, werden die Daten beim Zurücknavigieren und erneuten Öffnen zurückgesetzt.
• Speicherleck — das Erstellen von @StateObject in einer übergeordneten View, die nie entfernt wird, kann zur Objektansammlung führen, wenn jeder untergeordnete Bildschirm ebenfalls @StateObject ohne Kontrolle erstellt.
• Objektduplizierung — das Übergeben eines einzelnen ObservableObject an mehrere @StateObject in verschiedenen Views erstellt mehrere unabhängige Instanzen, die nicht miteinander synchronisiert werden.

Um diese Probleme zu vermeiden, befolgen Sie eine einfache Regel: ein @StateObject pro Quelle der Wahrheit. Wenn Daten über mehrere Bildschirme hinweg gemeinsam genutzt werden sollen — erstellen Sie @StateObject einmal in der Root-View und übergeben Sie es über @ObservedObject oder @EnvironmentObject an untergeordnete Elemente.

// ❌ Wrong: @ObservedObject for owning an object
struct BadView: View {
    @ObservedObject var vm = ViewModel() // will be recreated on each update!
}

// ✅ Correct: @StateObject for owning
struct GoodView: View {
    @StateObject var vm = ViewModel() // created once for View lifetime
}