Home / @Observable vs ObservableObject interview
SwiftUI
@Observable vs ObservableObject interview
This is one of the most current SwiftUI interview questions because Apple's Observation framework changed how state drives views. A senior answer covers both the mechanics and the migration.
How they differ
ObservableObject uses @Published properties and a class conformed to ObservableObject, observed with @StateObject or @ObservedObject; any published change can invalidate every view watching the object. The @Observable macro from the Observation framework tracks which properties a view actually reads, so only views depending on a changed property re-render, reducing unnecessary invalidations.
The migration answer
Explain that @Observable removes the need for @Published and often for @StateObject, replacing it with plain @State for owned models and @Bindable where you need bindings. The senior framing is that the win is finer-grained invalidation and simpler code, while noting deployment-target constraints, since Observation requires recent OS versions.
Go deeper than a summary
Share Your Screen works topics like this through in full: 82 solved Swift problems with tests, 9 case studies (one real round, eight composites), and 7 annotated mock interviews, so you rehearse the live round instead of just reading about it.
Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.
Frequently asked
Why is @Observable better than ObservableObject?
It tracks per-property reads, so only views that use a changed property re-render, cutting unnecessary invalidations and removing @Published boilerplate.
Do I still need @StateObject with @Observable?
Usually no. You hold an @Observable model with @State for ownership and use @Bindable when a view needs two-way bindings to it.