@ObservedObject in iOS Swift - Deep Dive

Overview - @ObservedObject

What is it?

@ObservedObject is a property wrapper in SwiftUI that lets a view watch an external data source for changes. When the data changes, the view updates automatically to show the new information. It connects a view to a separate object that holds data and logic, keeping UI and data separate but in sync.

Why it matters

Without @ObservedObject, views would not update when data changes outside their own scope, causing the UI to show old or wrong information. This would make apps feel broken or unresponsive. @ObservedObject solves this by linking views to live data sources, so the app always shows the latest state without manual refreshes.

Where it fits

Before learning @ObservedObject, you should understand basic SwiftUI views and state management with @State. After this, you can learn about @StateObject for owning data, and @EnvironmentObject for sharing data across many views. This fits into the bigger topic of reactive UI programming in SwiftUI.

Mental Model

Core Idea

@ObservedObject lets a SwiftUI view watch an external data object and automatically refresh when that data changes.

Think of it like...

It's like having a friend who keeps you updated about their life. You don't control their actions, but whenever something important happens to them, they tell you so you can react accordingly.

View ── observes ──> Data Object
  │                          ▲
  │                          │
  └──── updates automatically ─┘

Build-Up - 7 Steps

1

Foundation

What is @ObservedObject in SwiftUI

Concept: Introducing @ObservedObject as a way for views to watch external data objects.

In SwiftUI, views can use @ObservedObject to connect to a class that conforms to ObservableObject. This class holds data and can notify views when data changes. The view then redraws itself to show the new data.

Result

The view updates automatically when the observed data changes.

Understanding that @ObservedObject links a view to an external data source is key to building dynamic interfaces.

2

Foundation

ObservableObject and @Published Basics

Concept: How ObservableObject and @Published work together to notify views.

A class marked ObservableObject can have properties marked with @Published. When these properties change, the class sends a signal. Views observing this class with @ObservedObject listen for these signals and update.

Result

Changing a @Published property triggers view updates automatically.

Knowing that @Published properties inside ObservableObject trigger updates helps you design reactive data models.

3

Intermediate

Using @ObservedObject in a SwiftUI View

🤔Before reading on: Do you think @ObservedObject creates or owns the data object, or just watches it? Commit to your answer.

Concept: @ObservedObject watches an existing data object but does not create or own it.

You declare a property in your view with @ObservedObject var model: YourModel. The model is created outside the view and passed in. The view listens to changes but does not manage the model's lifecycle.

Result

The view updates when model changes, but the model lives outside the view.

Understanding ownership clarifies when to use @ObservedObject versus @StateObject.

4

Intermediate

Difference Between @ObservedObject and @StateObject

🤔Before reading on: Which property wrapper do you think should be used when the view creates the data object? @ObservedObject or @StateObject? Commit to your answer.

Concept: @StateObject owns and creates the data object; @ObservedObject only watches an existing one.

@StateObject is used when the view creates and owns the data object, ensuring it stays alive. @ObservedObject is for watching objects created elsewhere. Using @ObservedObject to create an object can cause bugs because the object may be recreated unexpectedly.

Result

Choosing the right wrapper prevents data loss and unexpected behavior.

Knowing the ownership difference prevents common bugs with data lifecycle in SwiftUI.

5

Intermediate

Passing @ObservedObject Between Views

Concept: How to share an ObservableObject between multiple views using @ObservedObject.

You can create an ObservableObject in a parent view with @StateObject and pass it down to child views as @ObservedObject. This way, all views watch the same data source and update together.

Result

Multiple views stay in sync with shared data changes.

Sharing data with @ObservedObject enables coordinated UI updates across views.

6

Advanced

Avoiding Common @ObservedObject Pitfalls

🤔Before reading on: What happens if you use @ObservedObject to create a new data object inside a view? Commit to your answer.

Concept: Using @ObservedObject to create data causes the object to be recreated on every view update, losing state.

Because @ObservedObject expects an existing object, creating one inside the view means it resets every time the view redraws. This causes data loss and UI glitches. Instead, create the object outside or use @StateObject if the view owns it.

Result

Proper use prevents unexpected resets and keeps data stable.

Understanding lifecycle management is crucial to avoid subtle bugs with @ObservedObject.

7

Expert

How @ObservedObject Works with Combine Framework

🤔Before reading on: Do you think @ObservedObject uses notifications, delegates, or Combine publishers to detect changes? Commit to your answer.

Concept: @ObservedObject uses Combine publishers under the hood to listen for changes from ObservableObject.

ObservableObject protocol requires a publisher called objectWillChange. When @Published properties change, they send events through this publisher. @ObservedObject subscribes to this publisher and triggers view updates when it emits events.

Result

SwiftUI views react instantly to data changes via Combine's reactive streams.

Knowing the Combine integration reveals how SwiftUI achieves efficient, reactive UI updates.

Under the Hood

@ObservedObject subscribes to the ObservableObject's objectWillChange publisher from the Combine framework. When any @Published property changes, the ObservableObject emits an event. The subscription triggers SwiftUI to re-render the view. This subscription is managed automatically by SwiftUI, ensuring updates happen only when needed.

