SwiftUI8 min read

Mastering @ObservedObject in SwiftUI: Dynamic Data for Your Views

SwiftUI's @ObservedObject property wrapper is a cornerstone for managing dynamic, mutable data within your views that comes from an external source. It allows your views to react to changes in reference types conforming to the ObservableObject protocol. Understanding its nuances is key to building responsive and efficient SwiftUI applications.

Introduction to @ObservedObject and ObservableObject

In SwiftUI, managing dynamic data effectively is crucial for building interactive user interfaces. For value types, @State and @Binding are excellent choices. However, when you need to manage complex, shared, or external data that is a reference type, SwiftUI provides @ObservedObject in tandem with the ObservableObject protocol.

A class that conforms to ObservableObject can broadcast changes to its properties. When these properties are marked with @Published, the ObservableObject automatically emits change notifications. @ObservedObject then listens for these notifications and triggers a redraw of the view hierarchy that depends on the published property.

Why use @ObservedObject?

@ObservedObject is designed for data that is owned and managed externally to the view that's observing it. You're typically passed an instance of an ObservableObject from a parent view or the environment. When the observed object changes, the view invalidates its body and re-renders, displaying the latest data.

Defining an ObservableObject

To use @ObservedObject, you first need a class that conforms to the ObservableObject protocol. This protocol has no required methods or properties; its power comes from its combination with the @Published property wrapper. Any property within an ObservableObject class that is marked with @Published will automatically notify subscribers whenever its value changes.

Let's consider a simple UserSettings class that tracks a user's name and a preference for dark mode.

swift

import Foundation
import Combine

class UserSettings: ObservableObject {
    @Published var username: String = "Guest"
    @Published var isDarkModeEnabled: Bool = false
    
    init(username: String = "Guest", isDarkModeEnabled: Bool = false) {
        self.username = username
        self.isDarkModeEnabled = isDarkModeEnabled
        print("UserSettings initialized")
    }
    
    deinit {
        print("UserSettings deinitialized")
    }
}

In this example, whenever username or isDarkModeEnabled changes, any view observing an instance of UserSettings will be re-drawn. The init and deinit print statements will be useful for understanding the lifecycle later.

swift

import Foundation
import Combine

class UserSettings: ObservableObject {
    @Published var username: String = "Guest"
    @Published var isDarkModeEnabled: Bool = false
    
    init(username: String = "Guest", isDarkModeEnabled: Bool = false) {
        self.username = username
        self.isDarkModeEnabled = isDarkModeEnabled
        print("UserSettings initialized")
    }
    
    deinit {
        print("UserSettings deinitialized")
    }
}

Using @ObservedObject in a SwiftUI View

Once you have an ObservableObject, you can use @ObservedObject in a SwiftUI view to establish a connection. You initialize the @ObservedObject by passing an existing instance of your ObservableObject into the view from a parent.

Here's how you might use UserSettings in a ProfileView:

swift

import SwiftUI

struct ProfileView: View {
    @ObservedObject var settings: UserSettings
    
    var body: some View {
        Form {
            Section("User Profile") {
                TextField("Username", text: $settings.username)
                    .autocorrectionDisabled()
                Toggle("Dark Mode", isOn: $settings.isDarkModeEnabled)
            }
            
            Text("Current Username: \(settings.username)")
                .fontWeight(.medium)
            Text("Dark Mode status: \(settings.isDarkModeEnabled ? "Enabled" : "Disabled")")
                .font(.footnote)
                .foregroundColor(.secondary)
        }
        .navigationTitle("Edit Profile")
    }
}

struct ContentView: View {
    // A parent view creating and owning the UserSettings instance
    // For a top-level view, consider @StateObject.
    // Here, we're simulating a scenario where a parent view passes it down.
    @State private var userSettings = UserSettings(username: "Alice", isDarkModeEnabled: true)
    
    var body: some View {
        NavigationView {
            VStack {
                Text("Welcome, \(userSettings.username)!")
                    .font(.largeTitle)
                
                NavigationLink(destination: ProfileView(settings: userSettings)) {
                    Text("Go to Profile")
                }
                .padding()
            }
        }
    }
}

In this setup, ContentView creates and owns the UserSettings instance (using @State for demonstration purposes, though @StateObject would be more appropriate for ownership within ContentView itself). It then passes this instance to ProfileView. ProfileView declares @ObservedObject var settings: UserSettings, indicating that it expects an instance to be provided and that it wants to react to changes within that instance.

Key takeaway for @ObservedObject: The view using @ObservedObject does not create or own the instance of the ObservableObject. It merely observes an existing instance passed to it.

