# **The Evolution of State Management in Declarative UI: Migrating from ObservableObject to the Swift Observation Framework**

The move from the Combine‑based **ObservableObject** protocol to Swift’s native **Observation** framework is a fundamental shift for SwiftUI. For years, state updates were driven by a push‑based invalidation model where objects broadcast generic change signals that trigger broad view re‑evaluations. This worked for small apps but struggled at scale, especially with large lists, nested reference models, and complex data dependencies. With the **@Observable** macro in Swift 5.9, the model becomes pull‑based and access tracked, giving precise invalidation, cleaner architecture, and better performance by default.

## **Historical Context: Limits of the Combine Era**

The **ObservableObject** protocol relied on Combine’s publishers, especially the synthesized **objectWillChange** stream from **@Published** properties. When a published property is mutated, the object sends a change event before the actual value update, notifying subscribers that it is about to enter a dirty state. See [Apple Developer: Migrating from ObservableObject to Observable](https://developer.apple.com/documentation/SwiftUI/Migrating-from-the-observable-object-protocol-to-the-observable-macro).

In practice, a view subscribing to an observable instance—whether via **@ObservedObject**, **@StateObject**, or **@EnvironmentObject**—depends on the entire object rather than specific properties. Consider a profile view where the header displays a username and the footer shows a high‑frequency **downloadProgress**. Each progress tick invalidates the entire view hierarchy, forcing unrelated areas like the header to re‑evaluate. See [SwiftLee: Performance increase with @Observable](https://www.avanderlee.com/swiftui/observable-macro-performance-increase-observableobject/).

This over‑invalidation led teams to fragment view models into smaller units to isolate updates, often at odds with domain‑driven design. A common structural flaw involved nested observable objects: a parent view model referencing a child **ObservableObject** would not automatically forward the child’s changes to the parent’s **objectWillChange**. Changes in the child were invisible to views bound to the parent unless developers wrote manual forwarding code.

![Observable-1.jpg](https://api.flyingharley.dev/uploads/Observable_1_c57e56fccd.jpg)

## **Legacy Workaround for Nested Objects**

When a parent holds a child **ObservableObject**, the parent does not automatically forward changes from the child. Developers implemented glue code by subscribing to the child’s **objectWillChange** and piping it to the parent’s publisher. See [Swift Forums: Observing nested ObservableObject](https://forums.swift.org/t/what-is-the-correct-way-to-observe-the-changes-from-within-a-nested-observableobject/62788).

```swift

// Manual forwarding of nested changes
class ParentViewModel: ObservableObject {
    @Published var child: ChildViewModel
    var cancellables = Set<AnyCancellable>()

    init(child: ChildViewModel) {
        self.child = child
        child.objectWillChange
            .sink { [weak self] _ in
                self?.objectWillChange.send()
            }
            .store(in: &cancellables)
    }
}
```
This code adds complexity and can introduce leaks if cancellables are mismanaged. It also dilutes the idea of a single source of truth because synchronization becomes manual and error‑prone. See [Stack Overflow: Bind to nested ObservableObjects](https://stackoverflow.com/questions/58406287/how-to-tell-swiftui-views-to-bind-to-nested-observableobjects).

![Observable-2.jpg](https://api.flyingharley.dev/uploads/Observable_2_ff96d34653.jpg)

## **Mechanics of Observation: A Deep Dive**

The Observation framework abandons Combine publishers and uses compiler‑generated access tracking. The **@Observable** macro expands a class into an observable type with a private storage backing and computed properties that intercept reads and writes through an **ObservationRegistrar**.

```swift

@Observable class UserViewModel {
    var name: String = "Guest"
}

// Conceptual expansion (simplified)
class UserViewModel: Observable {
    @ObservationIgnored private let _$observationRegistrar = ObservationRegistrar()
    @ObservationIgnored private var _name: String = "Guest"

    var name: String {
        get {
            _$observationRegistrar.access(self, keyPath: \.name)
            return _name
        }
        set {
            _$observationRegistrar.withMutation(of: self, keyPath: \.name) {
                _name = newValue
            }
        }
    }
}
```
During a render, SwiftUI installs a tracking scope. When a view reads **viewModel.name**, the getter records the dependency. When **name** changes, the registrar invalidates exactly the views that read that key path, and nothing else. This is the core of granular invalidation and explains the performance wins on lists and complex hierarchies.

![Observable-3.jpg](https://api.flyingharley.dev/uploads/Observable_3_c1bd3d070d.jpg)

To opt out of observation for internal or non‑UI fields, use **@ObservationIgnored**. This keeps the registrar from tracking churn on values that never drive UI. See [Donny Wals: Observable in SwiftUI](https://www.donnywals.com/observable-in-swiftui-explained/).

### **ObservationRegistrar: The Engine of State**

The **ObservationRegistrar** is the thread‑safe core that manages access tracking and invalidation. During the access phase, when a view evaluates its body, a tracking scope is installed. Each property read calls **access(self, keyPath:)** and the registrar records a precise dependency between the active scope and the specific key path of the specific instance being read. During mutation, setters call **withMutation(of:keyPath:)**. The registrar looks up the exact scopes registered for that key path and triggers their invalidation closures. Views that did not read that property are not notified and do not re‑evaluate. This selective behavior is the foundation for property‑level granularity and improved performance. See [Apple Docs: ObservationRegistrar](https://developer.apple.com/documentation/observation/observationregistrar).

Thread safety is provided by internal locking around registration and invalidation so concurrent reads and writes remain consistent. UI mutations must still occur on the main actor to respect SwiftUI’s threading rules. When views leave the hierarchy, SwiftUI tears down their scopes and the registrar drops the associated dependencies, keeping memory safe in normal usage. For manual scopes created with **withObservationTracking**, ensure the scope is released or a subsequent mutation occurs to allow the change closure to fire and the dependency to be cleaned up. See community analysis such as [Jano.dev: Observation Framework](https://jano.dev/apple/swiftui/2024/12/13/Observation-Framework.html).

![Observable-4.jpg](https://api.flyingharley.dev/uploads/Observable_4_f088145b73.jpg)

## **Structural Migration in MVVM**

Moving from **ObservableObject** to **@Observable** changes how view models are owned, passed, and injected. The taxonomy of wrappers simplifies significantly. The old **@StateObject** becomes **@State** for ownership and lifecycle. The old **@ObservedObject** becomes a plain property for dependency. The old **@EnvironmentObject** becomes **@Environment** for injection. **@Published** is no longer needed because stored properties of **@Observable** types are tracked by default.

Each mapping carries a clear role. **@State** owns the instance and manages its lifecycle within the view. A plain reference (let or var) expresses a dependency that is created elsewhere and passed in, and reading properties in the body establishes observation implicitly. **@Environment** retrieves shared instances from the environment hierarchy. Removal of **@Published** reduces boilerplate because observation is opt‑out rather than opt‑in.

A dangerous change involves the swap from **@StateObject** to **@State**. **@StateObject** initialized lazily and only once per view lifecycle, while **@State** initializes eagerly when the struct initializes. If an initializer performs heavy work, that work might run more often than expected, even if the state instance is ultimately preserved by SwiftUI. See [Jesse Squires: Observable macro is not drop‑in](https://www.jessesquires.com/blog/2024/09/09/swift-observable-macro/) and [Swift Forums: init called multiple times with @State](https://forums.swift.org/t/observable-init-called-multiple-times-by-state-different-behavior-to-stateobject/70811).

Mitigation is straightforward. Keep initializers light and move heavy setup into methods triggered by **.task** or **.onAppear**. When appropriate, initialize optional state and populate it lazily inside a task. This keeps startup fast and avoids repeated heavy work.

```swift

// Lightweight state ownership and deferred work
@State private var model: MyModel?

var body: some View {
    Group {
        // ... UI ...
    }
    .task {
        if model == nil { model = MyModel() }
        await model?.load()
    }
}
```

![Observable-5.jpg](https://api.flyingharley.dev/uploads/Observable_5_7554f3fff6.jpg)

Passing observable models implicitly establishes observation. Any property read inside **body** or helpers called by **body** creates a subscription. For read–write access in child views, wrap the model in **@Bindable** to project bindings. A view that owns state via **@State** gets bindings automatically with the dollar prefix; a view that receives a model must create a bindable proxy.

```swift

struct EditView: View {
    @Bindable var model: UserViewModel

    var body: some View {
        Form {
            TextField("Name", text: $model.name)
            Toggle("Active", isOn: $model.isActive)
        }
    }
}
```
## **Nested Object Revolution**

The nested object problem disappears with **@Observable**. If a view reads **viewModel.user.address.city**, and **Address** is observable, the dependency is registered on that exact property of that exact instance. There is no need to wire **objectWillChange** manually, and domain‑driven modeling becomes natural again. See [Holy Swift: Solving nested observables](https://holyswift.app/how-to-solve-observable-object-problem/).

```swift

@Observable class Inner { var val = 0 }
@Observable class Outer { var inner = Inner() }
// Reading outer.inner.val triggers updates exactly where needed.
```

![Observable-6.jpg](https://api.flyingharley.dev/uploads/Observable_6_aa9f934a88.jpg)


## **Performance Internals**

Granularity transforms invalidation costs. In the legacy model, the cost of updates grows with the number of views observing an object multiplied by the frequency of any property change on that object. In the modern model, the cost grows with the number of views that read a specific property multiplied by the frequency of that property’s change. This is why unrelated views stop recomputing and lists scale dramatically. See [SwiftLee: Performance increase with @Observable](https://www.avanderlee.com/swiftui/observable-macro-performance-increase-observableobject/).

Large collections benefit greatly. A list of tens of thousands of items can update a single row without disturbing the others. When item **#42** changes, only the view that read **item[42]** invalidates; the parent that reads the array reference does not rerender because the reference and count are unchanged. See [Medium: Deep understanding of SwiftUI List](https://medium.com/@yildirimpost/deep-understanding-of-swiftui-list-ddd96ad57147).

![Observable-7.jpg](https://api.flyingharley.dev/uploads/Observable_7_f478dcf46d.jpg)

Subtle memory risks remain. Complex derived properties may introduce strong reference cycles if they capture **self** in closures. Observation itself is thread‑safe via internal locking, but UI mutations must still occur on the main actor. Lifecycle teardown of views cleans tracking scopes automatically.

## **Bridging the Reactive Gap**

The loss of automatic **\$** publishers breaks Combine‑based side effects like debouncing and throttling. In **@Observable** types, the **\$** syntax inside views projects a binding rather than a publisher, so operators like **debounce** and **sink** cannot be used directly. Prefer Swift Concurrency with **.task(id:)** in views for debounce and cancellation semantics. 

```Swift

struct SearchView: View {
    @State private var viewModel = SearchViewModel()

    // Debounce search queries for 0.5 seconds  
    var body: some View {
        TextField("Search", text: $viewModel.query)
            .task(id: viewModel.query) {
                try? await Task.sleep(for: .seconds(0.5))
                await viewModel.performSearch()
            }
    }
}
```

When logic must live inside view models, use an actor‑backed debouncer to serialize work safely.

```Swift
actor SearchDebouncer {
    private var currentTask: Task<Void, Error>?

    // Submit a search query, debouncing previous submissions.
    func submit(query: String, action: @escaping (String) async -> Void) {
        currentTask?.cancel()
        currentTask = Task {
            // Throw error if the task is canceled before the delay.
            try await Task.sleep(for: .seconds(0.5))
            await action(query)
        }
    }
}
```

For complex pipelines that depend on Combine operators such as **combineLatest**, **flatMap**, or **merge**, expose manual publishers from observable models while keeping UI observation on **@Observable**. 

See guidance and discussion in [Donny Wals: Observable in SwiftUI](https://www.donnywals.com/observable-in-swiftui-explained/), [Swift Forums: observing outside View](https://forums.swift.org/t/two-approaches-to-observe-observable-object-without-outside-view/77004), and [Stack Overflow: publisher from @Observable values](https://stackoverflow.com/questions/77081347/how-to-get-a-publisher-from-a-value-since-the-beauty-of-observable).

```Swift
@Observable class HybridViewModel {
    var query: String = "" {
        didSet { querySubject.send(query) }
    }

    @ObservationIgnored
    private let querySubject = PassthroughSubject<String, Never>()

    var queryPublisher: AnyPublisher<String, Never> {
        querySubject.eraseToAnyPublisher()
    }
}
```

For the above code examples, the **.task(id:)** modifier installs a task that cancels and restarts whenever the identifier changes, which matches debounce behavior. A sleep creates the delay window and cancellation drops in‑flight work. Actor‑based debouncers bring these guarantees into models without relying on view lifecycle. The hybrid approach connects **didSet** changes to a subject so Combine pipelines can operate while views still benefit from precise observation. 

## **Testing Strategies**

Testing direct mutations is unchanged: set a property and assert the new value. To test that observation actually triggers, use **withObservationTracking** and expectations. Remember the nuance: the change handler runs with will‑set semantics—before the new value is stored—so read the new value after the mutation or inside an asynchronous continuation.

```Swift

withObservationTracking {
    _ = vm.name
} onChange: {
    expectation.fulfill()
}
vm.name = "Updated"
```
## **Backward Compatibility**

Teams supporting iOS 15 or 16 can adopt the model today using Point‑Free’s **Perception** library. Replace **@Observable** with **@Perceptible** and wrap bodies with **WithPerceptionTracking**. When support for older OS versions is dropped, perform a straightforward rename back to the native macros. See [Point‑Free: Perception](https://github.com/pointfreeco/swift-perception).

## **Conclusion**

Migrating to **@Observable** removes imperative glue, enables natural nested modeling, and converts broad invalidation into precise property‑level updates. Syntax becomes cleaner, and concurrency replaces reactive operators for side effects. The result is a system that is performant by default, simple to reason about, and robust at scale. For teams on older platforms, backports make it possible to adopt the architecture immediately and migrate later with minimal effort.

#### **References**

Apple Developer: [Migrating from ObservableObject to Observable](https://developer.apple.com/documentation/SwiftUI/Migrating-from-the-observable-object-protocol-to-the-observable-macro). 
SwiftLee: [Performance increase with @Observable](https://www.avanderlee.com/swiftui/observable-macro-performance-increase-observableobject/). 
Stack Overflow: [Bind to nested ObservableObjects](https://stackoverflow.com/questions/58406287/how-to-tell-swiftui-views-to-bind-to-nested-observableobjects). 
Swift Forums: [Nested ObservableObject observation](https://forums.swift.org/t/what-is-the-correct-way-to-observe-the-changes-from-within-a-nested-observableobject/62788). 
Apple Docs: [ObservationRegistrar](https://developer.apple.com/documentation/observation/observationregistrar). 
Jesse Squires: [Observable macro is not drop‑in](https://www.jessesquires.com/blog/2024/09/09/swift-observable-macro/). 
Point‑Free: [Perception](https://github.com/pointfreeco/swift-perception).


large_observable-thumb.jpg

medium_observable-thumb.jpg

small_observable-thumb.jpg

thumbnail_observable-thumb.jpg

observable-thumb.jpg

The move from the Combine‑based **ObservableObject** protocol to Swift’s native **Observation** framework is a fundamental shift for SwiftUI. For years, state updates were driven by a push‑based invalidation model where objects broadcast generic change signals that trigger broad view re‑evaluations. This worked for small apps but struggled at scale, especially with large lists, nested reference models, and complex data dependencies. With the **@Observable** macro in Swift 5.9, the model becomes pull‑based and access tracked, giving precise invalidation, cleaner architecture, and better performance by default.

MVVM Architecture in SwiftUI: From ObservableObject to @Observable - Part 3

# Property Wrapper Integration and Lifecycle — deep dive on *@StateObject* vs *@ObservedObject*

SwiftUI gives you two very similar-looking tools for connecting classes to the view layer: *@StateObject* and *@ObservedObject*. They both let a view react to changes from an ObservableObject, but they have very different responsibilities. Pick the wrong one and your view models will be behavior unexpectedly.

---

## The short definition

*@StateObject* = *creates and owns* the object. SwiftUI stores it outside the view struct and gives you the same instance across body re-evaluations.

*@ObservedObject* = *observes only*. It subscribes to the object’s changes but does not own or store it for you.

Ownership is the whole story. Once you understand who owns the object, every mystery about lifecycle falls into place.

---

## Why this matters — SwiftUI’s view recreation model

SwiftUI views are value types. SwiftUI rebuilds view structs frequently: when local state changes, when parents update, and during layout passes. If you put a reference-type (class) instance in a plain property of the view struct, it will be recreated with the view struct and you’ll lose state. *@StateObject* prevents that by telling SwiftUI to allocate and keep the instance in its managed storage for the life of that view’s identity.

---

## Classic mistakes and concrete fixes

### Mistake A — Creating a view model with *@ObservedObject* in the view (the most common trap)

Wrong: the view model gets reconstructed every time the view redraws.

```swift
import SwiftUI
import Combine

final class CounterVM: ObservableObject {
    @Published var count = 0
    init() { print("CounterVM init") }
    deinit { print("CounterVM deinit") }
    func inc() { count += 1 }
}

struct ParentBadView: View {
    @State private var toggle = false

    var body: some View {
        VStack(spacing: 16) {
            Button("Toggle parent state") { toggle.toggle() } // causes parent to re-evaluate
            Text("Parent toggle: \(toggle.description)")

            // Child created inline — has @ObservedObject var vm = CounterVM()
            BadCounterView()
                .border(Color.red)
        }
        .padding()
    }
}

struct BadCounterView: View {
    // <-- BAD: observed object created inline.
    // This initializer runs every time the view struct is recreated.
    @ObservedObject var vm = CounterVM() // ❌ wrong ownership

    var body: some View {
        VStack {
            Text("Count: \(vm.count)")
            Button("Inc") { vm.inc() }
        }
        .padding()
    }
}

```

Expected console log when the view is recreated repeatedly:

```
CounterVM init
CounterVM deinit
CounterVM init
CounterVM deinit
...
```

Symptom: *count* resets. Presentations that rely on the VM (alerts, sheets) may dismiss because their presenter was deallocated.

First way to fix: Child owns the VM with @StateObject

```swift
struct ParentGoodAView: View {
    @State private var toggle = false

    var body: some View {
        VStack(spacing: 16) {
            Button("Toggle parent state") { toggle.toggle() }
            Text("Parent toggle: \(toggle.description)")

            GoodCounterView() // child owns VM via @StateObject
                .border(Color.green)
        }
        .padding()
    }
}

struct GoodCounterView: View {
    // ✅ child becomes the owner. SwiftUI allocates and stores this instance once.
    @StateObject private var vm = CounterVM()

    var body: some View {
        VStack {
            Text("Count: \(vm.count)")
            Button("Inc") { vm.inc() }
        }
        .padding()
    }
}

```
---
Or we could let parent owns the VM and passes it down:
```swift
struct ParentGoodBView: View {
    @State private var toggle = false
    @StateObject private var sharedVM = CounterVM() // parent owns the VM

    var body: some View {
        VStack(spacing: 16) {
            Button("Toggle parent state") { toggle.toggle() }
            Text("Parent toggle: \(toggle.description)")

            ChildObservingView(vm: sharedVM) // child only observes
                .border(Color.blue)
        }
        .padding()
    }
}

struct ChildObservingView: View {
    @ObservedObject var vm: CounterVM // observes the parent's VM

    var body: some View {
        VStack {
            Text("Count: \(vm.count)")
            Button("Inc") { vm.inc() }
        }
        .padding()
    }
}

```
### Mistake B — Heavy work in init() of the view model

Putting network calls, database setup, or expensive computation directly inside *init* causes slow startup and makes duplicate inits visible during SwiftUI layout passes (previews and complex hierarchies might call init multiple times before the StateObject is stored).

Wrong:

```swift
final class SyncVM: ObservableObject {
    @Published var value: String = ""
    init() {
        // heavy sync work
        fetchFromNetworkSynchronously() // ❌ blocks and may run multiple times
    }
}
```

Symptom: UI jank, slower previews, confusing double initialization logs.

Fix: keep init lightweight and perform async work in *onAppear*, *.task*, or a *start()* method.

```swift
final class AsyncVM: ObservableObject {
    @Published var value: String = ""
    func start() {
        Task {
            let result = await fetchFromNetwork()
            await MainActor.run { self.value = result }
        }
    }
}

struct LoaderView: View {
    @StateObject private var vm = AsyncVM()
    var body: some View {
        Text(vm.value.isEmpty ? "Loading…" : vm.value)
            .task { vm.start() } // starts once when view enters scene
    }
}
```

This pattern avoids heavy work in init and defers side-effects until the view is actually active. 
From the above behavior, *@StateObject* is created the first time the view is inserted into the real view hierarchy. However, SwiftUI can instantiate view structs for layout and measurement before that moment — which sometimes makes it look like initializers ran more than once during preview or complex layouts. In practice, the instance that matters is the one SwiftUI stores and supplies to subsequent body evaluations.

_Here is the rule of thumb_: don’t rely on *init* side effects for one-time app-level setup. Use *onAppear*, *.task*, or an explicit *start()* call for side-effects that must run once.

---

### Mistake C — Using *@StateObject* but wanting to inject instances (DI gotcha)

If you want a view to accept an externally created VM (for tests or DI), don’t declare *@StateObject private var vm = MyVM()* and then expect an injected instance to replace it. SwiftUI will ignore the external instance after the wrapper has been set up.

Incorrect injection attempt:

```swift
struct ProfileView: View {
    @StateObject private var vm = ProfileVM() // hard-coded instance
    init(vm: ProfileVM) { /* trying to inject — doesn't work */ }
}
```

Fix: initialize the wrapper from the initializer using the underscore syntax:

```swift
struct ProfileView: View {
    @StateObject private var vm: ProfileVM

    init(vm: ProfileVM) {
        _vm = StateObject(wrappedValue: vm) // ✅ use injected instance as the stored value
    }

    var body: some View {
        Text(vm.username)
    }
}
```

Now tests or parent code can pass a mock VM and SwiftUI will use the injected instance as the *StateObject*'s initial value.

---

### Mistake D — Putting *@StateObject* in a child when you needed shared state

*@StateObject* gives each view its own owned instance. For lists or sibling views that must share a single model, this creates duplicates.

Example where this is wrong:

```swift
struct RowView: View {
    @StateObject private var rowVM = CounterVM() // each row gets its own VM
    var body: some View {
        HStack {
            Text("Count \(rowVM.count)")
            Button("Inc") { rowVM.inc() }
        }
    }
}
```

Symptom: It looks like you have many counters and they don't sync (as expected). But if you wanted a single counter shared between rows, this is wrong.

Fix: own the model at a higher level and pass as `@ObservedObject`:

```swift
struct TableView: View {
    @StateObject private var sharedVM = CounterVM()

    var body: some View {
        ForEach(0..<3) { _ in
            RowView(vm: sharedVM)
        }
    }
}

struct RowView: View {
    @ObservedObject var vm: CounterVM
    var body: some View { /* uses vm */ }
}
```

Now all rows observe the same *CounterVM*.

---

### Mistake E — Expecting to replace a *@StateObject* instance later (you can’t)

A *@StateObject* belongs to SwiftUI. Once the view is created, SwiftUI stores the object and keeps it alive for the view’s whole lifecycle. This means you **cannot** later assign a new instance to that property, and re-passing a different instance from the parent won’t replace it either. The child takes the value **only at the moment it is created**. Developers often expect the child to “pick up” a new instance, but SwiftUI keeps the first one.

Wrong — parent tries to pass a different instance, child uses *@StateObject*:

```swift
struct Parent: View {
    @State private var useOther = false
    private let first = CounterVM(tag: "first")
    private let second = CounterVM(tag: "second")

    var body: some View {
        VStack {
            Button("Swap instance") { useOther.toggle() }
            Child(vm: useOther ? second : first)  // looks like it should change…
        }
    }
}

struct Child: View {
    @StateObject private var vm: CounterVM

    init(vm: CounterVM) {
        _vm = StateObject(wrappedValue: vm)  // …but this is only used once at creation
    }

    var body: some View {
        Text("VM tag: \(vm.tag)")
    }
}
```

Even though the parent switches between *first* and *second*, the child continues showing only the **initial** VM’s tag. SwiftUI does not replace the stored *StateObject*.

Fix: mutate the object you already own, or let the parent truly own the instance and pass it down using *@ObservedObject*. If you need to reset or change behavior, prefer internal methods:

```swift
final class CounterVM: ObservableObject {
    @Published var count = 0
    func reset() { count = 0 }  // change internal state instead of replacing the object
}
```

If you absolutely must replace the whole instance, do it at the **parent** level (for example by storing the VM in a *@State* property and passing it to the child as an *@ObservedObject*).


---

## Closing notes

*@StateObject* and *@ObservedObject* may look similar, but the difference is ownership. Once you start thinking in terms of *who owns the model*, most lifecycle surprises disappear. Use *@StateObject* when the view is the source of truth and must keep the object alive across redraws, and use *@ObservedObject* when the model lives elsewhere and the view only needs to watch it. Small shifts in ownership lead to big differences at runtime, so keep initializers simple, avoid heavy work or side effects in *init*, and inject dependencies with *_vm = StateObject(wrappedValue:)* only when the view truly owns the instance. And always check behavior in the simulator or on a device, because previews don’t always reveal lifecycle details. With these habits, SwiftUI’s MVVM flow becomes much more predictable and easier to reason about.



large_stateObject-ObservedObject.jpg

medium_stateObject-ObservedObject.jpg

small_stateObject-ObservedObject.jpg

thumbnail_stateObject-ObservedObject.jpg

stateObject-ObservedObject.jpg

SwiftUI gives you two very similar-looking tools for connecting classes to the view layer: `@StateObject` and `@ObservedObject`. They both let a view react to changes from an ObservableObject, but they have very different responsibilities. Pick the wrong one and your view models will be behavior unexpectedly.

@StateObject & @ObservedObject in details

large_Screenshot 2025-08-06 at 22.17.43.png

medium_Screenshot 2025-08-06 at 22.17.43.png

small_Screenshot 2025-08-06 at 22.17.43.png

thumbnail_Screenshot 2025-08-06 at 22.17.43.png

Screenshot 2025-08-06 at 22.17.43.png

Apple’s TextKit framework is the powerful engine that drives text rendering in every iOS and macOS app. With the introduction of TextKit 2, Apple completely redesigned this engine to meet the demands of modern computing.

This article provides a top-down understanding of TextKit, starting with the classic architecture of TextKit 1, moving to the modern component-based design of TextKit 2, and concluding with a strategic roadmap for migration.

TextKit2: A Top-Down Approach

large_Race Road Paths Minimalism.jpeg

medium_Race Road Paths Minimalism.jpeg

small_Race Road Paths Minimalism.jpeg

thumbnail_Race Road Paths Minimalism.jpeg

Race Road Paths Minimalism.jpeg

Swift Concurrency offers powerful tools for writing asynchronous code that's more readable and maintainable than traditional callback-based approaches. However, beneath its elegant syntax lies a complex system that can create serious issues when misused. The cooperative thread pool, actor isolation, and bridging mechanisms introduce subtle pitfalls that can lead to deadlocks, memory leaks, and unexpected runtime behavior.

This article explores the challenges developers face with Swift Concurrency and provides guidance for avoiding common pitfalls that can compromise application stability and performance.

 Swift Concurrency is great, but... - Part 1

Swift Concurrency, introduced in WWDC21, offers a safer and more efficient approach to asynchronous programming compared to _Grand Central Dispatch_ (GCD). However, integrating _Swift Concurrency_ with older primitives like _NSLock_ and _GCD queue_ requires careful consideration to avoid potential pitfalls.



### 1. Swift Concurrency vs. GCD



Swift Concurrency distinguishes itself from GCD in its threading model and its approach to handling blocked threads.



**Threading Model:**



*  **GCD:** GCD employs a thread-pool model where threads are dynamically created and managed by the system. This can lead to **thread explosion**, particularly with concurrent queues, where the system might overcommit by creating more threads than CPU cores. GCD dynamically adjusts the number of threads based on system load and available resources.

  *  Example:

    ```swift

    let queue = DispatchQueue.global(qos: .background)

    for i in 0..<100 { 

     queue.async { 

      // Perform some lengthy task, such as:

      print("Task \(i) is running on thread: \(Thread.current)")

      Thread.sleep(forTimeInterval: 2) // Simulate a long-running task

     }

    }
    ```

    This code could potentially create 100 threads, even if the device has fewer cores. Each task is dispatched to the global concurrent queue, and GCD might create a new thread for each task, especially if the tasks are CPU-bound or blocking. This can lead to performance issues due to excessive context switching and resource contention.

*  **Swift Concurrency:** Swift Concurrency, by default, utilizes a **cooperative thread pool** limited to the number of CPU cores. It uses cooperative multitasking, where tasks voluntarily yield control to allow other tasks to run, thus efficiently utilizing CPU cores and preventing thread explosion.

  *  Example:

    ```swift

    func lengthyTask() async {

      print("Lengthy task is running on thread: \(Thread.current)")

      await Task.sleep(nanoseconds: 2_000_000_000) // Simulate a long-running task

    }

    func anotherLengthyTask() async {

      print("Another lengthy task is running on thread: \(Thread.current)")

      await Task.sleep(nanoseconds: 1_000_000_000) 
    }

    async let task1 = lengthyTask()

    async let task2 = anotherLengthyTask()

    await task1
    await task2
    ```

    This code leverages the cooperative thread pool and ensures efficient utilization of CPU cores. When _await_ is encountered, the current thread can be potentially freed up to execute other tasks while waiting for the awaited task to complete. This helps prevent the creation of unnecessary threads and minimizes context switching overhead.



**Handling Blocked Threads:**



*  **GCD:** When a thread in GCD is blocked, the system might spin up new threads to handle remaining tasks, potentially exacerbating thread explosion.

  *  Example:

    ```swift

    let queue = DispatchQueue.global()

    queue.sync {

     // This blocking operation will halt the current thread

     let url = URL(string: "https://www.example.com/large_file.zip")! 

     let data = try Data(contentsOf: url) // Download a large file (blocking)

     print("Downloaded data size: \(data.count) bytes")

    }
    ```

    If this occurs within a concurrent queue with multiple tasks, GCD might create additional threads to continue processing tasks. Downloading a large file can take a significant amount of time, during which the thread executing this code is blocked, waiting for the download to complete. In a GCD-based system, if other tasks are enqueued on the same concurrent queue, GCD might create new threads to handle those tasks, potentially leading to thread explosion. To understand more about Excessive Context Switching & Thread Explosion, take a look at this incredible [WWDC explanation](https://developer.apple.com/videos/play/wwdc2017/706/) at 11:03.

*  **Swift Concurrency:** Swift Concurrency replaces blocked threads with lightweight _continuations_ These continuations track the resumption points of suspended tasks, enabling threads to efficiently switch between work items without the overhead of full thread context switches.


![wwdc-gcd-thread.jpg](https://api.flyingharley.dev/uploads/wwdc_gcd_thread_82c1c5d328.jpg)
*With GCD, when a thread is blocked, many threads will be created and Context Switches occurred*

![wwdc-swiftconcurrency.jpg](https://api.flyingharley.dev/uploads/wwdc_swiftconcurrency_a768fbc1d4.jpg)
*With Swift Concurrency, there will be only one thread for each CPU core*

  *  Example:

    ```swift

    let url = URL(string: "https://www.example.com/large_file.zip")!

    do {

      let data = try await Data(contentsOf: url)

      print("Downloaded data size: \(data.count) bytes")

    } catch {

      print("Failed to download data: \(error)")

    }
    ```

    Using _await_ allows the current thread to be freed while waiting for the file data, avoiding thread blocking and allowing the thread to potentially handle other tasks. The _await_ keyword signals a potential suspension point. When the code execution reaches _await_ the current task can be suspended, and the thread can be used to execute other tasks. Once the awaited operation (downloading the file) is complete, the task is resumed, and the execution continues from the suspension point.



### 2. Safe Primitives vs. Legacy Primitives

![primitives.jpg](https://api.flyingharley.dev/uploads/primitives_4f7179124b.jpg)

When adopting Swift Concurrency, it's crucial to prioritize performance and understand the implications of await on atomicity. The recommended approach is to utilize safe primitives like _await_, _Actors_, and _Task groups_, which are compiler-enforced. These primitives ensure thread safety and help avoid common concurrency issues.

While primitives like _os_unfair_lock_ and _NSLock_ can be used in synchronous code for short, well-defined critical sections, they require caution. Using them within asynchronous contexts or for long-running operations can lead to deadlocks and violate the **runtime contract of forward progress**.

Unsafe primitives such as _DispatchSemaphore_, _pthread_cond_, _NSCondition_, and _pthread_rw_lock_ are strongly discouraged. These primitives hide dependency information from the Swift runtime, potentially causing unpredictable behavior and making debugging difficult.
To identify the use of unsafe primitives during development, run your app with the environment variable _LIBDISPATCH_COOPERATIVE_POOL_STRICT_=1. This modified debug runtime helps enforce the invariant of forward progress and can flag potential issues.
But we should use Actors whenever possible. They offer a safer and more efficient alternative to locks and serial queues for mutual exclusion. They guarantee that only one method call is executed at a time, protecting the actor's state from data races. Actors also support efficient thread hopping and prioritization, ensuring responsiveness and avoiding priority inversions.

So why shouldn't we use Actors at any time? In reality, there are situations where using these might not be ideal, such as when **modifying and reading individual properties** within a type such as class... In this case, actors aren't quite the right tool because:

- **Granularity of Access**: Actors are designed to protect their entire state. Every method call on an actor is executed serially, ensuring that only one thread can access the actor's properties at a time. This is great for preventing data races when working with multiple properties. However, if you only need to synchronize access to a single property, using an actor might introduce unnecessary overhead.
- **Order of Operations**: You can't guarantee the order in which operations will run on an actor. If you have a sequence of operations that must be performed in a specific order on a single property, using an actor might not be the best solution.

Let's consider an example: Imagine you have a class representing a counter:

```swift
class Counter {
    private var count = 0
    
    func increment() {
        count += 1
    }
    
    func decrement() {
        count -= 1
    }
    
    func getValue() -> Int {
        return count
    }
}
```

If you want to ensure that increment and decrement operations are synchronized, using an actor might be an option. However, it will also make reading the value using **getValue** subject to the actor's serialization, potentially impacting performance if there are frequent read operations.
In such cases, alternative synchronization mechanisms like atomics, dispatch queues, or locks can be more appropriate. These mechanisms allow you to synchronize access to specific properties without affecting the entire object's state.
For instance, you could use a [_ManagedAtomic_](https://www.swift.org/blog/swift-atomics/) to synchronize access to the count property:
```swift
import SwiftAtomics

class Counter {
    private var count = ManagedAtomic<Int>(0)
    
    func increment() {
        count.wrappingIncrement(ordering: .sequentiallyConsistent)
    }
    
    func decrement() {
        count.wrappingDecrement(ordering: .sequentiallyConsistent)
    }
    
    func getValue() -> Int {
        return count.load(ordering: .sequentiallyConsistent)
    }
}
```

Here, [_ManagedAtomic_](https://www.swift.org/blog/swift-atomics/) ensures that increment, decrement, and read operations on the count property are atomic and synchronized, without requiring the entire _Counter_ class to be an actor.
Therefore, while actors are powerful tools for concurrent programming, they might not always be the most efficient or flexible solution. When dealing with individual properties that require synchronized access, consider using alternative synchronization mechanisms like atomics, dispatch queues, or locks. Remember to carefully evaluate the trade-offs and choose the approach that best suits your specific needs.

### 3. Deadlock Scenario: GCD Queues and Swift Concurrency



#### Problem Description



Integrating Swift Concurrency with GCD can lead to deadlock scenarios, especially when tasks are blocked inside GCD queues. Understanding how GCD queues work and how they differ from Swift Concurrency is crucial to avoid these issues.



#### GCD Queue



- **Serial Queue**: Executes tasks one at a time in the order they are added. This ensures that tasks do not run concurrently and are processed sequentially.

  

- **Concurrent Queue**: Allows multiple tasks to execute simultaneously. Tasks are started in the order they are added, but they can run in parallel and complete in any order. _GCD_ concurrent queues can **overcommit** by creating more threads than there are available hardware threads to ensure work progresses.



#### Swift Concurrency



- **Task & Continuation**: A _Task_ represents a unit of asynchronous work that can be awaited. Together with _Continuation_, they allow asynchronous code that doesn't use _async/await_ to be integrated into Swift's concurrency model by capturing the continuation of an operation. In this context, it can be used to integrate GCD.



- **Non-Overcommitting**: Swift Concurrency does not expect blocking and will **not overcommit** CPU cores. This means it efficiently manages resources but can lead to deadlocks if tasks are blocked.



#### Problem When Swift Concurrency Task Is Blocked Inside GCD Queue



When a Swift Concurrency task is blocked inside a GCD queue, it can lead to a deadlock if the queue is waiting for a thread from the thread pool to dispatch a task, but no threads are available because they are all blocked.



#### Code Example: Read & Write Patterns Using GCD Concurrent Queue



```swift

import XCTest

final class BarrierTests: XCTestCase {

  func test() async {

    let subsystem = Subsystem()

    await withTaskGroup(of: Void.self) { group in

      for index in 0 ..< 100 {

        group.addTask { subsystem.performWork(id: index) }

      }

      await group.waitForAll()

    }

  }

}


final class Subsystem {

  let queue = DispatchQueue(label: "my concurrent queue", attributes: .concurrent)

  func performWork(id: Int) {

    if id % 10 == 0 { write(id: id) }

    else { read(id: id) }

  }

  func write(id: Int) {

    print("schedule exclusive write \(id)")

    queue.async(flags: .barrier) { print(" execute exclusive write \(id)") } // Asynchronous write with barrier

    print("schedule exclusive write \(id) done")

  }

   
  func read(id: Int) {

    print("schedule read \(id)")

    queue.sync { print(" execute read \(id)") } // Synchronous read, blocking the caller

    print("schedule read \(id) done")

  }

}

```
Ref: https://forums.swift.org/t/deadlock-when-using-dispatchqueue-from-swift-task/66058/25


#### Explanation

- **Multiple Synchronous Reads**: Allowed with the concurrent queue, blocking the caller.

- **Barrier for Writes**: The write operation is dispatched asynchronously with a barrier, ensuring it can only proceed when no other reads or writes are running concurrently.


While the code might not immediately cause a deadlock, it has the potential to do so when:


1. An event triggers multiple read and write operations.

2. A large number of read operations start from a Swift Concurrency context, consuming available threads.

3. A write operation is triggered, making an asynchronous call to the concurrent queue under the _.barrier_ option.

4. The queue waits for a thread from the thread pool to dispatch the write operation, but **no threads are available due to blocking reads**. Since Swift Concurrency won't overcommit (create more threads), the barrier isn't cleared, leading to a deadlock.



#### Observations


- **GCD and Swift Concurrency**: They seem to share the same thread pools, which can exacerbate the issue.



- **Deadlock Consequences**: When this deadlock occurs, **subsequent tasks will not be dispatched, leading to program malfunction**. The main thread (MainActor) may still work and receive events, but other threads will not make progress.



Here are some rule of thumbs & considerations:

- **Avoid Blocking**: Do not block work inside Swift Concurrency, such as using _.sync_ on another GCD queue, especially for future work that is not actively running but enqueued (e.g., async dispatch with a barrier). This violates the runtime contract of "Forward progress" we mentioned before.


- **Limit Task Creation**: Avoid creating too many Swift Concurrency tasks using **Task** blocks or **TaskGroup**, as unexpected blocking can easily lead to deadlocks, especially when interacting with legacy frameworks.



- **Minimize Mixing**: Try to avoid mixing Swift Concurrency and GCD, as it can lead to unexpected behavior and be difficult to debug.


With the discussion so far, we can easily figure out the solution which is simply avoid using the concurrent queue for read-write pattern. Instead, we could use _NSLock_ (with caution) or _pthread_rw_lock_ (not recommended).

### 4. Summary
Swift Concurrency provides powerful tools for writing safer and more efficient concurrent code. Developers should prioritize the use of safe primitives like _await_, _Actors_, and _Task groups_ as they offer compiler-enforced safety and help manage concurrency effectively.
While traditional synchronization mechanisms like locks (_NSLock_, _os_unfair_lock_) and dispatch queues are still available, it's important to exercise caution when using them in Swift Concurrency. They can introduce deadlock risks if not handled properly, especially when interacting with asynchronous operations.


large_balancer.jpeg

medium_balancer.jpeg

small_balancer.jpeg

thumbnail_balancer.jpeg

balancer.jpeg

Swift Concurrency, introduced in WWDC21, offers a safer and more efficient approach to asynchronous programming compared to Grand Central Dispatch (GCD). However, integrating Swift Concurrency with older primitives like NSLock and GCD requires careful consideration to avoid potential pitfalls

Swift Concurrency and Legacy Primitives: A Balancing Act

# Protocol Extension Method Dispatching in Swift

## Introduction to Method Dispatch Types

Method dispatch is the mechanism a program uses to determine which implementation of a function to execute when that function is called. **Swift employs four types of method dispatch, each with trade-offs between speed and flexibility**:

*   **Inlining:** This is the fastest and least flexible type of dispatch. It involves replacing a function call with the function's code, eliminating the overhead associated with making the call. This optimization is most effective when the compiler has all the information it needs to determine the result of the function call at compile time, such as when working with hardcoded values or simple operations.

*   **Static Dispatch:** Also known as direct dispatch, static dispatch is the second fastest and second least flexible type of dispatch. It occurs when the function's memory address is known at compile time. This allows the compiler to directly jump to that address without needing to perform a runtime lookup. Static dispatch is typically used for functions within structs, enums, and final classes, where the compiler can guarantee which implementation will be used.

*   **Table Dispatch:** This type of dispatch is used to implement polymorphism, which is the ability of a single type to have multiple forms. In table dispatch, the function to be called is determined at runtime by looking up its address in a table. Swift implements two flavors of table dispatch: **virtual table dispatch** for class hierarchies and **protocol witness table dispatch** for protocols.

    *   **Virtual Table Dispatch:** Virtual tables are used to dispatch methods on class hierarchies. When a class is created, it includes a hidden data structure called a virtual table, which contains pointers to the implementations of all the methods defined in the class and its superclasses. When a method is called on an object, the runtime uses the object's virtual table to find the correct implementation of the method to execute. This allows subclasses to override methods from their superclasses and have their implementations called even when the method is called on a variable typed as the superclass. This is because the specific type of the object is not known until runtime.

    *   **Protocol Witness Table Dispatch:** Protocol witness tables work similarly to virtual tables but are used for protocols. When a type conforms to a protocol, it creates a witness table that contains pointers to the implementations of all the required methods of the protocol. When a method is called on a variable typed as a protocol, the runtime uses the variable's witness table to find the correct implementation of the method to execute.

*   **Message Dispatch:** This is the slowest and most flexible type of dispatch. It uses the Objective-C runtime and allows for dynamic method lookup at runtime. This means that the implementation of a method can be changed at runtime, even after the code has been compiled. Message dispatch is invoked using the _@objc_ and _dynamic_ keywords in Swift. This type of dispatch is useful for interoperability with Objective-C code and for implementing features like Key-Value Observing (KVO).

In this article, we will focus on Protocol Witness Table Dispatch. For further information on method dispatch in Swift, please refer to those great articles:

*   [The Swift Method Dispatch Deep Dive](https://jacob.bartlett.dev/blog/swift-method-dispatch)
*   [Swift Protocol Extensions Method Dispatch](https://medium.com/@leandromperez/swift-protocol-extensions-method-dispatch-7e28d7a68b8c)
*   [Method Dispatch in Swift — RaizException — Raizlabs Developer Blog](https://www.raizlabs.com/dev/method-dispatch-in-swift/)
*   [Method Dispatch in Protocol Extensions — Ole Begemann](https://oleb.net/blog/2014/07/swift-protocol-extensions/)

## Protocol Witness Table Dispatch

Protocol witness table dispatch is the mechanism by which Swift implements polymorphism for protocols. **When a type conforms to a protocol, it generates a witness table that includes pointers to the implementations of the protocol's required methods**.  During runtime, when a protocol requirement is invoked on an instance of a conforming type, Swift references the corresponding function pointer in the witness table and directs the execution flow to that memory location.

**Points to remember**:

*   **Abstract vs. Concrete Types**: Protocol witness table dispatch is employed when interacting with abstract protocol types, such as _any MyProtocol_. When a concrete type adhering to the protocol is used, the compiler often opts for static dispatch due to the compile-time knowledge of the implementation. 

![Screenshot 2024-12-05 at 23.07.22.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_07_22_a87c0ab297.png)
Explanation:

    - The speak() method is a requirement of the Speaker protocol, so it will use dynamic dispatch when called on a variable of type any Speaker, even though there is a default implementation in the extension.

      - When genericSpeaker.speak() is called, the runtime checks the protocol witness table associated with the concrete type (Human) to find the correct implementation of speak(), which results in printing "Hello there!".

      - When humanSpeaker.speak() is called, the compiler knows at compile time that the type is Human, so it can use static dispatch directly to the Human implementation of speak()


*   **Default Implementations in Protocol Extensions**: Methods defined within protocol extensions, but not explicitly declared as requirements in the protocol's definition, leverage static dispatch. Consequently, invoking these methods on an abstract protocol type will directly execute the implementation from the extension. This is in contrast to requirement methods defined in protocol extensions, which use dynamic dispatch and can be customized by conforming types.
![Screenshot 2024-12-05 at 23.13.29.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_13_29_166e78d3a9.png)

Explanation:

    - makeSound() is a protocol requirement, so it uses dynamic dispatch, and the Dog implementation overrides the default extension implementation.
     
      - eat() is not a requirement. It's only defined in the extension, so it uses static dispatch. Regardless of the concrete type of animal, calling eat() will always execute the code in the extension
### Example and Dispatch Flow

![Screenshot 2024-12-05 at 23.17.44.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_17_44_12f80c1e8e.png)

**Explanation of the dispatch flow**:

1.  _myProtocolImplement_ is declared as an abstract protocol type (_any MyProtocol_).

2.  _myProtocolImplement.foo(i1: 1, i2: "2")_ is invoked. Because _myProtocolImplement_ is an abstract type, the runtime will use protocol witness table dispatch.

3.  The runtime inspects the witness table associated with the concrete type of _myProtocolImplement_, which is _MyStruct_ in this case, to locate the implementation of _foo(i1:i2:)_.

4.  Within the witness table, the runtime discovers the function pointer corresponding to _MyStruct_'s implementation of _foo(i1:i2:)_.

5.  Execution then jumps to this memory address, leading to the execution of _print("MyStruct foo")_.

**Outcome**: "MyStruct foo" is printed.

**Why this happens**:

Despite the protocol extension offering a default implementation for _foo(i1:i2:)_, _MyStruct_ also provides its own implementation. **When a conforming type provides a specific implementation for a protocol requirement, this implementation supersedes the default implementation in the extension**. This principle underscores a fundamental concept in protocol-oriented programming: conforming types retain the ability to customize their behavior, even when default implementations are available.

## The Perils of Default Parameters in Protocol Extensions

While protocol extensions in Swift offer a powerful mechanism for extending functionality, using default parameters within them requires careful consideration. The compiler's inability to safeguard against potential pitfalls, coupled with the possibility of infinite recursion, necessitates a cautious approach when employing this pattern.

Let's illustrate this with an example:

![Screenshot 2024-12-05 at 23.30.38.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_30_38_6fbc41b7e5.png)

Here, invoking _myProtocolImplement.foo()_ is intended to execute the _.foo(i1: Int, i2: String)_ method of _MyStruct_ with the default values of _1_ for _i1_ and _"2"_ for _i2_. However, this seemingly convenient approach can lead to dangerous runtime behavior.

**Recursive Calls and Their Consequences**:

The compiler provides no safeguards to prevent potential issues arising from this pattern. Consider the following scenarios:

*   **Missing Implementation**: If we forget to implement the _foo(i1: Int, i2: String)_ method inside _MyStruct_, the program will still compile.

![Screenshot 2024-12-06 at 22.56.18.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_06_at_22_56_18_7910114b0b.png)

*   **Parameter Mismatch**: If we modify the parameters of the _foo_ method in _MyStruct_, such as changing the type of _i2_ to _Int_, resulting in _foo(i1: Int, i2: Int)_, the program will again compile without errors.

In both of these cases, we encounter a critical runtime problem – an infinite loop of recursive calls.

**The Root of the Problem**:

The method dispatch mechanism in this context solely searches for the method implementation within the protocol extension.  **The _foo(i1: Int = 1, i2: String = "2")_ method ends up repeatedly calling itself, ultimately resulting in a crash**. This behavior arises because when the variable's inferred type is the protocol, the dynamically dispatched implementation from the extension is always invoked. If the conforming type doesn't explicitly override the default parameter, the default implementation from the protocol extension will be used, leading to the recursive call.

**Strategies to Mitigate the Risks**:

To avoid these potentially disastrous situations, consider the following strategies:

1.  **Avoidance:** The safest course of action is to completely avoid the use of default parameters within protocol extensions.

2.  **Renaming:** Alternatively, we can rename the method that has default parameters to differentiate it from the required protocol method. For example, instead of _foo(i1: Int = 1, i2: String = "2")_, we could use _fooDefault(i1: Int = 1, i2: String = "2")_. This prevents the recursive call issue, as the default implementation in the extension is now clearly distinct from the required method in the protocol.

![Screenshot 2024-12-06 at 22.58.55.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_06_at_22_58_55_eef7d5b0f4.png)

## In Conclusion

Swift's protocol extensions are a potent tool for expanding functionality. However, exercising caution when incorporating default parameters within them is crucial. The absence of compiler-enforced safeguards and the potential for infinite recursion demand a mindful approach. By acknowledging these risks and implementing appropriate mitigation strategies, we can ensure the robustness and reliability of our code.


large_Table-dispatch.jpg

medium_Table-dispatch.jpg

small_Table-dispatch.jpg

thumbnail_Table-dispatch.jpg

Table-dispatch.jpg


While Swift protocol extensions offer the convenience of default parameter values and other cool things, this seemingly simple feature can introduce unexpected behavior due to the dynamic nature of protocol method dispatch

mobile-1

MVVM Architecture in SwiftUI: From ObservableObject to @Observable - Part 3

@StateObject & @ObservedObject in details

TextKit2: A Top-Down Approach

Swift Concurrency is great, but... - Part 1

Swift Concurrency and Legacy Primitives: A Balancing Act

Protocol Extension Method Dispatching in Swift