1. Introduction — Why SwiftUI “Stutters” When It Shouldn’t You built a polished screen in SwiftUI, but scrolling through a list reveals micro-stutters. The profiler shows thousands of body invocations. You start doubting SwiftUI — "maybe UIKit was better after all?" body The problem isn’t SwiftUI. The problem is a lack of understanding of how it decides what to update. Beneath the declarative API lies a powerful mechanism called the Attribute Graph — a directed acyclic graph (DAG) that tracks every dependency in your UI and updates exactly what needs updating. Nothing more, nothing less. how it decides what to update Attribute Graph But only if you don’t get in its way. In this article, we’ll cover: How the Attribute Graph is structured What re-evaluate and re-draw mean, and why they are fundamentally different How invalidation works — the process of marking “dirty” nodes Common mistakes that cause unnecessary recalculations How to optimize your code so SwiftUI performs at its best How the Attribute Graph is structured What re-evaluate and re-draw mean, and why they are fundamentally different How invalidation works — the process of marking “dirty” nodes Common mistakes that cause unnecessary recalculations How to optimize your code so SwiftUI performs at its best 2. What Is the Attribute Graph? The Attribute Graph is a directed acyclic graph (DAG) that SwiftUI constructs from your view hierarchy. It consists of three layers: directed acyclic graph (DAG) Source nodes — values from @State, @Binding, @Environment, @ObservedObject Computation nodes — the results of each view’s body call Render nodes — the concrete display layers (backing CALayer/UIView instances) Source nodes — values from @State, @Binding, @Environment, @ObservedObject Source nodes @State @Binding @Environment @ObservedObject Computation nodes — the results of each view’s body call Computation nodes body Render nodes — the concrete display layers (backing CALayer/UIView instances) Render nodes CALayer UIView The edges of the graph represent dependencies: “this body depends on this @State dependencies body How Dependencies Are Formed Here’s the key insight: a dependency is recorded at the moment of access, not at the point of declaration. at the moment of access struct ProfileView: View { @StateObject var user: UserModel // properties: name, avatar, settings var body: some View { // SwiftUI records: ProfileView.body depends on user.name Text(user.name) // user.settings is NOT read → changing settings // will NOT trigger a re-evaluate of this view } } struct ProfileView: View { @StateObject var user: UserModel // properties: name, avatar, settings var body: some View { // SwiftUI records: ProfileView.body depends on user.name Text(user.name) // user.settings is NOT read → changing settings // will NOT trigger a re-evaluate of this view } } During the first invocation of body, SwiftUI records which data sources the view accessed. This forms the edges of the graph. An important nuance: with ObservableObject, tracking operates at the level of the entire object, whereas with @Observable (iOS 17+), it operates at the level of individual properties. We'll explore this distinction in the optimization section. body ObservableObject entire object @Observable individual properties Identity and Lifetime The graph is tied to the identity of each view. Identity is determined in one of two ways: identity Structural position — the view’s location within the body hierarchy (used by default) Explicit .id() — a manually assigned identifier Structural position — the view’s location within the body hierarchy (used by default) Structural position body Explicit .id() — a manually assigned identifier Explicit .id() When a view’s identity changes, its graph node is destroyed and recreated — all @State in child views is reset. Understanding this is essential to avoid accidentally losing state. destroyed and recreated @State 3. Re-evaluate vs. Re-draw — The Critical Distinction This is the central concept of the article. The two terms sound similar, but they mean fundamentally different things. Re-evaluate (Recalculating body) A node’s value in the graph changes (e.g., a @State property is updated via .wrappedValue) SwiftUI marks dependent nodes as “dirty” (invalidated) On the next render cycle, it calls body on the marked views body returns a new view tree (these are just lightweight structs — cheap to create) A node’s value in the graph changes (e.g., a @State property is updated via .wrappedValue) @State .wrappedValue SwiftUI marks dependent nodes as “dirty” (invalidated) On the next render cycle, it calls body on the marked views body body returns a new view tree (these are just lightweight structs — cheap to create) body struct CounterView: View { @State private var count = 0 var body: some View { let _ = Self._printChanges() // 🔍 Prints: "CounterView: _count changed." VStack { Text("Count: \(count)") Button("Increment") { count += 1 } HeavyView() // Will NOT be re-evaluated if it doesn't depend on count } } } struct CounterView: View { @State private var count = 0 var body: some View { let _ = Self._printChanges() // 🔍 Prints: "CounterView: _count changed." VStack { Text("Count: \(count)") Button("Increment") { count += 1 } HeavyView() // Will NOT be re-evaluated if it doesn't depend on count } } } Re-evaluate is a function call that returns lightweight structs. It’s fast. function call Re-draw (Rendering) After re-evaluate, SwiftUI performs a structural diff — comparing the old and new view trees. It then updates only the changed backing layers (the underlying CALayer/UIView instances). This involves GPU work, layout calculations, and animations — an expensive operation. structural diff only the changed expensive An Analogy Re-evaluate is re-reading the recipe. Re-draw is actually replacing an ingredient on the plate. The key insight: frequent re-evaluations are normal — they’re cheap. Problems arise when: The key insight: A re-evaluate is unnecessary — a view recalculates even though its data hasn’t changed The body is heavy — objects are allocated, computations are performed inline A re-evaluate is unnecessary — a view recalculates even though its data hasn’t changed unnecessary The body is heavy — objects are allocated, computations are performed inline body heavy 4. Invalidation — How the Graph Decides What to Recalculate 4. Invalidation — How the Graph Decides What to Recalculate Invalidation is the process by which SwiftUI marks graph nodes as “dirty” and schedules them for recalculation. The crucial point is that it does this surgically, not across the entire tree. surgically I prepared mini web-app for fully understood how it works please visit https://pavelandreev13.github.io/SwiftUI_attribute_graph/ I prepared mini web-app for fully understood how it works please visit I prepared mini web-app for fully understood how it works please visit https://pavelandreev13.github.io/SwiftUI_attribute_graph/ https://pavelandreev13.github.io/SwiftUI_attribute_graph/ https://pavelandreev13.github.io/SwiftUI_attribute_graph/ https://pavelandreev13.github.io/SwiftUI_attribute_graph/ The Process, Step by Step Step 1 — At rest. All graph nodes are valid. SwiftUI recalculates nothing — the UI is stable. Step 1 — At rest. Step 2 — A change occurs. The user taps a button; count becomes 1. SwiftUI detects that a node's value has changed and begins traversing its outgoing edges. Step 2 — A change occurs. count Step 3 — Marking (invalidation). SwiftUI follows only the edges leading from the changed node. CounterView.body reads count — it's marked dirty. HeaderView, BgView, and ProfileView don't depend on count — they are skipped entirely. Step 3 — Marking (invalidation). only the edges CounterView.body count HeaderView BgView ProfileView count Step 4 — Re-evaluate. On the next render cycle, SwiftUI calls body only on the marked views. It receives a new UI description. The remaining body methods are never invoked. Step 4 — Re-evaluate. body only body Step 5 — Result. The diff between the old and new trees reveals that only one Text has changed. That element alone is re-drawn. The other three render layers are untouched. The graph is stable once again. Step 5 — Result. Text Coalescing — Batching Changes Invalidation is a synchronous marking step, while re-evaluate is a deferred recalculation. SwiftUI batches multiple changes within a single cycle (coalescing): synchronous marking deferred recalculation Button("Update All") { count += 1 // marks CounterView dirty title = "New" // marks HeaderView dirty // Re-evaluate happens ONCE, not twice } Button("Update All") { count += 1 // marks CounterView dirty title = "New" // marks HeaderView dirty // Re-evaluate happens ONCE, not twice } This means you can safely mutate multiple @State properties in sequence within the same block — SwiftUI won't recalculate intermediate states. @State 5. Anti-pattern “AnyView” 5. Anti-pattern “AnyView” AnyView erases the type — SwiftUI sees only "AnyView → AnyView" and cannot determine whether the content has actually changed. The result: a full re-draw every time. With @ViewBuilder, SwiftUI knows the concrete type _ConditionalContent<TextView, ImageView> and performs a precise, targeted diff. AnyView @ViewBuilder _ConditionalContent<TextView, ImageView> // ❌ SwiftUI can't compare types — full re-draw every time func makeView(for type: ContentType) -> AnyView { switch type { case .text: return AnyView(TextView()) case .image: return AnyView(ImageView()) } } // ✅ SwiftUI knows the exact types — efficient diff @ViewBuilder func makeView(for type: ContentType) -> some View { switch type { case .text: TextView() case .image: ImageView() } } // ❌ SwiftUI can't compare types — full re-draw every time func makeView(for type: ContentType) -> AnyView { switch type { case .text: return AnyView(TextView()) case .image: return AnyView(ImageView()) } } // ✅ SwiftUI knows the exact types — efficient diff @ViewBuilder func makeView(for type: ContentType) -> some View { switch type { case .text: TextView() case .image: ImageView() } } 6. Unnecessary Re-evaluations via Closures 6. Unnecessary Re-evaluations via Closures struct ParentView: View { @State private var count = 0 @State private var title = "Hello" var body: some View { VStack { Text("Count: \(count)") // ❌ The closure captures self → ChildView depends on ALL @State properties ChildView(action: { doSomething(count) }) // ✅ Pass the value directly — ChildView doesn't depend on count ChildView(value: count) } } } struct ParentView: View { @State private var count = 0 @State private var title = "Hello" var body: some View { VStack { Text("Count: \(count)") // ❌ The closure captures self → ChildView depends on ALL @State properties ChildView(action: { doSomething(count) }) // ✅ Pass the value directly — ChildView doesn't depend on count ChildView(value: count) } } } When you pass a closure into a child view, SwiftUI doesn’t analyze what the closure actually uses — it only sees that the closure captures self. That single fact makes the child view depend on the entire parent, not just the specific state property the closure touches. actually uses self entire parent Why this matters @State properties in SwiftUI are stored outside the struct, but self inside a View is the struct itself — a value type regenerated on every body evaluation. When ChildView receives a closure that captures self, its dependency graph now includes every @State property on ParentView: count, title, and anything else added in the future. The moment any of them changes, ChildView.body is marked dirty and re-evaluated — even if the closure never touches the changed property. @State self View body ChildView self @State ParentView count title any ChildView.body // ❌ title changes → ChildView re-evaluates even though it only uses count ChildView(action: { doSomething(count) }) // ❌ title changes → ChildView re-evaluates even though it only uses count ChildView(action: { doSomething(count) }) The compiler has no way to peer inside the closure at compile time and determine a narrower dependency. From SwiftUI’s perspective the closure is an opaque () -> Void blob that holds a reference to the whole parent struct. () -> Void The fix: pass values, not self Extracting the concrete value you need and passing it directly severs the hidden dependency chain. ChildView now only receives an Int. SwiftUI can diff that scalar precisely — the view re-evaluates if and only if count itself changes. ChildView Int count // ✅ title changes → ChildView is completely unaffected ChildView(value: count) // ✅ title changes → ChildView is completely unaffected ChildView(value: count) 7. Optimization: How to helping the Attribute Graph 7. Optimization: How to helping the Attribute Graph The principle: the fewer dependencies a body has, the less often it recalculates. Break views into smaller units not for "code cleanliness," but to isolate recalculation zones. body isolate recalculation zones // ❌ Monolith: any change → everything recalculatesstruct ProfileScreen: View { @StateObject var vm: ProfileVM var body: some View { VStack { Image(vm.avatar) Text(vm.name) BadgeView(vm.badges) StatsGrid(vm.stats) } } } // ✅ Granular: each block recalculates independentlystruct ProfileScreen: View { @StateObject var vm: ProfileVM var body: some View { VStack { AvatarView(avatar: vm.avatar) NameView(name: vm.name) BadgeListView(badges: vm.badges) StatsGrid(stats: vm.stats) } } } // ❌ Monolith: any change → everything recalculatesstruct ProfileScreen: View { @StateObject var vm: ProfileVM var body: some View { VStack { Image(vm.avatar) Text(vm.name) BadgeView(vm.badges) StatsGrid(vm.stats) } } } // ✅ Granular: each block recalculates independentlystruct ProfileScreen: View { @StateObject var vm: ProfileVM var body: some View { VStack { AvatarView(avatar: vm.avatar) NameView(name: vm.name) BadgeListView(badges: vm.badges) StatsGrid(stats: vm.stats) } } } Equatable to Prevent Unnecessary body Calls body By default, SwiftUI re-evaluates a child view’s body every time its parent re-evaluates — even if the child's inputs haven't changed at all. For lightweight views this is cheap enough to ignore. For a view that renders a complex chart, runs a heavy layout pass, or processes large datasets, that cost adds up fast. body The Equatable protocol gives you a way to short-circuit this: tell SwiftUI exactly what "nothing changed" means for your view, and it will skip the body call entirely when that condition holds. Equatable exactly body How it works under the hood When you call .equatable() on a view, SwiftUI wraps it in an EquatableView<YourView>. On every render cycle, before invoking body, SwiftUI calls your custom == implementation and compares the previous props with the new ones: .equatable() EquatableView<YourView> body == Parent re-evaluates│▼SwiftUI calls lhs == rhs│┌────┴────┐true false│ │▼ ▼skip body call body → diff → re-draw If == returns true, the entire subtree rooted at your view is frozen — no body, no diff, no re-draw. SwiftUI reuses the last rendered output as-is. == true body Why define a custom == instead of using Equatable synthesis == Equatable Swift can synthesize Equatable automatically if all stored properties are themselves Equatable. But automatic synthesis compares every field byte-for-byte. For a ChartData struct that contains arrays, nested objects, or computed properties, that comparison can be just as expensive as re-rendering — or it can produce false negatives that trigger unnecessary redraws. Equatable Equatable every field byte-for-byte ChartData A hand-written == lets you define a semantic equality: == semantic static func == (lhs: Self, rhs: Self) -> Bool { lhs.data.id == rhs.data.id && lhs.data.version == rhs.data.version } static func == (lhs: Self, rhs: Self) -> Bool { lhs.data.id == rhs.data.id && lhs.data.version == rhs.data.version } This says: “the data is the same if the identity and version haven’t changed.” Two integer comparisons replace a potentially deep structural diff of the entire ChartData object. This is the same idea behind database row versioning — you don't compare every column, you compare a version counter. ChartData What .equatable() does NOT do .equatable() It’s important to understand the boundaries of this optimization: If == returns true — body is skipped and the entire subtree is frozen. SwiftUI reuses the last rendered output unchanged. If == returns false — body runs normally and its result goes through the standard diff pipeline. If the view uses @State internally — internal state changes always trigger re-evaluation regardless of what == returns. The Equatable check only guards against prop changes coming from the parent. If the view uses @EnvironmentObject — environment changes bypass the == check entirely. The view will still re-evaluate whenever the observed object publishes a change. If .equatable() is omitted at the call site — == is never called, even if the view fully conforms to Equatable. The conformance alone does nothing; the modifier is what activates the optimization. If == returns true — body is skipped and the entire subtree is frozen. SwiftUI reuses the last rendered output unchanged. If == returns true body If == returns false — body runs normally and its result goes through the standard diff pipeline. If == returns false body If the view uses @State internally — internal state changes always trigger re-evaluation regardless of what == returns. The Equatable check only guards against prop changes coming from the parent. If the view uses @State internally == Equatable prop If the view uses @EnvironmentObject — environment changes bypass the == check entirely. The view will still re-evaluate whenever the observed object publishes a change. If the view uses @EnvironmentObject == If .equatable() is omitted at the call site — == is never called, even if the view fully conforms to Equatable. The conformance alone does nothing; the modifier is what activates the optimization. If .equatable() is omitted at the call site == Equatable When to reach for this pattern Equatable diffing is worth adding when all three conditions hold: Equatable The view is expensive — complex layout, heavy drawing, large data processing. The inputs have a cheap equality check — an id + version pair, a hash, a timestamp. If checking equality is as costly as re-rendering, you gain nothing. The parent re-evaluates frequently — if the parent is stable, the optimization never fires and adds only noise. The view is expensive — complex layout, heavy drawing, large data processing. The view is expensive The inputs have a cheap equality check — an id + version pair, a hash, a timestamp. If checking equality is as costly as re-rendering, you gain nothing. The inputs have a cheap equality check id version The parent re-evaluates frequently — if the parent is stable, the optimization never fires and adds only noise. The parent re-evaluates frequently A good rule of thumb: profile first with Instruments’ SwiftUI template. If you see ExpensiveView.body appearing in the call tree during interactions that shouldn't touch it, Equatable is one of the cleanest fixes available. ExpensiveView.body Equatable 8. List of anti-patterns: “What Not to Do” Checklist Here is a concise list of the most common mistakes that lead to unnecessary recalculations: Storing everything in a single ObservableObject — one objectWillChange signal updates every subscribed view Allocating objects inside body — DateFormatter(), NumberFormatter(), heavy models are recreated on every re-evaluate Using AnyView — type erasure makes diffing impossible Passing closures that capture unnecessary dependencies — the closure drags in the entire self Running heavy computations in body — filtering, sorting, or mapping arrays inline during tree construction Using @ObservedObject instead of @StateObject — the object is recreated on every parent re-evaluate Monolithic views with 5+ dependencies — one large body instead of several isolated ones Ignoring lazy containers — a VStack with ForEach over thousands of items instead of LazyVStack Storing everything in a single ObservableObject — one objectWillChange signal updates every subscribed view Storing everything in a single ObservableObject objectWillChange Allocating objects inside body — DateFormatter(), NumberFormatter(), heavy models are recreated on every re-evaluate Allocating objects inside body DateFormatter() NumberFormatter() Using AnyView — type erasure makes diffing impossible Using AnyView Passing closures that capture unnecessary dependencies — the closure drags in the entire self Passing closures that capture unnecessary dependencies self Running heavy computations in body — filtering, sorting, or mapping arrays inline during tree construction Running heavy computations in body Using @ObservedObject instead of @StateObject — the object is recreated on every parent re-evaluate Using @ObservedObject instead of @StateObject Monolithic views with 5+ dependencies — one large body instead of several isolated ones Monolithic views with 5+ dependencies body Ignoring lazy containers — a VStack with ForEach over thousands of items instead of LazyVStack Ignoring lazy containers VStack ForEach LazyVStack 9. Diagnostic Tools 9. Diagnostic Tools 1. Self._printChanges() The quickest way to see what triggered a re-evaluate: var body: some View { let _ = Self._printChanges() // Output: "MyView: _count changed." // or: "MyView: @self changed." (the view struct was recreated) Text("Hello") } var body: some View { let _ = Self._printChanges() // Output: "MyView: _count changed." // or: "MyView: @self changed." (the view struct was recreated) Text("Hello") } 2. os_signpost for Custom Measurements import os let log = OSLog(subsystem: "com.app", category: "performance") var body: some View { let signpostID = OSSignpostID(log: log) os_signpost(.begin, log: log, name: "HeavyView.body", signpostID: signpostID) defer { os_signpost(.end, log: log, name: "HeavyView.body", signpostID: signpostID) } // ... your body } import os let log = OSLog(subsystem: "com.app", category: "performance") var body: some View { let signpostID = OSSignpostID(log: log) os_signpost(.begin, log: log, name: "HeavyView.body", signpostID: signpostID) defer { os_signpost(.end, log: log, name: "HeavyView.body", signpostID: signpostID) } // ... your body } 3. Instruments → SwiftUI Template Xcode Instruments includes a SwiftUI template with two primary instruments: View Body — shows how many times each view’s body was called View Properties — shows which property changes triggered a re-evaluate View Body — shows how many times each view’s body was called View Body body View Properties — shows which property changes triggered a re-evaluate View Properties 4. Flash Updated Regions 4. Flash Updated Regions Attention: you need to connection with real device Attention: you need to connection with real device A built-in Xcode overlay that highlights every region of the screen being redrawn in real time — no third-party tools, no code changes required. Connect a real device — the feature is unavailable in the simulator Run the app via ⌘R and wait for it to fully launch In the menu bar: Debug → View Debugging → Rendering → Flash Updated Regions A checkmark confirms it’s active — takes effect instantly, no restart needed Connect a real device — the feature is unavailable in the simulator real device Run the app via ⌘R and wait for it to fully launch ⌘R In the menu bar: Debug → View Debugging → Rendering → Flash Updated Regions Debug → View Debugging → Rendering → Flash Updated Regions A checkmark confirms it’s active — takes effect instantly, no restart needed Every time SwiftUI issues a draw call to the GPU, the affected region flashes yellow on screen for a fraction of a second. No flash means SwiftUI reused the cached texture from the previous frame — which is exactly what you want for views that haven’t changed. The overlay is composited on top of your UI so the app remains fully interactive while you observe it. yellow Why it’s useful It answers the question “is this view redrawing when it shouldn’t?” instantly and visually — without opening Instruments or reading call stacks. You interact with the app naturally and watch whether flashes appear in places they have no reason to be: “is this view redrawing when it shouldn’t?” A static header flashing on every scroll → unnecessary parent re-evaluation All list cells flashing when one updates → overly broad @ObservableObject dependency The entire screen flashing on a button tap → monolithic view structure, state living too high in the hierarchy Any flash during idle → background state or timer invalidating views at rest A static header flashing on every scroll → unnecessary parent re-evaluation All list cells flashing when one updates → overly broad @ObservableObject dependency @ObservableObject The entire screen flashing on a button tap → monolithic view structure, state living too high in the hierarchy Any flash during idle → background state or timer invalidating views at rest The workflow is simple: tap something, see only what should redraw flash, investigate anything that shouldn’t. Fix it, re-interact, confirm the flash is gone — all without leaving the app. should 10. Conclusion The Attribute Graph is a contract between you and SwiftUI. You describe what to display; SwiftUI decides when and how to update it. The engine is optimized for surgical updates — but only if you isolate your dependencies correctly. what when how Three guiding principles: Granularity — small views with minimal dependencies outperform monoliths Precision — @Observable over ObservableObject, specific values over entire models Purity — body should be a pure function with no side effects and no allocations Granularity — small views with minimal dependencies outperform monoliths Granularity Precision — @Observable over ObservableObject, specific values over entire models Precision @Observable ObservableObject Purity — body should be a pure function with no side effects and no allocations Purity body Understanding the Attribute Graph transforms SwiftUI’s “magic” into a predictable, controllable tool. Once you can see how data flows through the graph, you know exactly why the UI updated — and how to ensure it only updates when it should. Closures are the most common source of invisible over-dependence in SwiftUI. The fix is almost always the same: extract the specific value the closure needs, pass it as a typed argument, and let the child close over that narrow value instead of the entire parent. invisible