swift

import SwiftUI

struct ProfileView: View {
    @ObservedObject var settings: UserSettings
    
    var body: some View {
        Form {
            Section("User Profile") {
                TextField("Username", text: $settings.username)
                    .autocorrectionDisabled()
                Toggle("Dark Mode", isOn: $settings.isDarkModeEnabled)
            }
            
            Text("Current Username: \(settings.username)")
                .fontWeight(.medium)
            Text("Dark Mode status: \(settings.isDarkModeEnabled ? "Enabled" : "Disabled")")
                .font(.footnote)
                .foregroundColor(.secondary)
        }
        .navigationTitle("Edit Profile")
    }
}

struct ContentView: View {
    // A parent view creating and owning the UserSettings instance
    // For a top-level view, consider @StateObject.
    // Here, we're simulating a scenario where a parent view passes it down.
    @State private var userSettings = UserSettings(username: "Alice", isDarkModeEnabled: true)
    
    var body: some View {
        NavigationView {
            VStack {
                Text("Welcome, \(userSettings.username)!")
                    .font(".largeTitle")
                
                NavigationLink(destination: ProfileView(settings: userSettings)) {
                    Text("Go to Profile")
                }
                .padding()
            }
        }
    }
}

The Lifecycle of @ObservedObject

Understanding the lifecycle of @ObservedObject is crucial to avoid common pitfalls. Unlike @StateObject, @ObservedObject does not own the object it observes. This means that if the view containing @ObservedObject is re-created (for example, due to a parent view updating), and a new instance of the ObservableObject is passed in, the @ObservedObject will update to observe the new instance. Crucially, if the ObservableObject instance itself is re-created by its owner, the @ObservedObject will receive a new instance.

When a view using @ObservedObject is instantiated, the property wrapper is set with the provided ObservableObject instance. As long as this instance remains the same, changes to its @Published properties will trigger view updates.

The Problematic Case: View Re-creation

Consider the ContentView example again. If userSettings in ContentView was declared with just @State var userSettings = UserSettings() (without StateObject), and ContentView itself was prone to re-creation (e.g., due to its parent updating and calling its initializer), then a new UserSettings instance would be created every time ContentView re-initialized userSettings. This would lead to @ObservedObject in ProfileView observing a new object, losing state. This is why @StateObject was introduced in iOS 14.

Compatibility: @ObservedObject is available from iOS 13.0+, macOS 10.15+, tvOS 13.0+, watchOS 6.0+. @StateObject is available from iOS 14.0+, macOS 11.0+, tvOS 14.0+, watchOS 7.0+.

@ObservedObject is typically used when:

The ObservableObject is created and owned by a parent view using @StateObject or a factory method, and then passed down the view hierarchy.
The ObservableObject is a global singleton or managed externally (e.g., by a DI container).
The ObservableObject is provided by the environment using @EnvironmentObject.

@ObservedObject owns its object.

Becoming a stronger iOS Engineer

THE MYTH or PROBLEM: @ObservedObject owns its object.

Many developers incorrectly assume that a view declares and owns its @ObservedObject, leading to unexpected state loss or re-initialization upon view re-creation. This is a common source of bugs and inefficient code in SwiftUI.

swift

struct MyView: View {
    // Problem: If MyView is re-created, UserSettings gets re-initialized!
    @ObservedObject var settings = UserSettings() 
    var body: some View { ... }
}

WHAT HAPPENS INTERNALLY?

`@ObservedObject` creates a subscription to the `objectWillChange` publisher of the `ObservableObject` instance it's initialized with. When this publisher emits, SwiftUI invalidates the view's body, triggering a re-render. Crucially, if the view itself is re-created, and a *new* instance of the `ObservableObject` is passed in, `@ObservedObject` will simply observe the new instance.

AppRootView (@StateObject or static)

ParentView (Passes ObservedObject)

ChildView (@ObservedObject)

1. Parent Initializes Object

A parent view or external source creates an `ObservableObject` instance.

2. Child View Instantiated

A child view is created, receiving the *existing* `ObservableObject` instance.

3. @ObservedObject Set

The `@ObservedObject` property wrapper is given the external instance to observe.

4. Property Changes Broadcast

An `@Published` property within the `ObservableObject` changes, emitting `objectWillChange`.

5. View Updates

The observing view is re-rendered with the new data.

Visualized execution hierarchy.

Powerful Guarantees

Automatic View Updates

Any changes to `@Published` properties in an `ObservableObject` automatically trigger re-renders of observing views.

Reference Semantic Observation

Ensures views observe changes on a shared instance of data, suitable for complex models and external dependencies.

