SwiftUI Performance Inspector
Diagnose from code first, then request profiling evidence when code review cannot explain the symptom.
Workflow
- Classify the symptom: slow rendering, scrolling jank, high CPU, memory growth, hangs, broad updates, or layout thrash.
- If code is available, review with
references/code-smells.md.
- If code is missing, ask for the smallest useful slice: target view, data flow, reproduction steps, device/simulator, build config, and deployment target.
- If runtime evidence is needed, use
references/profiling-intake.md for the exact Instruments checklist.
- Report likely causes, evidence, fixes, and validation steps using
references/report-template.md when useful.
Code Review Focus
- invalidation storms from broad observation or environment reads
- unstable identity in
List/ForEach
- heavy derived work in
body or view builders
- layout thrash from complex hierarchy,
GeometryReader, or preferences
- main-thread image decode/resize or other expensive work
- animation and transition work applied too broadly
Profiling Evidence
Ask for SwiftUI timeline or Time Profiler export/screenshots, device/OS/build configuration, exact profiled interaction, and before/after metrics when comparing changes.
Map evidence to invalidation, identity churn, layout, main-thread work, image cost, animation cost, or hangs. Distinguish trace-backed findings from code-level suspicion and state what evidence would reduce uncertainty.
Fix Defaults
- narrow state scope and observation fan-out
- stabilize list identities
- move heavy work out of
body into model/service precomputation, memoized helpers, background preprocessing, or input-driven derived state
- use
@State only for view-owned state, not arbitrary caches
- use
equatable() only when equality is cheaper than recomputing and inputs are value-semantic
- downsample images before rendering
- reduce layout complexity or add stable sizing where appropriate
Output
Provide a short metrics table when available, top issues ordered by impact, proposed fixes with effort, and verification steps.
References
references/profiling-intake.md
references/code-smells.md
references/report-template.md
references/optimizing-swiftui-performance-instruments.md
references/understanding-improving-swiftui-performance.md
references/understanding-hangs-in-your-app.md
references/demystify-swiftui-performance-wwdc23.md
Use current Apple Developer docs when Instruments or SwiftUI performance guidance may have changed.
1---2name: swiftui-performance-inspector3description: Diagnose SwiftUI rendering and update costs from code or profiles when scrolling janks, CPU or memory spikes, views update excessively, layouts thrash, or apps hang.4---56# SwiftUI Performance Inspector78Diagnose from code first, then request profiling evidence when code review cannot explain the symptom.910## Workflow11121. Classify the symptom: slow rendering, scrolling jank, high CPU, memory growth, hangs, broad updates, or layout thrash.132. If code is available, review with `references/code-smells.md`.143. If code is missing, ask for the smallest useful slice: target view, data flow, reproduction steps, device/simulator, build config, and deployment target.154. If runtime evidence is needed, use `references/profiling-intake.md` for the exact Instruments checklist.165. Report likely causes, evidence, fixes, and validation steps using `references/report-template.md` when useful.1718## Code Review Focus1920- invalidation storms from broad observation or environment reads21- unstable identity in `List`/`ForEach`22- heavy derived work in `body` or view builders23- layout thrash from complex hierarchy, `GeometryReader`, or preferences24- main-thread image decode/resize or other expensive work25- animation and transition work applied too broadly2627## Profiling Evidence2829Ask for SwiftUI timeline or Time Profiler export/screenshots, device/OS/build configuration, exact profiled interaction, and before/after metrics when comparing changes.3031Map evidence to invalidation, identity churn, layout, main-thread work, image cost, animation cost, or hangs. Distinguish trace-backed findings from code-level suspicion and state what evidence would reduce uncertainty.3233## Fix Defaults3435- narrow state scope and observation fan-out36- stabilize list identities37- move heavy work out of `body` into model/service precomputation, memoized helpers, background preprocessing, or input-driven derived state38- use `@State` only for view-owned state, not arbitrary caches39- use `equatable()` only when equality is cheaper than recomputing and inputs are value-semantic40- downsample images before rendering41- reduce layout complexity or add stable sizing where appropriate4243## Output4445Provide a short metrics table when available, top issues ordered by impact, proposed fixes with effort, and verification steps.4647## References4849- `references/profiling-intake.md`50- `references/code-smells.md`51- `references/report-template.md`52- `references/optimizing-swiftui-performance-instruments.md`53- `references/understanding-improving-swiftui-performance.md`54- `references/understanding-hangs-in-your-app.md`55- `references/demystify-swiftui-performance-wwdc23.md`5657Use current Apple Developer docs when Instruments or SwiftUI performance guidance may have changed.