Why designed this way?

SwiftUI uses Combine to unify reactive programming and UI updates in a declarative way. This design allows views to stay simple and stateless, while data changes flow through a standard publisher-subscriber model. Alternatives like manual callbacks or notifications were more error-prone and less efficient.

┌───────────────┐       subscribes to       ┌─────────────────────┐
│ SwiftUI View  │ ─────────────────────────>│ ObservableObject     │
│ (@ObservedObj)│                           │ (with @Published)    │
└───────────────┘                           └─────────────────────┘
         │                                            ▲
         │                                            │
         └───────── triggers view update on event ───┘

Myth Busters - 4 Common Misconceptions

Quick: Does @ObservedObject create and own the data object it watches? Commit yes or no.

Common Belief: @ObservedObject creates and owns the data object inside the view.

Reality: @ObservedObject only watches an existing data object created elsewhere; it does not own or create it.

Why it matters: Misusing @ObservedObject to create data causes the object to be recreated on every view update, losing all stored data and causing UI glitches.

Quick: Does changing any property in an ObservableObject always update the view? Commit yes or no.

Common Belief: Any change in the ObservableObject triggers the view to update.

Reality: Only changes to properties marked with @Published send update signals; other changes do not trigger view refresh.

Why it matters: Not marking properties with @Published can cause the UI to not update, leading to stale or incorrect displays.

Quick: Can @ObservedObject be used to share data across many unrelated views easily? Commit yes or no.

Common Belief: @ObservedObject is the best way to share data across many views in an app.

Reality: @ObservedObject is for watching data passed directly to a view; @EnvironmentObject is better for sharing data widely across many views without manual passing.

Why it matters: Using @ObservedObject for wide data sharing leads to complex code and manual passing, increasing bugs and maintenance.

Quick: Does @ObservedObject always cause the entire view to redraw on any data change? Commit yes or no.

Common Belief: @ObservedObject causes the whole view to redraw on any change.

Reality: SwiftUI intelligently updates only the parts of the view that depend on the changed data, minimizing redraw cost.

Why it matters: Believing the whole view redraws can lead to unnecessary performance worries and premature optimization.

Expert Zone

1

Using @ObservedObject with classes that have complex internal state requires careful management to avoid inconsistent UI updates.

2

Combining @ObservedObject with other state wrappers like @State and @EnvironmentObject can cause subtle update order issues if not designed carefully.

3

The objectWillChange publisher can be customized to batch multiple changes into a single update, improving performance in complex models.

When NOT to use

@ObservedObject is not suitable when the view owns the data object; use @StateObject instead. For global app-wide data sharing, prefer @EnvironmentObject. For simple local state, use @State. Avoid @ObservedObject for immutable data or data that does not change.

Production Patterns

In production apps, @ObservedObject is often used to inject view models created by dependency injection frameworks. It enables MVVM architecture by separating UI from business logic. Developers also combine it with Combine operators to transform and debounce data streams before updating views.

Connections

Observer Pattern (Software Design)

Same pattern

Understanding @ObservedObject as a modern SwiftUI implementation of the observer pattern helps grasp how views react to data changes automatically.

Reactive Programming

Builds-on

Knowing reactive programming concepts clarifies how @ObservedObject uses Combine publishers to propagate changes efficiently.

Human Attention and Notifications

Analogy to real life

Just like people pay attention to notifications from friends or apps to stay updated, @ObservedObject lets views listen for data changes to stay current.

Common Pitfalls

#1 Creating the ObservableObject inside a view using @ObservedObject causes data loss.

Wrong approach:

struct MyView: View {
@ObservedObject var model = MyModel()
var body: some View { Text(model.text) }
}

Correct approach:

struct MyView: View {
@ObservedObject var model: MyModel
var body: some View { Text(model.text) }
}
// Create MyModel outside and pass it in

Root cause:

Misunderstanding that @ObservedObject does not own the data object and recreating it on every view update resets state.

#2 Not marking properties with @Published inside ObservableObject prevents view updates.

Wrong approach:

class MyModel: ObservableObject {
var text = "Hello"
}

Correct approach:

class MyModel: ObservableObject {
@Published var text = "Hello"
}

Root cause:

Forgetting that only @Published properties send change notifications to views.

#3 Passing ObservableObject to many views without @EnvironmentObject leads to complex code.

Wrong approach:

Passing the same ObservableObject manually through many view initializers using @ObservedObject.

Correct approach:

Use @StateObject in a parent and @EnvironmentObject in child views for easier data sharing.

Root cause:

Not using the right property wrapper for wide data sharing increases boilerplate and error risk.

Key Takeaways

@ObservedObject connects a SwiftUI view to an external data object that can change over time.

It listens to changes from ObservableObject classes that use @Published properties to notify updates.

@ObservedObject does not create or own the data; it only watches it, so ownership matters.

Using @ObservedObject incorrectly can cause data loss or stale UI, so understanding lifecycle is crucial.

