SwiftUI Transactions & Update Propagation

🧠 What Is a SwiftUI Transaction? ## 🔄 The Update Propagation Pipeline ## 🎬 Implicit Animations = Transactions ## ⚠️ Why Some Views Animate and Others Don’t ## 🧩 The Transaction Type (Explicit Control) ## 🚫 Disabling Animations Selectively ## 🔁 Nested Transactions (Who Wins?) ## ⚖️ Transaction vs .animation(_:value:) ## 🧠 Update Propagation Rules (Critical) ## 🧵 Async Updates & Transactions ## ⚠️ Common Bugs Caused by Transaction Misuse ## 🧠 Mental Model to Remember ## 🚀 Final Thoughts SwiftUI updates don’t just “happen”. Every state change flows through a transaction — and understanding that flow is what separates: Most SwiftUI developers use transactions without realizing it. This post explains what transactions are, how updates propagate, and how SwiftUI decides what animates, what re-renders, and what doesn’t — using modern SwiftUI patterns. A Transaction is a container that carries metadata about a state change. Every time state changes, SwiftUI creates a transaction. Even when you don’t write one. State mutation ↓ Transaction created ↓ View invalidation ↓ Body recomputation ↓ Layout pass ↓ Diffing ↓ Rendering (with or without animation) Transactions flow down the view tree. Children inherit transaction context from parents. No animation code inside views — just data flow. If isVisible changes outside an animation transaction → no animation. You can intercept or modify transactions: Sometimes you don’t want animations. This prevents animation noise. Text("B") does not animate — even though its parent does. Creates a scoped implicit transaction. SwiftUI propagates updates: This is why clean state ownership matters. Async updates do not automatically animate. To animate async results: Transactions must exist at the moment of mutation. ❌ Animations firing multiple times Cause: repeated state mutations in a loop ❌ Animations not firing Cause: mutation outside transaction ❌ Animations restarting Cause: identity reset (not a transaction issue) ❌ Janky list animations Cause: large diff + implicit animation State changes create transactions. Transactions define animation behavior. Views simply respond. SwiftUI animations are not imperative. They are data-driven side effects of transactions. Understanding transactions gives you: Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: withAnimation(.easeInOut) { isExpanded.toggle() } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: withAnimation(.easeInOut) { isExpanded.toggle() } CODE_BLOCK: withAnimation(.easeInOut) { isExpanded.toggle() } CODE_BLOCK: Text("Hello") .opacity(isVisible ? 1 : 0) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Text("Hello") .opacity(isVisible ? 1 : 0) CODE_BLOCK: Text("Hello") .opacity(isVisible ? 1 : 0) CODE_BLOCK: .transaction { tx in tx.animation = .spring() } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: .transaction { tx in tx.animation = .spring() } CODE_BLOCK: .transaction { tx in tx.animation = .spring() } CODE_BLOCK: .transaction { tx in tx.disablesAnimations = true } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: .transaction { tx in tx.disablesAnimations = true } CODE_BLOCK: .transaction { tx in tx.disablesAnimations = true } CODE_BLOCK: withAnimation(.easeIn) { VStack { Text("A") Text("B") .transaction { $0.animation = nil } } } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: withAnimation(.easeIn) { VStack { Text("A") Text("B") .transaction { $0.animation = nil } } } CODE_BLOCK: withAnimation(.easeIn) { VStack { Text("A") Text("B") .transaction { $0.animation = nil } } } CODE_BLOCK: .animation(.easeInOut, value: isExpanded) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: .animation(.easeInOut, value: isExpanded) CODE_BLOCK: .animation(.easeInOut, value: isExpanded) CODE_BLOCK: Task { await load() isLoaded = true // no animation } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Task { await load() isLoaded = true // no animation } CODE_BLOCK: Task { await load() isLoaded = true // no animation } CODE_BLOCK: await MainActor.run { withAnimation { isLoaded = true } } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: await MainActor.run { withAnimation { isLoaded = true } } CODE_BLOCK: await MainActor.run { withAnimation { isLoaded = true } } - smooth, predictable animations - from glitchy, half-animated UI - from views updating “too much” - from state changes not animating at all - whether animations are enabled - what animation to use - whether updates should be immediate - context for view updates - Mutates state - Wraps that mutation in a transaction with animation metadata - propagates that transaction - animates any animatable values affected by the change - changed inside the same transaction - are animatable - and are diffed as changed - override parent animations - disable animations for subtrees - enforce consistent motion - initial layout - list updates - pagination inserts - state restoration - performance-critical paths - inner transactions override outer ones - closest transaction wins - no transaction = inherits parent - .animation(value:) is declarative - withAnimation is imperative - .animation(value:) for simple view-driven animation - withAnimation for event-driven state changes - top-down through the hierarchy - only to views that depend on changed state - stopping at unchanged identity boundaries - sibling views don’t update unless needed - children update only if inputs changed - transactions don’t magically animate everything - disable animations for list updates - animate only user-driven changes - full control over animation behavior - predictable update propagation - smoother UI - better performance - fewer “why did this animate?” bugs