Cooperative Design

Works seamlessly with `ObservableObject` and its `objectWillChange` publisher.

REAL PRODUCTION EXAMPLE: Shared User Session Data

Imagine an authentication manager (`AuthService`) that needs to be accessed and observed across multiple views in an application. If this was declared with `@ObservedObject` in a top-level view, it would re-initialize if the view was re-created, leading to lost session state.

Impact / Results

Lost authentication token on view re-creation

Required re-login for users

Inconsistent UI state (e.g., 'Logged In' button when logged out)

THE FIX or SOLUTION: Use @StateObject for ownership

swift

class AuthService: ObservableObject {
    @Published var isAuthenticated: Bool = false
    func login() { /* ... */ isAuthenticated = true }
    func logout() { /* ... */ isAuthenticated = false }
}

struct AppRootView: View {
    // AppRootView OWNS and PERSISTS the AuthService instance
    @StateObject var authService = AuthService()
    
    var body: some View {
        Group {
            if authService.isAuthenticated {
                MainContentView()
                    .environmentObject(authService) // Provide via environment
            } else {
                LoginView(authService: authService) // Pass directly
            }
        }
    }
}

struct LoginView: View {
    // LoginView OBSERVES the EXISTING AuthService from AppRootView
    @ObservedObject var authService: AuthService
    
    var body: some View {
        // ... UI to call authService.login()
    }
}

struct ProfileView: View {
    // Also observe the shared AuthService, perhaps via EnvironmentObject
    @EnvironmentObject var authService: AuthService 
    
    var body: some View {
        Text("Auth Status: \(authService.isAuthenticated ? "Authenticated" : "Not authenticated")")
    }
}

INTERVIEW PERSPECTIVE

Common Question

“Explain the difference between @ObservedObject and @StateObject and when to use each.”

Strong Answer

A strong answer should highlight that `@StateObject` is for *ownership* and *persistence* of an `ObservableObject` instance across view updates and re-creations, making it ideal for the source of truth in a view or its subtree. `@ObservedObject` is for *observing* an existing `ObservableObject` that is *owned externally* (e.g., by a parent `@StateObject` or `EnvironmentObject`). Using `@ObservedObject` where `@StateObject` is needed typically leads to data loss upon view re-render, as a new object instance would be created.

Interviewers Expect you to understand:

Ownership vs. Observation
Lifecycle management by SwiftUI
Preventing state loss on view re-creation
Usage scenarios for passing data down vs. owning data
Mentions of `ObservableObject` and `@Published`

KEY TAKEAWAY

Use `@StateObject` to *own* and *persist* an `ObservableObject` within a view's lifecycle. Use `@ObservedObject` when you need to *observe* an `ObservableObject` that is *created and owned elsewhere* (e.g., from a parent view or the environment). Choose `ObservedObject` for data flowing *into* a view, not data created *by* the view.

Common Interview Questions

What is the main difference between @ObservedObject and @StateObject?

The primary difference lies in ownership and lifecycle. `@StateObject` *owns* the instance of `ObservableObject` it wraps and ensures it persists for the lifetime of the view (or its SwiftUI identity). `@ObservedObject` *does not* own the object; it merely observes an existing instance that is passed to it. If the parent view re-creates the observed object, `@ObservedObject` will observe the new instance, potentially losing prior state, whereas `@StateObject` would preserve its original instance.

When should I use @ObservedObject instead of @StateObject?

Use `@ObservedObject` when a view needs to observe an `ObservableObject` instance that is created and owned by another source, typically a parent view (using `@StateObject`), an external data manager, or `EnvironmentObject`. It's ideal for passing down shared data or dependencies through the view hierarchy.

Can I use @ObservedObject with structs?

No, `@ObservedObject` (and `ObservableObject`) are exclusively for reference types (classes). For managing state in value types (structs), you should use `@State` or `@Binding`.

What happens if the ObservableObject is nil, or becomes nil?

`@ObservedObject` requires a non-optional instance of an `ObservableObject`. If you try to pass `nil`, it will result in a runtime error or a compiler error if the type is explicitly optional. If the object being observed somehow becomes invalid or deallocated while a view is still observing it, this would lead to a crash or undefined behavior, emphasizing the importance of proper lifecycle management by the object's owner.

How do I make a property within my ObservableObject trigger view updates?

To make a property within your `ObservableObject` trigger view updates, you must mark it with the `@Published` property wrapper. These properties automatically synthesize the necessary `objectWillChange` publisher notifications.

#SwiftUI#ObservedObject#ObservableObject#Property Wrappers#Data Flow#iOS Development