SwiftUI Performance Inspector
SkillDocs & knowledgeDiagnose SwiftUI rendering and update costs from code or profiles when scrolling janks, CPU or memory spikes, views update excessively, layouts thrash, or apps hang.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the SwiftUI Performance Inspector skill
What this skill tells your AI
The instructions your AI receives, as published by xopoko/build-swift-apps in skills/swiftui-performance-inspector/SKILL.md and read by ahel’s review.
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.mdfor the exact Instruments checklist. - Report likely causes, evidence, fixes, and validation steps using
references/report-template.mdwhen useful.
Code Review Focus
- invalidation storms from broad observation or environment reads
- unstable identity in
List/ForEach - heavy derived work in
bodyor 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
bodyinto model/service precomputation, memoized helpers, background preprocessing, or input-driven derived state - use
@Stateonly 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.mdreferences/code-smells.mdreferences/report-template.mdreferences/optimizing-swiftui-performance-instruments.mdreferences/understanding-improving-swiftui-performance.mdreferences/understanding-hangs-in-your-app.mdreferences/demystify-swiftui-performance-wwdc23.md
Use current Apple Developer docs when Instruments or SwiftUI performance guidance may have changed.
Signals
- GitHub stars
- 45
- Forks
- 4
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
swiftui-performance-inspector- Source
- github.com/xopoko/build-swift-apps