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