@ObservedObject: was ist das, Beobachtung von Objekten und Aktualisierung von Views

Was ist @ObservedObject in SwiftUI

@ObservedObject ist ein Property Wrapper, der eine View für ObservableObject-Änderungen abonniert. Wenn ein mit @ObservedObject markiertes Objekt eine seiner mit @Published deklarierten Eigenschaften ändert, zeichnet SwiftUI die View automatisch neu. @ObservedObject erstellt das Objekt nicht — es stellt lediglich eine Verbindung zwischen einer vorhandenen ObservableObject-Instanz und der View her, die auf ihre Änderungen reagieren soll.

Der Hauptunterschied zwischen @ObservedObject und @StateObject ist das Eigentum. @ObservedObject geht davon aus, dass das Objekt irgendwo höher in der View-Hierarchie erstellt und gespeichert wurde. Die untergeordnete View erhält einen Verweis auf dieses Objekt über den Initialisierer und beobachtet es lediglich. Wenn die untergeordnete View neu erstellt wird, erhält sie denselben Verweis vom Elternteil — Daten gehen nicht verloren.

Laut Apple Developer Documentation — SwiftUI (2025) ist @ObservedObject ab iOS 13 verfügbar, was es zur einzigen Option für die Beobachtung von ObservableObject in Projekten mit Unterstützung älterer iOS-Versionen macht. In iOS 14+ wird @StateObject zum Erstellen von Objekten bevorzugt, aber @ObservedObject bleibt für die Übergabe vorhandener Objekte relevant.

Wie funktioniert @ObservedObject

Der Mechanismus von @ObservedObject basiert auf dem ObservableObject-Protokoll aus dem Combine-Framework. Jede Klasse, die ObservableObject entspricht, erhält automatisch einen objectWillChange Publisher, der ein Signal sendet, bevor sich eine @Published-Eigenschaft ändert. SwiftUI abonniert diesen Publisher über @ObservedObject und markiert die View beim Empfang des Signals als neu zu zeichnen.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // Daten abrufen
        isLoading = false
    }
}

struct TaskListView: View {
    @ObservedObject var viewModel: TaskViewModel
    
    var body: some View {
        List(viewModel.tasks) { task in
            Text(task.title)
        }
        .task { await viewModel.loadTasks() }
    }
}

Wenn die Eltern-View viewModel über den Initialisierer an TaskListView übergibt, erstellt SwiftUI eine Verbindung zwischen dem Objekt und der View. Wenn sich das tasks-Array oder das isLoading-Flag ändert, zeichnet SwiftUI TaskListView neu. Das Objekt selbst bleibt unverändert — es wird in der Eltern-View über @StateObject gespeichert.

@ObservedObject vs @StateObject: Wann was verwenden

Der Unterschied zwischen @ObservedObject und @StateObject ist der Unterschied zwischen einem Beobachter und einem Eigentümer. @StateObject erstellt das Objekt und verwaltet seinen Lebenszyklus. @ObservedObject beobachtet nur ein Objekt, das an anderer Stelle erstellt und gespeichert wurde. Die Wahl zwischen ihnen wird durch die Verantwortung der View für die Daten bestimmt.

Die Hauptregel: wenn die View das Objekt erstellt — @StateObject. Wenn die View das Objekt empfängt — @ObservedObject. Die Verletzung dieser Regel durch die Verwendung von @ObservedObject zum Erstellen eines Objekts führt zu Datenverlust, wenn die View neu aufgebaut wird. Die Verletzung durch die Verwendung von @StateObject zum Empfangen eines Objekts erstellt eine doppelte Instanz, die vom Elternteil unabhängig ist.

Beispiele für die Verwendung von @ObservedObject

Ein typisches Anwendungsszenario für @ObservedObject ist eine Aufgabenliste, bei der die Root-View ein View Model erstellt und jede Listen-Zelle es über @ObservedObject erhält. Jede Zelle kann Methoden des View Models aufrufen, und Änderungen werden automatisch in der gesamten Liste widergespiegelt, da alle Zellen dasselbe Objekt beobachten.

struct TaskRow: View {
    @ObservedObject var viewModel: TaskViewModel
    let task: Task
    
    var body: some View {
        HStack {
            Text(task.title)
            Spacer()
            Button("Erledigt") {
                viewModel.completeTask(task)
            }
        }
    }
}

struct TaskListContainer: View {
    @StateObject var viewModel = TaskViewModel()
    
    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(viewModel: viewModel, task: task)
        }
    }
}

In diesem Beispiel erstellt TaskListContainer viewModel über @StateObject, und jede TaskRow erhält es über @ObservedObject. Wenn der Benutzer in einer beliebigen Zeile auf „Done“ drückt, ändert viewModel.completeTask eine veröffentlichte Eigenschaft, und alle Views, die dieses Objekt beobachten, aktualisieren sich automatisch.

Häufige Fehler mit @ObservedObject

Der häufigste Fehler ist die Verwendung von @ObservedObject zum Erstellen eines Objekts innerhalb einer View. Wenn die View neu aufgebaut wird (z. B. bei Zustandsänderung), erstellt SwiftUI eine neue ObservableObject-Instanz, was zum Verlust aller angesammelten Daten führt. Dieser Fehler ist besonders schmerzhaft in NavigationStack, wo ein Benutzer ein Formular ausfüllen und beim Zurücknavigieren Daten verlieren kann.

Fehler: @ObservedObject statt @StateObject

// ❌ Datenverlust: @ObservedObject behält Objekt nicht
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // Neues formVM bei jedem View-Neuaufbau erstellt!
}

// ✅ Richtig: @StateObject behält das Objekt
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // Objekt einmal pro View-Lebensdauer erstellt
}

Fehler: @StateObject übergeben, wo @ObservedObject benötigt wird

Wenn eine untergeordnete View dasselbe ObservableObject über @StateObject deklariert, erstellt sie eine unabhängige Kopie. Änderungen im Eltern-Objekt werden in der untergeordneten View nicht sichtbar sein und umgekehrt. Verwenden Sie immer @ObservedObject für untergeordnete Views, die das Objekt extern erhalten.

Alternativen zu @ObservedObject in SwiftUI

Im modernen SwiftUI gibt es mehrere Alternativen zu @ObservedObject, jede mit ihren eigenen Vorteilen. Die Wahl hängt von der Anwendungsarchitektur, der iOS-Version und dem spezifischen Anwendungsfall ab.

• @EnvironmentObject — ermöglicht das Abrufen eines Objekts aus der SwiftUI-Umgebung, ohne es explizit über den Initialisierer zu übergeben. Praktisch für Objekte, die von vielen Bildschirmen benötigt werden, erfordert jedoch eine explizite Injektion über .environmentObject().
• @State + @Binding — für einfache Werttypen wird kein ObservableObject benötigt. Verwenden Sie @State zum Speichern und @Binding zum Übergeben an untergeordnete Views.
• @AppStorage — für UserDefaults-Werte, die automatisch mit der View synchronisiert werden sollen.
• @SceneStorage — zum Beibehalten des temporären Zustands zwischen Szenenneustarts (z. B. Scrollposition in einer Liste).

Die Wahl zwischen @ObservedObject und @EnvironmentObject ist eine Frage des Stils und der Architektur. @ObservedObject zeigt Abhängigkeiten der View explizit über den Initialisierer, was den Code vorhersehbarer macht. @EnvironmentObject ist praktisch für tiefe Hierarchien, verbirgt jedoch Abhängigkeiten, was das Debuggen erschweren kann.