Under the hood, @ObservedObject uses Combine publishers to efficiently update views reactively.

Practice

1. What is the main purpose of using @ObservedObject in a SwiftUI view?

easy

A. To watch an external data object and update the view when it changes

B. To create a new data object inside the view

C. To store a constant value that never changes

D. To handle user input events like taps and swipes

Solution

1. Step 1: Understand the role of @ObservedObject

   @ObservedObject is used to watch an external data object for changes.

2. Step 2: Connect data changes to UI updates

   When the observed object changes, the SwiftUI view automatically updates to reflect those changes.

3. Final Answer:

   To watch an external data object and update the view when it changes -> Option A

4. Quick Check:

   @ObservedObject = watch external data [OK]

Hint: Remember: @ObservedObject watches data outside the view [OK]

Common Mistakes:

• Confusing @ObservedObject with @State which owns data inside the view
• Thinking @ObservedObject creates new data instead of observing
• Using @ObservedObject for constant values

2. Which of the following is the correct way to declare an observed object in a SwiftUI view?

easy

A. @ObservedObject var model: MyModel

B. @ObservedObject var model: MyModel = MyModel()

C. @ObservedObject model = MyModel()

D. @ObservedObject var model: MyModel?

Solution

1. Step 1: Understand @ObservedObject declaration

   @ObservedObject properties are typically declared without initialization in the view, expecting the instance to be injected.

2. Step 2: Check syntax correctness

   @ObservedObject var model: MyModel is the correct declaration; initializing it inside the view is not recommended.

3. Final Answer:

   @ObservedObject var model: MyModel -> Option A

4. Quick Check:

   Declare @ObservedObject without initialization for injection [OK]

Hint: Declare @ObservedObject properties without initializing inside the view [OK]

Common Mistakes:

• Initializing @ObservedObject inside the view
• Omitting the var keyword
• Using optional type without proper handling

3. Given the code below, what will be the output when the button is tapped?

class Counter: ObservableObject {
  @Published var count = 0
}

struct ContentView: View {
  @ObservedObject var counter = Counter()
  var body: some View {
    VStack {
      Text("Count: \(counter.count)")
      Button("Increment") {
        counter.count += 1
      }
    }
  }
}

medium

A. The app crashes due to missing @State

B. The text never updates and stays at 0

C. The text updates to show the incremented count each tap

D. The button does not respond to taps

Solution

1. Step 1: Understand @Published and @ObservedObject interaction

   The Counter class publishes changes to its count property.

2. Step 2: Observe how the view updates

   The ContentView observes the counter object, so when count changes, the Text updates automatically.

3. Final Answer:

   The text updates to show the incremented count each tap -> Option C

4. Quick Check:

   @Published + @ObservedObject = UI updates [OK]

Hint: @Published properties trigger view updates via @ObservedObject [OK]

Common Mistakes:

• Thinking @ObservedObject alone updates UI without @Published
• Confusing @State with @ObservedObject
• Assuming UI updates require manual refresh

4. Identify the error in this SwiftUI view using @ObservedObject:

class TimerModel: ObservableObject {
  @Published var time = 0
}

struct TimerView: View {
  @ObservedObject var timer: TimerModel
  var body: some View {
    Text("Time: \(timer.time)")
  }
}

medium

A. The TimerModel class is missing ObservableObject conformance

B. The @ObservedObject property is not initialized

C. The @Published property should be private

D. The Text view syntax is incorrect

Solution

1. Step 1: Check class conformance

   TimerModel correctly conforms to ObservableObject.

2. Step 2: Check @ObservedObject initialization

   The timer property is declared but not initialized, causing a compile error.

3. Final Answer:

   The @ObservedObject property is not initialized -> Option B

4. Quick Check:

   @ObservedObject must be initialized or injected [OK]

Hint: Always initialize or inject @ObservedObject properties [OK]

Common Mistakes:

• Forgetting to initialize @ObservedObject
• Assuming @Published must be private
• Misreading Text string interpolation

5. You have a parent view that creates a Settings object and passes it to two child views. Which is the best way to share this data so both children update when settings change?

hard

A. Use @EnvironmentObject in children without passing from parent

B. Create separate @ObservedObject instances in each child view

C. Use @State in the parent and @Binding in children for the settings

D. Declare @ObservedObject in both child views and pass the same Settings instance from the parent

Solution

1. Step 1: Understand data sharing with @ObservedObject

   Passing the same instance to children with @ObservedObject keeps them in sync.

2. Step 2: Evaluate other options

   Creating separate instances duplicates data; @State/@Binding is for simple values; @EnvironmentObject requires environment setup.

3. Final Answer:

   Declare @ObservedObject in both child views and pass the same Settings instance from the parent -> Option D

4. Quick Check:

   Share one @ObservedObject instance for synced updates [OK]

Hint: Pass one @ObservedObject instance to children for shared updates [OK]

Common Mistakes:

• Creating multiple instances causing unsynced data
• Confusing @Binding with @ObservedObject for complex objects
• Using @EnvironmentObject without setup