The Hidden Costs of @Observable in Complex Hierarchies

The @Observable macro introduced in Swift 5.9 is a massive improvement over ObservableObject. It provides field-level tracking, meaning a view only updates when the specific property it reads changes. However, in deeply nested hierarchies, the “management” of these observation registrations is not free.

The Hook: The Registration overhead

Every time a view accesses a property on an @Observable class, a “tracking” registration occurs. In a list with 1,000 items, each observing 5 properties, that’s 5,000 registrations that SwiftUI must manage and clean up.

The “Why”: Observation Metadata

Under the hood, @Observable uses a global ObservationRegistrar. This registrar maintains a map of which fields are being watched by which views. While extremely efficient, the lock contention on this global registrar can become noticeable in apps with extremely high-frequency state changes across many threads.

The Implementation: Defensive Observation

To mitigate this, senior engineers avoid “over-observing.” Instead of passing a large @Observable model to every child view, pass only the specific primitive values needed for rendering.

// ❌ SUBOPTIMAL: Every child observes the entire 'User' object
struct UserRow: View {
    let user: User // @Observable class
    var body: some View {
        Text(user.name) // View registers as a listener for 'user.name'
    }
}

// ✅ OPTIMAL: Only the primitive 'String' is passed; no observation needed
struct StaticUserRow: View {
    let name: String
    var body: some View {
        Text(name)
    }
}

By “disconnecting” the view from the observation graph where possible, you reduce the workload on the SwiftUI runtime and the ObservationRegistrar.

The Verdict: Precision vs. Ease of Use

• Pros: Field-level updates (far better than ObservableObject); cleaner syntax.
• Cons: Management overhead in massive hierarchies; global lock contention in edge cases.
• When to use: Most scenarios, but revert to “Static” subviews for long lists or high-frequency updates.

Internal Connectivity

• Foundation: Observable SwiftUI Performance
• Next Step: Micro-optimizing SwiftUI: Custom Equatable

External Resources

• Swift Evolution SE-0395: Observation
• WWDC: Discover Observation in SwiftUI