119 lines
5.2 KiB
Markdown
119 lines
5.2 KiB
Markdown
---
|
|
name: swiftui-performance-audit
|
|
description: Audit SwiftUI performance issues from code review and profiling evidence.
|
|
risk: safe
|
|
source: "Dimillian/Skills (MIT)"
|
|
date_added: "2026-03-25"
|
|
---
|
|
|
|
# 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.
|
|
|
|
## When to Use
|
|
- When the user reports slow rendering, janky scrolling, layout thrash, or high CPU in SwiftUI.
|
|
- When you need a code-first audit plus Instruments guidance if profiling evidence is required.
|
|
|
|
## Workflow
|
|
|
|
1. Classify the symptom: slow rendering, janky scrolling, high CPU, memory growth, hangs, or excessive view updates.
|
|
2. If code is available, start with a code-first review using `references/code-smells.md`.
|
|
3. If code is not available, ask for the smallest useful slice: target view, data flow, reproduction steps, and deployment target.
|
|
4. If code review is inconclusive or runtime evidence is required, guide the user through profiling with `references/profiling-intake.md`.
|
|
5. 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`
|
|
|
|
## Limitations
|
|
- Use this skill only when the task clearly matches the scope described above.
|
|
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
|
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|