# The Complete Guide to SwiftUI's Animation System: From Architecture to Advanced iOS 17 Features

SwiftUI changed how iOS developers think about animations. Instead of UIKit’s old imperative style where you had to manage every detail, SwiftUI lets you just describe *what* should animate and it handles the rest. This guide walks through everything you need to know, from the basics of how SwiftUI’s animation system works to the advanced tools added in iOS 17.

## SwiftUI vs UIKit Animation

UIKit takes an **imperative approach**. You must set up animation lifecycles, manage callbacks, and manually handle state changes ([example](https://www.tlvtech.io/post/learning-swiftui-vs-uikit), [comparison](https://getstream.io/blog/uikit-vs-swiftui/)). While you get fine control, it also makes code long and complex.

SwiftUI is **declarative**. When state changes, SwiftUI figures out what to animate and applies the animations you specify ([explanation](https://fatbobman.com/en/posts/the_animation_mechanism_of_swiftui/), [implicit vs explicit](https://fatbobman.com/en/snippet/swiftui-implicit-vs-explicit-animations/)). This cuts down boilerplate and keeps animations smooth.  

Performance differs too. UIKit gives direct access to Core Animation for deep tuning. SwiftUI instead optimizes automatically: batching updates, reducing layout recalculations, and using GPU acceleration where it can (see the [tips](https://canopas.com/swiftui-performance-tuning-tips-and-tricks-a8f9eeb23ec4), and [video](https://www.youtube.com/watch?v=WDRrsEAXvrE)).

## Core Animation Basics

### View Tree vs Render Tree
![Screenshot 2025-09-15 at 21.58.18.png](https://api.flyingharley.dev/uploads/Screenshot_2025_09_15_at_21_58_18_e07ac38896.png)

SwiftUI works with two linked trees:  

- **View Tree**: the structure from your Swift code. It’s temporary and rebuilt each time state changes ([source](https://substack.com/home/post/p-154812233), [how it works](https://flyingharley.dev/posts/swift-ui-fundamentals-how-it-works-behind-the-scenes)).  
- **Render Tree**: SwiftUI’s internal structure that actually controls the screen. It persists between updates and handles animations ([details](https://fatbobman.com/en/posts/the_animation_mechanism_of_swiftui/), [behind the scenes](https://vbat.dev/behind-the-scenes-of-ui-part-2-swiftui)).

This separation makes it possible to keep SwiftUI declarative but still fast.

### State-Driven Flow

State is the single source of truth. Wrappers like `@State`, `@Binding`, and `@ObservableObject` trigger updates automatically ([overview](https://tanaschita.com/20230116-animations-in-swiftui/), [guide](https://designcode.io/swiftui-handbook-animations-states/)).

Animations calculate **progress values** between 0.0 and 1.0 to smoothly move from old to new values ([article](https://swiftwithmajid.com/2020/06/17/the-magic-of-animatable-values-in-swiftui/), [deep dive](https://digitalbunker.dev/mastering-animatable-and-animatablepair-swiftui/)).

```swift
// State drives animation behavior
@State private var isExpanded = false
@State private var progress: Double = 0.0  // Progress interpolated during animation

var body: some View {
    Rectangle()
        .scaleEffect(1.0 + progress * 0.5)  // Progress creates intermediate values
        .animation(.linear(duration: 2.0), value: isExpanded)
}
```

![state-driven-anim.gif](https://api.flyingharley.dev/uploads/state_driven_anim_4c64aa3b3b.gif)
### Implicit vs Explicit Animations

- **Implicit animations** use `.animation()` directly on views. They affect only that view’s properties and trigger when values change ([examples](https://fatbobman.com/en/snippet/swiftui-implicit-vs-explicit-animations/), [discussion](https://holyswift.app/difference-between-implicit-and-explicit-animations-in-swiftui/)).  

```swift
// Implicit animation - scoped to view subtree
Rectangle()
    .fill(isActive ? .red : .blue)
    .scaleEffect(isActive ? 1.5 : 1.0)
    .animation(.spring(), value: isActive)  // Only affects this view's properties
```

![implicit-anim.gif](https://api.flyingharley.dev/uploads/implicit_anim_f40226ea96.gif)

- **Explicit animations** use `withAnimation {}` to wrap state changes. Everything inside animates together (Take a look at this [comparison](https://fatbobman.com/en/posts/the_animation_mechanism_of_swiftui/) for more information).


```swift
// Explicit animation - affects all changing properties
withAnimation(.easeInOut(duration: 0.5)) {
    isActive.toggle()       // Both properties animate
    scale = scale == 1.0 ? 1.5 : 1.0
}
```

![explicit-anim.gif](https://api.flyingharley.dev/uploads/explicit_anim_2f6f2e80a8.gif)

When both exist, implicit wins. That order is: explicit triggers → state changes → view re‑evaluates → implicit overrides.

### Transactions
![Screenshot 2025-09-15 at 22.42.46.png](https://api.flyingharley.dev/uploads/Screenshot_2025_09_15_at_22_42_46_0bc6f61fc7.png)
Transactions carry animation context (like curve and duration) through the view hierarchy (see this [guide](https://fatbobman.com/en/posts/mastering-transaction/), and [article](https://juniperphoton.substack.com/p/swiftui-transaction-animation)). Explicit animations create them at the state change site, while implicit ones modify them locally. This guide from [objc.io](https://www.objc.io/blog/2021/11/25/transactions-and-animations/) will clarify those things.

```swift
// Transaction modification example
.transaction { transaction in
    // Modify animation context for this view subtree
    transaction.animation = .easeInOut(duration: 1.0)
    // Can disable animations: transaction.disablesAnimations = true
}
```

![transaction-flow.gif](https://api.flyingharley.dev/uploads/transaction_flow_c6bfe0ce2f.gif)
### Timing Curves

Timing curves shape the feel of motion ([objc.io article](https://www.objc.io/blog/2019/09/26/swiftui-animation-timing-curves), [Design+Code](https://designcode.io/swiftui-handbook-animation-modifier-and-timing/)):

- **Linear**: steady speed.  
- **Ease curves**: gradual acceleration/deceleration.  
- **Spring**: physics‑like, bouncy ([repo](https://github.com/GetStream/swiftui-spring-animations), [post](https://www.kvin.me/posts/effortless-ui-spring-animations)).  

Custom Bézier curves are also supported.


```swift
// Different timing curve examples
.animation(.linear(duration: 1.0))                    // Constant velocity
.animation(.easeInOut(duration: 0.8))                // Natural acceleration/deceleration
.animation(.spring(response: 0.6, dampingFraction: 0.8))  // Physics-based motion
.animation(.timingCurve(0.68, -0.6, 0.32, 1.6, duration: 1.0))  // Custom Bézier curve
```

## Animations on State Change

![Screenshot 2025-09-15 at 22.52.31.png](https://api.flyingharley.dev/uploads/Screenshot_2025_09_15_at_22_52_31_8475866f9f.png)

When state changes, SwiftUI:  

1. Creates a transaction with animation info.  
2. Finds views depending on that state.  
3. Rebuilds their body.  
4. Identifies animatable properties.  
5. Interpolates values frame by frame.  
6. Updates visuals until the final state is reached.  

## Animatable Protocol

The [Animatable protocol](https://swiftwithmajid.com/2020/06/17/the-magic-of-animatable-values-in-swiftui/) lets you animate custom data. It works with types conforming to [VectorArithmetic](https://developer.apple.com/documentation/swiftui/vectorarithmetic) to enable interpolation.


```swift
protocol Animatable {
    associatedtype AnimatableData: VectorArithmetic
    var animatableData: AnimatableData { get set }
}
```

```swift
// Custom animatable type example
struct AnimatablePoint: VectorArithmetic {
    var x: Double
    var y: Double
    
    static var zero = AnimatablePoint(x: 0, y: 0)
    
    static func + (lhs: Self, rhs: Self) -> Self {
        AnimatablePoint(x: lhs.x + rhs.x, y: lhs.y + rhs.y)
    }
    
    static func - (lhs: Self, rhs: Self) -> Self {
        AnimatablePoint(x: lhs.x - rhs.x, y: lhs.y - rhs.y)
    }
    
    mutating func scale(by rhs: Double) {
        x *= rhs
        y *= rhs
    }
    
    var magnitudeSquared: Double {
        x * x + y * y
    }
}
```

![state-driven-anim.gif](https://api.flyingharley.dev/uploads/state_driven_anim_e41f9958f2.gif)

Before iOS 17, this was the way to animate custom values like rotation angles or morphing shapes (See this [advanced guide](https://alexdremov.me/swiftui-advanced-animation/)).

## iOS 17+ Features

### PhaseAnimator

`PhaseAnimator` runs animations as a sequence of phases instead of just start → end ([AppCoda](https://www.appcoda.com/phaseanimator/), [Design+Code](https://designcode.io/swiftui-handbook-phase-animator/)). Phases can each have their own curve and state. Good for storytelling animations and loaders.


```swift
enum AnimationPhase: CaseIterable {
    case initial, expand, rotate, contract, finish
    
    var scale: Double {
        switch self {
        case .initial, .finish: return 1.0
        case .expand: return 1.5
        case .rotate, .contract: return 1.2
        }
    }
    
    var rotation: Angle {
        switch self {
        case .initial, .expand, .contract, .finish: return .degrees(0)
        case .rotate: return .degrees(180)
        }
    }
}
```
**Phase animation structure** includes several key components:

- **Phases**: The sequence of discrete states the animation cycles through
- **Trigger**: Optional parameter that starts animation cycles when changed
- **Content closure**: View builder that applies phase-specific modifiers
- **Animation closure**: Defines timing and curves for each phase transition

```swift
struct PhaseAnimationExample: View {
    @State private var animate = false
    
    var body: some View {
        Image(systemName: "star.fill")
            .font(.largeTitle)
            .phaseAnimator(AnimationPhase.allCases, trigger: animate) { content, phase in
                content
                    .scaleEffect(phase.scale)
                    .rotationEffect(phase.rotation)
                    .foregroundStyle(phase == .rotate ? .red : .blue)
            } animation: { phase in
                switch phase {
                case .initial: .linear(duration: 0.1)
                case .expand: .bouncy(duration: 0.3)
                case .rotate: .smooth(duration: 0.5)
                case .contract: .easeOut(duration: 0.2)
                case .finish: .spring(duration: 0.1)
                }
            }
            .onTapGesture {
                animate.toggle()
            }
    }
}
![phase-based.gif](https://api.flyingharley.dev/uploads/phase_based_a9e8e19414.gif)
### KeyframeAnimator

![Screenshot 2025-09-15 at 23.19.39.png](https://api.flyingharley.dev/uploads/Screenshot_2025_09_15_at_23_19_39_f802f0ba4b.png)

`KeyframeAnimator` gives fine control with independent tracks per property ([AppCoda](https://www.appcoda.com/keyframeanimator/), [Design+Code](https://designcode.io/swiftui-handbook-keyframe-animator/)). Tracks can use linear, spring, cubic, or move keyframes. Perfect for detailed motion graphics or pro‑level effects.


**Keyframe animation structure** requires several components:

**AnimationValues struct**: Defines all properties that will be independently animated. Each property must conform to the `Animatable` protocol to enable smooth interpolation[^30][^29].

**KeyframeTracks**: Individual animation tracks for each property, specified using key paths to the corresponding property in the AnimationValues struct[^31][^32].

**Keyframe types**: Four distinct interpolation methods provide different motion characteristics:

- **LinearKeyframe**: Constant velocity interpolation between keyframes
- **SpringKeyframe**: Physics-based motion with spring dynamics
- **CubicKeyframe**: Smooth curves using cubic Bézier interpolation
- **MoveKeyframe**: Immediate value changes without interpolation

```swift
struct KeyframeAnimationExample: View {
    @State private var trigger = false
    
    struct AnimationValues {
        var scale = 1.0
        var verticalStretch = 1.0
        var position = CGPoint.zero
        var rotation = Angle.zero
        var opacity = 1.0
    }
    
    var body: some View {
        RoundedRectangle(cornerRadius: 20)
            .fill(.purple)
            .frame(width: 100, height: 100)
            .keyframeAnimator(
                initialValue: AnimationValues(),
                trigger: trigger
            ) { content, values in
                content
                    .scaleEffect(values.scale)
                    .scaleEffect(y: values.verticalStretch)
                    .offset(x: values.position.x, y: values.position.y)
                    .rotationEffect(values.rotation)
                    .opacity(values.opacity)
            } keyframes: { _ in
                // Scale track - bouncy entrance
                KeyframeTrack(\.scale) {
                    LinearKeyframe(1.0, duration: 0.2)      // Hold initial
                    SpringKeyframe(1.8, duration: 0.4, spring: .bouncy)  // Expand
                    CubicKeyframe(1.0, duration: 0.4)       // Return to normal
                }
                
                // Position track - arc movement
                KeyframeTrack(\.position) {
                    CubicKeyframe(CGPoint(x: 50, y: -80), duration: 0.3)   // Up and right
                    SpringKeyframe(CGPoint(x: -30, y: 40), duration: 0.4)  // Down and left
                    LinearKeyframe(CGPoint.zero, duration: 0.3)            // Return home
                }
                
                // Rotation track - independent timing
                KeyframeTrack(\.rotation) {
                    LinearKeyframe(.degrees(0), duration: 0.4)      // No rotation
                    CubicKeyframe(.degrees(180), duration: 0.3)     // Half spin
                    SpringKeyframe(.degrees(360), duration: 0.3)    // Complete rotation
                }
                
                // Vertical stretch - squash and stretch effect
                KeyframeTrack(\.verticalStretch) {
                    CubicKeyframe(0.8, duration: 0.15)    // Compress before jump
                    SpringKeyframe(1.3, duration: 0.25)   // Stretch during movement
                    CubicKeyframe(1.0, duration: 0.6)     // Return to normal
                }
                
                // Opacity track - fade effects
                KeyframeTrack(\.opacity) {
                    LinearKeyframe(1.0, duration: 0.2)     // Stay visible
                    CubicKeyframe(0.3, duration: 0.3)      // Fade during movement
                    SpringKeyframe(1.0, duration: 0.5)     // Fade back in
                }
            }
            .onTapGesture {
                trigger.toggle()
            }
    }
}
```
![keyframe-anim.gif](https://api.flyingharley.dev/uploads/keyframe_anim_4e34f9c485.gif)
### Scoped Animations

In iOS 17, `.animation()` can now target specific modifiers instead of whole view subtrees ([WWDC talk](https://developer.apple.com/videos/play/wwdc2023/10157/)). This avoids unnecessary animations and improves performance.

```swift
// iOS 17+ scoped animation
Text("Hello World")
    .opacity(flag ? 1 : 0)
    .animation(.default) {
        $0.rotationEffect(flag ? .zero : .degrees(90))  // Only rotation animates
    }
```
## Picking the Right Animation

![Screenshot 2025-09-15 at 23.24.45.png](https://api.flyingharley.dev/uploads/Screenshot_2025_09_15_at_23_24_45_0c40edd463.png)
Here are few points that need to be considered:
- **Simple changes**: use built‑in `.animation()`.  
- **Multi‑step sequences**: use PhaseAnimator.  
- **Independent property timelines**: use KeyframeAnimator.  
- **Custom data or math**: use Animatable.  
- **Path following or complex interpolation**: use AnimatableModifier.  

Decision depends on complexity and performance needs.


## Wrap Up

SwiftUI’s animation system makes complex things simpler by being declarative and state‑driven. With tools like PhaseAnimator and KeyframeAnimator in iOS 17, you can go from quick prototypes to professional motion graphics. Mastering these helps you pick the right tool, write cleaner code, and build smoother apps.

For more, check WWDC sessions: [Explore SwiftUI animation](https://developer.apple.com/videos/play/wwdc2023/10156/) and [Wind your way through advanced animations](https://developer.apple.com/videos/play/wwdc2023/10157/).

<div style="text-align: center">⁂</div>


This article provides a clear, end-to-end tour of SwiftUI animations, contrasting its declarative model with UIKit’s imperative approach to set expectations and trade-offs. You’ll learn how state drives updates through the view and render trees, how transactions carry animation context, and how timing curves and interpolation shape motion. We explain implicit vs. explicit animations, the Animatable protocol for custom values, and practical performance considerations for smooth, predictable UI. Diagrams and code examples map the full execution flow and show patterns for building reusable, testable animation behavior. Finally, we dive into iOS 17+ capabilities like PhaseAnimator and KeyframeAnimator to orchestrate multi-phase and keyframed effects with fine-grained control.

The first step to SwiftUI's Animation System: From Architecture to Advanced iOS 17 Features

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

# Tokyo day
![landing.jpg](https://api.flyingharley.dev/uploads/landing_494fbdafa0.jpg) ![airport.jpg](https://api.flyingharley.dev/uploads/airport_31970fafb8.jpg)
_Landed at Narita Airport - Tokyo_


![city-1.jpg](https://api.flyingharley.dev/uploads/city_1_39cedd25f6.jpg)
_Heading to hotel_
![city-2.jpg](https://api.flyingharley.dev/uploads/city_2_72e7e40eab.jpg)
![lake.jpeg](https://api.flyingharley.dev/uploads/lake_66d45909fd.jpeg)



![dishes-1.jpg](https://api.flyingharley.dev/uploads/dishes_1_9567288e83.jpg)
_First lunch..._

Walking a lot...
![street-2.jpg](https://api.flyingharley.dev/uploads/street_2_e281b83dad.jpg)
![street-1.jpg](https://api.flyingharley.dev/uploads/street_1_7958206b78.jpg)
_Crowded street_


![pagoda-1.jpg](https://api.flyingharley.dev/uploads/pagoda_1_8a2fb44b0b.jpg)
_Senso-ji_

![pagoda-2.jpeg](https://api.flyingharley.dev/uploads/pagoda_2_47a21070cf.jpeg)
![mrt.jpg](https://api.flyingharley.dev/uploads/mrt_b4903f9e3c.jpg)

# Hack days
Heading to LY office... 
Just walk... 🚶‍♂️🚶‍♂️🚶‍♂️
![office-building.jpg](https://api.flyingharley.dev/uploads/office_building_752765f673.jpg)
![office-building-2.jpg](https://api.flyingharley.dev/uploads/office_building_2_41e4f3514a.jpg)
_There it is! Tokyo Garden Terrace Kioicho_


![office-1.jpg](https://api.flyingharley.dev/uploads/office_1_750887d6c3.jpg)
_Finally found Brown and his friends..._


![office-3.jpg](https://api.flyingharley.dev/uploads/office_3_5a1fed86c2.jpg)
![office-2.jpg](https://api.flyingharley.dev/uploads/office_2_91165c3629.jpg)

![hackday-start.jpg](https://api.flyingharley.dev/uploads/hackday_start_ecbc14c751.jpg)
_It's hack time!_

![hackday-1.jpg](https://api.flyingharley.dev/uploads/hackday_1_e4ac2ca0a9.jpg)
![working.jpg](https://api.flyingharley.dev/uploads/working_749fd8ab5e.jpg)
_Didn't realize we were quite serious 😅_

![toy-1.jpg](https://api.flyingharley.dev/uploads/toy_1_df10f535ce.jpg)
_Let's see what's inside this little cute toy..._
![toy-2.jpg](https://api.flyingharley.dev/uploads/toy_2_9f57f5304e.jpg)
_When it became a real mess... 🤯_

![foods-2.jpg](https://api.flyingharley.dev/uploads/foods_2_2685a4e6a0.jpg)
![foods.jpg](https://api.flyingharley.dev/uploads/foods_49653426df.jpg)
_Break time 🤤_

### Presentation
After 2 days, time for presentation & exhibition...

![presentation-2.jpg](https://api.flyingharley.dev/uploads/presentation_2_f69e1d3a24.jpg)
_So many incredible ideas which can blow our mind..._

![presentation.jpg](https://api.flyingharley.dev/uploads/presentation_88a98931c1.jpg)
_There were only 90 seconds. Fortunately, I managed to catch my breath..._
![exhibition.jpg](https://api.flyingharley.dev/uploads/exhibition_30e7b07511.jpg)
![competition-1.jpeg](https://api.flyingharley.dev/uploads/competition_1_8a25b18bc1.jpeg)
We did a great job, bros! 💪


large_event-hackday-start.jpg

medium_event-hackday-start.jpg

small_event-hackday-start.jpg

thumbnail_event-hackday-start.jpg

event-hackday-start.jpg

Earlier of this month, I and my teammates participated in a hackathon organized by LY Corp, which was open to all employees from LY's global offices. 
It was an incredible experience with many exciting moments. Let's take a look...

My business trip to Japan in 2025


## Part 2: Behind the Scene of ObservableObject and MVVM Implementation

### Behind the Scene of **ObservableObject**

#### Construction and Internal Mechanism

**ObservableObject** is a protocol in the Combine framework that allows reference types to work with SwiftUI's reactive data binding system. When a class conforms to **ObservableObject**, Combine automatically creates an **objectWillChange** publisher. This publisher notifies subscribers just before any property marked with **@Published** changes. The publisher, called **ObservableObjectPublisher**, is a specialized version of **PassthroughSubject** that emits events without any data.

![SwiftUI ObservableObject Internal Mechanism and Data Flow](https://api.flyingharley.dev/uploads/observable_Object_46f52ece4e.jpg)
*SwiftUI ObservableObject Internal Mechanism and Data Flow*

This is achieved through runtime introspection, where the Combine framework inspects the class to find **@Published** properties. For each of these properties, Combine connects the **objectWillChange** publisher, linking property changes to notifications. The **@Published** property wrapper itself is a computed property that calls **objectWillChange.send()** in its setter before updating the stored value.

The timing of these notifications is "will change" rather than "did change," which is done for performance reasons. Early SwiftUI betas used a "did change" model, but this was changed to "will change" to allow for better coalescing of updates. [As discussed in a community forum, this change lets SwiftUI group multiple property changes into a single view update, improving rendering performance](https://www.reddit.com/r/swift/comments/gb8742/reasoning_behind_observableobjects/).

#### Property Wrapper Integration and Lifecycle

The way **ObservableObject** works with SwiftUI property wrappers like **@ObservedObject** and **@StateObject** involves complex lifecycle management. **@ObservedObject** creates a subscription to the **ObservableObject**'s **objectWillChange** publisher, but it doesn't control the object's lifecycle. It assumes that something else is keeping a strong reference to the object.

![A flowchart illustrating when to use @ObservedObject versus @StateObject in SwiftUI views.](https://api.flyingharley.dev/uploads/flow_chart_8496e52ddd.jpg)
*A flowchart illustrating when to use @ObservedObject versus @StateObject in SwiftUI views.*

**@StateObject**, on the other hand, both manages the subscription and owns the object's lifecycle. When a view uses **@StateObject**, SwiftUI allocates memory for the object and keeps it alive for as long as the view exists. This ensures that the same object instance is used even when the view is recreated, preventing state loss.

Both **@ObservedObject** and **@StateObject** conform to the [**DynamicProperty**](https://developer.apple.com/documentation/swiftui/dynamicproperty) protocol, which is the foundation for SwiftUI property wrappers involved in the view update cycle. This protocol requires an **update()** method that SwiftUI calls before re-rendering a view's body, allowing property wrappers to refresh their state.

The subscription system uses Combine's cancellation features to manage memory. When a view is deallocated, SwiftUI automatically cancels its subscriptions to prevent memory leaks. However, this only works if the property wrapper itself is deallocated correctly, which depends on proper usage.

### MVVM Implementation with **ObservableObject**

#### Lifecycle Management Challenges

Using **ObservableObject** for MVVM in SwiftUI brings up some lifecycle management issues. These arise from the fact that SwiftUI views are value types (structs) that can be recreated often, while **ObservableObject** instances are reference types (classes) that should persist.

Understanding how different property wrappers manage memory is key to avoiding lost state. With **@StateObject**, SwiftUI takes ownership of the object's lifecycle, creating it once when the view first appears and keeping it until the view is gone.

```swift
struct CounterView: View {
    @StateObject private var viewModel = CounterViewModel()
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment") {
                viewModel.incrementCounter()
            }
            Text("View recreated: \(UUID())")
        }
    }
}

class CounterViewModel: ObservableObject {
    @Published var count = 0
    
    init() {
        print("ViewModel created: \(Date())")
    }
    
    func incrementCounter() {
        count += 1
    }
}
```

In contrast, **@ObservedObject** does not manage the object's lifecycle. It assumes that the object is being kept alive by some other part of the application. This can be a problem if developers mistakenly think **@ObservedObject** works like **@StateObject**. If a parent view updates and recreates a child view that uses **@ObservedObject**, the child view might lose its connection to the original object if it isn't being retained elsewhere.

A common mistake is creating an **ObservableObject** inline inside a view's initializer or as a computed property when using **@ObservedObject**.

```swift
// Problematic pattern - object will be recreated on every view update
struct ProblematicView: View {
    @ObservedObject var viewModel = CounterViewModel() // Wrong usage
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment") {
                viewModel.incrementCounter()
            }
        }
    }
}
```

This leads to the **CounterViewModel** being recreated every time the parent view updates, which resets its state and can cause confusing behavior.

#### Property Wrapper Selection and Best Practices

The differences between **@StateObject** and **@ObservedObject** come down to their design and intended use. **@StateObject** uses SwiftUI's internal storage to cache the object instance, ensuring that even when the view struct is recreated, the same object reference is maintained.

Behind the scenes, **@StateObject** uses SwiftUI's storage system to keep object references across view updates. When a view is first created, **@StateObject** allocates memory and initializes the object once. On subsequent view recreations, it retrieves the cached object, ensuring state consistency.

```swift
struct ParentView: View {
    @State private var toggleState = false
    
    var body: some View {
        VStack {
            // This view will be recreated when toggleState changes
            // but @StateObject ensures viewModel persists
            ChildViewWithStateObject()
            
            Button("Toggle Parent State") {
                toggleState.toggle()
            }
            
            Text("Parent state: \(toggleState)")
        }
    }
}

struct ChildViewWithStateObject: View {
    @StateObject private var viewModel = PersistentViewModel()
    
    var body: some View {
        VStack {
            Text("Value: \(viewModel.value)")
            Button("Increment") {
                viewModel.increment()
            }
        }
        .onAppear {
            print("Child view appeared with viewModel: \(viewModel.id)")
        }
    }
}

class PersistentViewModel: ObservableObject {
    @Published var value = 0
    let id = UUID()
    
    func increment() {
        value += 1
    }
}
```

**@ObservedObject**, however, doesn't provide storage management. It simply observes an existing object. It's designed for cases where the object's lifecycle is managed externally, such as by a parent view or a dependency injection container. The key is that **@ObservedObject** expects the object to remain valid while it's being observed.

This distinction is important because of how SwiftUI updates views. When a view needs to be redrawn, SwiftUI creates a new instance of the view struct. At this point, **@StateObject** retrieves the cached object from its managed storage, while **@ObservedObject** expects the same object to be passed in from an external source.

```swift
struct DataFlowExample: View {
    @StateObject private var dataSource = DataSource()
    
    var body: some View {
        VStack {
            // Correct: Pass the StateObject-managed instance to children
            DisplayView(dataSource: dataSource)
            ModificationView(dataSource: dataSource)
        }
    }
}

struct DisplayView: View {
    @ObservedObject var dataSource: DataSource
    
    var body: some View {
        Text("Current data: \(dataSource.currentValue)")
    }
}

struct ModificationView: View {
    @ObservedObject var dataSource: DataSource
    
    var body: some View {
        Button("Update Data") {
            dataSource.updateValue()
        }
    }
}

class DataSource: ObservableObject {
    @Published var currentValue = "Initial"
    
    func updateValue() {
        currentValue = "Updated at \(Date().timeIntervalSince1970)"
    }
}
```

This pattern ensures that the **DataSource** instance is created and owned by the parent view using **@StateObject**, and child views observe that same instance using **@ObservedObject**.

#### State Persistence and Memory Management
As ObservableObject is implemented by reference type, it requires developers to be mindful of potential retain cycles, especially when using closures or delegates.

```swift
class NetworkService: ObservableObject {
    @Published var isLoading = false
    @Published var data: String = ""
    
    private var cancellables = Set<AnyCancellable>()
    
    func fetchData() {
        isLoading = true
        
        // Potential retain cycle if not handled properly
        URLSession.shared.dataTaskPublisher(for: URL(string: "https://api.example.com")!)
            .map { $0.data }
            .sink(
                receiveCompletion: { [weak self] _ in
                    self?.isLoading = false
                },
                receiveValue: { [weak self] data in
                    self?.data = String(data: data, encoding: .utf8) ?? ""
                }
            )
            .store(in: &cancellables)
    }
    
    deinit {
        cancellables.removeAll()
    }
}
```

The use of _[weak self]_ in closures prevents retain cycles that could keep the **NetworkService** instance alive even after its view is gone.

That's all about this part. We've seen that the traditional implementation of MVVM in SwiftUI relies on the ObservableObject protocol, which uses Combine's objectWillChange publisher to notify views of state changes from @Published properties. Effective state management requires using @StateObject to create and own the ViewModel, ensuring its persistence throughout the view's lifecycle, while child views use @ObservedObject to simply observe it. Misusing these wrappers often leads to state loss, a common pitfall for developers. Additionally, because ObservableObjects are reference types, developers are responsible for manually preventing memory leaks and retain cycles, typically by using [weak self] in closures.

In the next part, we will discover the _@Observable_ macro and its benefits.

large_Architectural Diagram Blue.jpeg

medium_Architectural Diagram Blue.jpeg

small_Architectural Diagram Blue.jpeg

thumbnail_Architectural Diagram Blue.jpeg

Architectural Diagram Blue.jpeg

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

## Part 1: The MVVM and its integration with SwiftUI Development

### Understanding MVVM Architecture Fundamentals

#### Core Concepts and Components

The **Model-View-ViewModel (MVVM)** is an architectural pattern, originally from Microsoft architects *Ken Cooper* and *Ted Peters*, designed to separate the graphical user interface from the business logic. It organizes an application into three key layers to improve how easy it is to maintain and test.

-   The **Model** is responsible for the application's data and business logic, such as domain objects and data access.
-   The **View** is the user interface that users see and interact with, responsible for displaying data and capturing user actions.
-   The **ViewModel** serves as a bridge between the Model and the View. It prepares data from the Model to be displayed in the View and handles user interactions and presentation logic.

![MVVM Architecture Pattern Components and Data Flow](https://api.flyingharley.dev/uploads/MVVM_Pattern_9d0942fa4f.png)

*MVVM Architecture Pattern Components and Data Flow - [wikipedia](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel)*

The main goal of MVVM is to eliminate direct dependencies between the View and the Model. This separation keeps Views from being tied to specific Model implementations, which allows for greater flexibility and reusability. The ViewModel acts as a converter, transforming data from the Model into a format that the View can easily use. In this way, it functions as a mediator, organizing access to back-end logic based on what the View needs.

#### Architectural Benefits and Rationale

MVVM addresses several common problems in application development, particularly with user interfaces. One of the main reasons for its creation was to remove UI code from the view layer by using data binding. [This approach, as detailed here, allows UI/UX designers to focus on the interface while developers work on the business logic](https://www.ramotion.com/blog/what-is-mvvm/). This separation of responsibilities helps teams work in parallel and can significantly boost productivity.

#### MVVM for iOS Development
For iOS development, we also care about the navigation between "screens" and their hierarchy, hence a separate *Coordinator* is needed. Those can be described with this cool diagram:

![MVVM-C.png](https://api.flyingharley.dev/uploads/MVVM_C_d637bdddbc.png)
*[App Architecture - iOS Application Design Patterns in Swift](https://www.objc.io/books/app-architecture)*

##### Advantages of MVVM over MVC

To fully appreciate MVVM, it's helpful to compare it to its predecessor, Model-View-Controller (MVC). In the MVC pattern, the **Controller** is responsible for handling user input and updating both the **Model** and the **View**. 

While MVC separates concerns, it often leads to a tight coupling between the View and the Controller. The Controller can become a massive class that handles all the logic, making it difficult to test and maintain. This is especially true in UI frameworks where the View and Controller are often closely linked.

MVVM improves on MVC in several key ways:

1.  **Enhanced Separation of Concerns**: MVVM introduces the **ViewModel**, which acts as a more specialized intermediary than the Controller. The **ViewModel** is responsible for preparing and providing data for the **View**, but it has no direct reference to the **View** itself. This decoupling is a significant improvement, and the modular design makes it easier to test individual components in isolation, leading to more reliable and maintainable code.

2.  **Data Binding**: This is a core advantage of **MVVM**. The **View** is automatically updated when the **ViewModel**'s data changes, thanks to data binding. This eliminates a large amount of boilerplate code that would otherwise be needed to manually update the **View** from the **Controller**. In SwiftUI, this is achieved through property wrappers like _@StateObject_ and _@ObservedObject_ (and more recently _@State_ with _@Observable_ objects). In UIKit or AppKit, it's usually one of the reactive frameworks such as **Combine**, **RxSwift**, ...

3.  **Improved Testability**: Because the **ViewModel** is not tied to the UI, it can be tested independently of any UI components without requiring complex UI component mocking. This makes unit testing the application's logic much simpler and more robust compared to testing a Controller that might be tightly coupled with the UI framework's APIs.

4.  **Better for Collaboration and Reusability**: The clear separation allows UI designers to work on the View while developers work on the **ViewModel** and **Model**, with less chance of conflicts. Additionally, MVVM promotes code reuse since **ViewModels** can be shared across multiple Views or even different platforms. This is particularly useful in cross-platform development, where business logic can remain consistent while the UI is adapted for each platform.

#### SwiftUI-Specific Advantages

SwiftUI's declarative programming style works very well with the principles of MVVM. The combination of SwiftUI's reactive data binding and MVVM's separation of concerns leads to better-organized and more maintainable apps. [A key benefit, as noted in the SwiftUI Cookbook, is that the framework's built-in data binding eliminates much of the boilerplate code that was traditionally needed to sync ViewModels with Views](https://www.kodeco.com/books/swiftui-cookbook/v1.0/chapters/2-understanding-observableobject-observedobject). This lets developers focus on the application's logic rather than on manual state synchronization, which results in cleaner, more concise code.

The declarative nature of SwiftUI also benefits from MVVM's structured approach to state management. Views can declaratively bind to ViewModel properties, and they will automatically update when the underlying data changes, without needing manual refresh calls. This reactive system keeps the UI synchronized with the application's state while maintaining a clear separation between the presentation and business logic layers. The pattern also helps in organizing complex view hierarchies by allowing related views to share common view models through dependency injection or as environment objects.

Let's take some conceptual code examples to illustrate the difference.

__Conceptual MVC-like approach in SwiftUI:__
In a pure MVC, the controller would handle the logic. In SwiftUI, views are more central, but one might be tempted to put logic inside the view, which acts a bit like a controller.

```swift
// A view doing too much, like a combined View-Controller
struct CounterView_PoorSeparation: View {
    @State private var count = 0

    var body: some View {
        VStack {
            // View logic
            if count > 10 {
                Text("Count is large!")
            } else {
                Text("Count: \(count)")
            }
            
            Button("Increment") {
                // Business logic inside the view
                self.increment()
            }
        }
    }

    // Business logic mixed in
    private func increment() {
        // Here we might have more complex logic, like checks or API calls
        self.count += 1
    }
}
```
The view above mixes presentation logic (the "if" statement) with business logic (the "increment" function). This becomes hard to test and reuse.

__MVVM approach in SwiftUI:__
With MVVM, we separate this logic cleanly.

```swift
// The Model
struct Counter {
    var value: Int = 0
}

// The ViewModel
class CounterViewModel: ObservableObject {
    @Published private var counter = Counter()
    
    var displayText: String {
        if counter.value > 10 {
            return "Count is large!"
        } else {
            return "Count: \(counter.value)"
        }
    }

    func increment() {
        // All business logic is here, testable and separate.
        counter.value += 1
    }
}

// The View
struct CounterView_MVVM: View {
    @StateObject private var viewModel = CounterViewModel()

    var body: some View {
        VStack {
            Text(viewModel.displayText) // View only displays data from ViewModel
            Button("Increment") {
                viewModel.increment() // View only sends actions to ViewModel
            }
        }
    }
}
```
In the MVVM example, the "CounterView_MVVM" is simple and only responsible for layout. The "CounterViewModel" contains all the presentation and business logic, and it is easily testable without needing any UI. This separation makes MVVM a more robust choice for modern application development.

That's it for this part! In the next part, we will dive deeper into the MVVM Implementation with SwiftUI and its _ObservableObject_ protocol and more. Stay tuned!

This article provides a deep dive into the Model-View-ViewModel (MVVM) architecture, beginning with its fundamental principles and its advantages over the classic Model-View-Controller (MVC) pattern. It then explores the integration of MVVM within SwiftUI, covering both the traditional `ObservableObject` implementation and the modern `@Observable` macro. The discussion details the inner workings of `ObservableObject`, its lifecycle challenges, and common implementation patterns. Subsequently, it transitions to the `@Observable` macro, highlighting its performance benefits, simplified syntax, and best practices, complete with code examples. The article also addresses potential drawbacks, offers guidance on choosing between the two models, and concludes with a look at the ongoing evolution of architectural patterns in the SwiftUI ecosystem.

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

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.

All Posts

The first step to SwiftUI's Animation System: From Architecture to Advanced iOS 17 Features

TextKit2: A Top-Down Approach

My business trip to Japan in 2025

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

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

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