1# Understanding and Improving SwiftUI Performance (Summary)
2 
3Context: Apple guidance on diagnosing SwiftUI performance with Instruments and applying design patterns to reduce long or frequent updates.
4 
5## Core concepts
6 
7- SwiftUI is declarative; view updates are driven by state, environment, and observable data dependencies.
8- View bodies must compute quickly to meet frame deadlines; slow or frequent updates lead to hitches.
9- Instruments is the primary tool to find long-running updates and excessive update frequency.
10 
11## Instruments workflow
12 
131. Profile via Product > Profile.
142. Choose the SwiftUI template and record.
153. Exercise the target interaction.
164. Stop recording and inspect the SwiftUI track + Time Profiler.
17 
18## SwiftUI timeline lanes
19 
20- Update Groups: overview of time SwiftUI spends calculating updates.
21- Long View Body Updates: orange >500us, red >1000us.
22- Long Platform View Updates: AppKit/UIKit hosting in SwiftUI.
23- Other Long Updates: geometry/text/layout and other SwiftUI work.
24- Hitches: frame misses where UI wasn’t ready in time.
25 
26## Diagnose long view body updates
27 
28- Expand the SwiftUI track; inspect module-specific subtracks.
29- Set Inspection Range and correlate with Time Profiler.
30- Use call tree or flame graph to identify expensive frames.
31- Repeat the update to gather enough samples for analysis.
32- Filter to a specific update (Show Calls Made by `MySwiftUIView.body`).
33 
34## Diagnose frequent updates
35 
36- Use Update Groups to find long active groups without long updates.
37- Set inspection range on the group and analyze update counts.
38- Use Cause graph ("Show Causes") to see what triggers updates.
39- Compare causes with expected data flow; prioritize the highest-frequency causes.
40 
41## Remediation patterns
42 
43- Move expensive work out of `body` and cache results.
44- Use `Observable()` macro to scope dependencies to properties actually read.
45- Avoid broad dependencies that fan out updates to many views.
46- Reduce layout churn; isolate state-dependent subtrees from layout readers.
47- Avoid storing closures that capture parent state; precompute child views.
48- Gate frequent updates (e.g., geometry changes) by thresholds.
49 
50## Verification
51 
52- Re-record after changes to confirm reduced update counts and fewer hitches.
53