1---
2name: swiftui-performance-audit
3description: Audit and improve SwiftUI runtime performance from code review and architecture. Use for requests to diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash in SwiftUI apps, and to provide guidance for user-run Instruments profiling when code review alone is insufficient.
4---
5 
6# SwiftUI Performance Audit
7 
8## Quick start
9 
10Use this skill to diagnose SwiftUI performance issues from code first, then request profiling evidence when code review alone cannot explain the symptoms.
11 
12## Workflow
13 
141. Classify the symptom: slow rendering, janky scrolling, high CPU, memory growth, hangs, or excessive view updates.
152. If code is available, start with a code-first review using `references/code-smells.md`.
163. If code is not available, ask for the smallest useful slice: target view, data flow, reproduction steps, and deployment target.
174. If code review is inconclusive or runtime evidence is required, guide the user through profiling with `references/profiling-intake.md`.
185. Summarize likely causes, evidence, remediation, and validation steps using `references/report-template.md`.
19 
20## 1. Intake
21 
22Collect:
23- Target view or feature code.
24- Symptoms and exact reproduction steps.
25- Data flow: `@State`, `@Binding`, environment dependencies, and observable models.
26- Whether the issue shows up on device or simulator, and whether it was observed in Debug or Release.
27 
28Ask the user to classify the issue if possible:
29- CPU spike or battery drain
30- Janky scrolling or dropped frames
31- High memory or image pressure
32- Hangs or unresponsive interactions
33- Excessive or unexpectedly broad view updates
34 
35For the full profiling intake checklist, read `references/profiling-intake.md`.
36 
37## 2. Code-First Review
38 
39Focus on:
40- Invalidation storms from broad observation or environment reads.
41- Unstable identity in lists and `ForEach`.
42- Heavy derived work in `body` or view builders.
43- Layout thrash from complex hierarchies, `GeometryReader`, or preference chains.
44- Large image decode or resize work on the main thread.
45- Animation or transition work applied too broadly.
46 
47Use `references/code-smells.md` for the detailed smell catalog and fix guidance.
48 
49Provide:
50- Likely root causes with code references.
51- Suggested fixes and refactors.
52- If needed, a minimal repro or instrumentation suggestion.
53 
54## 3. Guide the User to Profile
55 
56If code review does not explain the issue, ask for runtime evidence:
57- A trace export or screenshots of the SwiftUI timeline and Time Profiler call tree.
58- Device/OS/build configuration.
59- The exact interaction being profiled.
60- Before/after metrics if the user is comparing a change.
61 
62Use `references/profiling-intake.md` for the exact checklist and collection steps.
63 
64## 4. Analyze and Diagnose
65 
66- Map the evidence to the most likely category: invalidation, identity churn, layout thrash, main-thread work, image cost, or animation cost.
67- Prioritize problems by impact, not by how easy they are to explain.
68- Distinguish code-level suspicion from trace-backed evidence.
69- Call out when profiling is still insufficient and what additional evidence would reduce uncertainty.
70 
71## 5. Remediate
72 
73Apply targeted fixes:
74- Narrow state scope and reduce broad observation fan-out.
75- Stabilize identities for `ForEach` and lists.
76- Move heavy work out of `body` into derived state updated from inputs, model-layer precomputation, memoized helpers, or background preprocessing. Use `@State` only for view-owned state, not as an ad hoc cache for arbitrary computation.
77- Use `equatable()` only when equality is cheaper than recomputing the subtree and the inputs are truly value-semantic.
78- Downsample images before rendering.
79- Reduce layout complexity or use fixed sizing where possible.
80 
81Use `references/code-smells.md` for examples, Observation-specific fan-out guidance, and remediation patterns.
82 
83## 6. Verify
84 
85Ask the user to re-run the same capture and compare with baseline metrics.
86Summarize the delta (CPU, frame drops, memory peak) if provided.
87 
88## Outputs
89 
90Provide:
91- A short metrics table (before/after if available).
92- Top issues (ordered by impact).
93- Proposed fixes with estimated effort.
94 
95Use `references/report-template.md` when formatting the final audit.
96 
97## References
98 
99- Profiling intake and collection checklist: `references/profiling-intake.md`
100- Common code smells and remediation patterns: `references/code-smells.md`
101- Audit output template: `references/report-template.md`
102- Add Apple documentation and WWDC resources under `references/` as they are supplied by the user.
103- Optimizing SwiftUI performance with Instruments: `references/optimizing-swiftui-performance-instruments.md`
104- Understanding and improving SwiftUI performance: `references/understanding-improving-swiftui-performance.md`
105- Understanding hangs in your app: `references/understanding-hangs-in-your-app.md`
106- Demystify SwiftUI performance (WWDC23): `references/demystify-swiftui-performance-wwdc23.md`
107