1# SwiftUI Performance Patterns Reference
2 
3## Table of Contents
4 
5- [Performance Optimization](#performance-optimization)
6- [Anti-Patterns](#anti-patterns)
7- [Summary Checklist](#summary-checklist)
8 
9## Performance Optimization
10 
11### 1. Avoid Redundant State Updates
12 
13SwiftUI doesn't compare values before triggering updates:
14 
15```swift
16// BAD - triggers update even if value unchanged
17.onReceive(publisher) { value in
18    self.currentValue = value  // Always triggers body re-evaluation
19}
20 
21// GOOD - only update when different
22.onReceive(publisher) { value in
23    if self.currentValue != value {
24        self.currentValue = value
25    }
26}
27```
28 
29### 2. Optimize Hot Paths
30 
31Hot paths are frequently executed code (scroll handlers, animations, gestures):
32 
33```swift
34// BAD - updates state on every scroll position change
35.onPreferenceChange(ScrollOffsetKey.self) { offset in
36    shouldShowTitle = offset.y <= -32  // Fires constantly during scroll!
37}
38 
39// GOOD - only update when threshold crossed
40.onPreferenceChange(ScrollOffsetKey.self) { offset in
41    let shouldShow = offset.y <= -32
42    if shouldShow != shouldShowTitle {
43        shouldShowTitle = shouldShow  // Fires only when crossing threshold
44    }
45}
46```
47 
48### 3. Pass Only What Views Need
49 
50**Avoid passing large "config" or "context" objects.** Pass only the specific values each view needs.
51 
52```swift
53// Good - pass specific values
54ThemeSelector(theme: config.theme)
55FontSizeSlider(fontSize: config.fontSize)
56 
57// Avoid - passing entire config (creates broad dependency)
58ThemeSelector(config: config)  // Notified of ALL config changes
59```
60 
61With `ObservableObject`, any `@Published` change triggers all observers. With `@Observable`, views update only when accessed properties change, but passing entire objects still creates broader dependencies than necessary.
62 
63### 4. Use Equatable Views
64 
65For views with expensive bodies, conform to `Equatable`:
66 
67```swift
68struct ExpensiveView: View, Equatable {
69    let data: SomeData
70 
71    static func == (lhs: Self, rhs: Self) -> Bool {
72        lhs.data.id == rhs.data.id  // Custom equality check
73    }
74 
75    var body: some View {
76        // Expensive computation
77    }
78}
79 
80// Usage
81ExpensiveView(data: data)
82    .equatable()  // Use custom equality
83```
84 
85**Caution**: If you add new state or dependencies to your view, remember to update your `==` function!
86 
87### 5. POD Views for Fast Diffing
88 
89**POD (Plain Old Data) views use `memcmp` for fastest diffing.** A view is POD if it only contains simple value types and no property wrappers.
90 
91```swift
92// POD view - fastest diffing
93struct FastView: View {
94    let title: String
95    let count: Int
96    
97    var body: some View {
98        Text("\(title): \(count)")
99    }
100}
101 
102// Non-POD view - uses reflection or custom equality
103struct SlowerView: View {
104    let title: String
105    @State private var isExpanded = false  // Property wrapper makes it non-POD
106    
107    var body: some View {
108        Text(title)
109    }
110}
111```
112 
113**Advanced Pattern**: Wrap expensive non-POD views in POD parent views:
114 
115```swift
116// POD wrapper for fast diffing
117struct ExpensiveView: View {
118    let value: Int
119    
120    var body: some View {
121        ExpensiveViewInternal(value: value)
122    }
123}
124 
125// Internal view with state
126private struct ExpensiveViewInternal: View {
127    let value: Int
128    @State private var item: Item?
129    
130    var body: some View {
131        // Expensive rendering
132    }
133}
134```
135 
136**Why**: The POD parent uses fast `memcmp` comparison. Only when `value` changes does the internal view get diffed.
137 
138### 6. Lazy Loading
139 
140Use lazy containers for large collections:
141 
142```swift
143// BAD - creates all views immediately
144ScrollView {
145    VStack {
146        ForEach(items) { item in
147            ExpensiveRow(item: item)
148        }
149    }
150}
151 
152// GOOD - creates views on demand
153ScrollView {
154    LazyVStack {
155        ForEach(items) { item in
156            ExpensiveRow(item: item)
157        }
158    }
159}
160```
161 
162**iOS 26+ note**: Nested scroll views containing lazy stacks now automatically defer loading their children until they are about to appear, matching the behavior of top-level lazy stacks. This benefits patterns like horizontal photo carousels inside a vertical scroll view.
163 
164> Source: "What's new in SwiftUI" (WWDC25, session 256)
165 
166### 7. Task Cancellation
167 
168Cancel async work when view disappears:
169 
170```swift
171struct DataView: View {
172    @State private var data: [Item] = []
173 
174    var body: some View {
175        List(data) { item in
176            Text(item.name)
177        }
178        .task {
179            // Automatically cancelled when view disappears
180            data = await fetchData()
181        }
182    }
183}
184```
185 
186### 8. Debug View Updates
187 
188**Use `Self._printChanges()` or `Self._logChanges()` to debug unexpected view updates.**
189 
190```swift
191struct DebugView: View {
192    @State private var count = 0
193    @State private var name = ""
194    
195    var body: some View {
196        #if DEBUG
197        let _ = Self._logChanges()  // Xcode 15.1+: logs to com.apple.SwiftUI subsystem
198        #endif
199        
200        VStack {
201            Text("Count: \(count)")
202            Text("Name: \(name)")
203        }
204    }
205}
206```
207 
208- `Self._printChanges()`: Prints which properties changed to standard output.
209- `Self._logChanges()` (iOS 17+): Logs to the `com.apple.SwiftUI` subsystem with category "Changed Body Properties", using `os_log` for structured output.
210 
211Both print `@self` when the view value itself changed and `@identity` when the view's persistent data was recycled.
212 
213**Why**: This helps identify which state changes are causing view updates. Isolating redraw triggers into single-responsibility subviews is often the fix -- extracting a subview means SwiftUI can skip its body when its inputs haven't changed.
214 
215### 9. Eliminate Unnecessary Dependencies
216 
217**Narrow state scope to reduce update fan-out.** Instead of passing an entire `@Observable` model to a row view (which creates a dependency on all accessed properties), pass only the specific values the view needs as `let` properties.
218 
219```swift
220// Bad - broad dependency on entire model
221struct ItemRow: View {
222    @Environment(AppModel.self) private var model
223    let item: Item
224    var body: some View { Text(item.name).foregroundStyle(model.theme.primaryColor) }
225}
226 
227// Good - narrow dependency
228struct ItemRow: View {
229    let item: Item
230    let themeColor: Color
231    var body: some View { Text(item.name).foregroundStyle(themeColor) }
232}
233```
234 
235**Avoid storing frequently-changing values in the environment.** Even when a view doesn't read the changed key, SwiftUI still checks all environment readers. This cost adds up with many views and frequent updates (geometry values, timers).
236 
237> Source: "Optimize SwiftUI performance with Instruments" (WWDC25, session 306)
238 
239### 10. @Observable Dependency Granularity
240 
241**Consider per-item `@Observable` state holders (one per row/item) to narrow update scope.** When multiple list items share a dependency on the same `@Observable` array, changing one element causes all items to re-evaluate their bodies.
242 
243```swift
244// BAD - all item views depend on the full favorites array
245@Observable
246class ModelData {
247    var favorites: [Landmark] = []
248 
249    func isFavorite(_ landmark: Landmark) -> Bool {
250        favorites.contains(landmark)
251    }
252}
253 
254struct LandmarkRow: View {
255    let landmark: Landmark
256    @Environment(ModelData.self) private var model
257 
258    var body: some View {
259        HStack {
260            Text(landmark.name)
261            if model.isFavorite(landmark) {
262                Image(systemName: "heart.fill")
263            }
264        }
265    }
266}
267 
268// GOOD - each item has its own observable view model
269@Observable
270class LandmarkViewModel {
271    var isFavorite: Bool = false
272}
273 
274struct LandmarkRow: View {
275    let landmark: Landmark
276    let viewModel: LandmarkViewModel
277 
278    var body: some View {
279        HStack {
280            Text(landmark.name)
281            if viewModel.isFavorite {
282                Image(systemName: "heart.fill")
283            }
284        }
285    }
286}
287```
288 
289**Why**: With the bad pattern, toggling one favorite marks the entire array as changed, causing every `LandmarkRow` to re-run its body. With per-item view models, only the toggled item's body runs.
290 
291> Source: "Optimize SwiftUI performance with Instruments" (WWDC25, session 306)
292 
293### 11. Off-Main-Thread Closures
294 
295**SwiftUI may call certain closures on a background thread for performance.** These closures must be `Sendable` and should avoid accessing `@MainActor`-isolated state directly. Instead, capture needed values in the closure's capture list.
296 
297Closures that may run off the main thread:
298- `Shape.path(in:)`
299- `visualEffect` closure
300- `Layout` protocol methods
301- `onGeometryChange` transform closure
302 
303```swift
304// BAD - accessing @MainActor state directly
305.visualEffect { content, geometry in
306    content.blur(radius: self.pulse ? 5 : 0)  // Compiler error: @MainActor isolated
307}
308 
309// GOOD - capture the value
310.visualEffect { [pulse] content, geometry in
311    content.blur(radius: pulse ? 5 : 0)
312}
313```
314 
315> Source: "Explore concurrency in SwiftUI" (WWDC25, session 266)
316 
317### 12. Common Performance Issues
318 
319**Be aware of common performance bottlenecks in SwiftUI:**
320 
321- View invalidation storms from broad state changes
322- Unstable identity in lists causing excessive diffing
323- Heavy work in `body` (formatting, sorting, image decoding)
324- Layout thrash from deep stacks or preference chains
325 
326**When performance issues arise**, suggest the user profile with Instruments (SwiftUI template) to identify specific bottlenecks.
327 
328## Anti-Patterns
329 
330### 1. Creating Objects in Body
331 
332```swift
333// BAD - creates new formatter every body call
334var body: some View {
335    let formatter = DateFormatter()
336    formatter.dateStyle = .long
337    return Text(formatter.string(from: date))
338}
339 
340// GOOD - static or stored formatter
341private static let dateFormatter: DateFormatter = {
342    let f = DateFormatter()
343    f.dateStyle = .long
344    return f
345}()
346 
347var body: some View {
348    Text(Self.dateFormatter.string(from: date))
349}
350```
351 
352### 2. Heavy Computation in Body
353 
354**Keep view body simple and pure.** Avoid side effects, dispatching, or complex logic.
355 
356```swift
357// BAD - sorts array every body call
358var body: some View {
359    List(items.sorted { $0.name < $1.name }) { item in Text(item.name) }
360}
361 
362// GOOD - compute once, update via onChange or a computed property in the model
363@State private var sortedItems: [Item] = []
364 
365var body: some View {
366    List(sortedItems) { item in Text(item.name) }
367        .onChange(of: items) { _, newItems in
368            sortedItems = newItems.sorted { $0.name < $1.name }
369        }
370}
371```
372 
373Move sorting, filtering, and formatting into models or computed properties. The `body` should be a pure structural representation of state.
374 
375### 3. Unnecessary State
376 
377```swift
378// BAD - derived state stored separately
379@State private var items: [Item] = []
380@State private var itemCount: Int = 0  // Unnecessary!
381 
382// GOOD - compute derived values
383@State private var items: [Item] = []
384 
385var itemCount: Int { items.count }  // Computed property
386```
387 
388## Summary Checklist
389 
390- [ ] State updates check for value changes before assigning
391- [ ] Hot paths minimize state updates
392- [ ] Pass only needed values to views (avoid large config objects)
393- [ ] Large lists use `LazyVStack`/`LazyHStack`
394- [ ] No object creation in `body`
395- [ ] Heavy computation moved out of `body`
396- [ ] Body kept simple and pure (no side effects)
397- [ ] Derived state computed, not stored
398- [ ] Use `Self._logChanges()` or `Self._printChanges()` to debug unexpected updates
399- [ ] Equatable conformance for expensive views (when appropriate)
400- [ ] Consider POD view wrappers for advanced optimization
401- [ ] Consider using granular @Observable dependencies for list items (smaller observable units per row when it measurably reduces updates)
402- [ ] Frequently-changing values not stored in the environment
403- [ ] Sendable closures (Shape, visualEffect, Layout) capture values instead of accessing @MainActor state
404