| name | ios-performance-debugging |
| description | Diagnose SwiftUI rendering, launch, responsiveness, concurrency, memory, energy, and simulator failures using reproducible traces and before-after evidence. |
iOS Performance Debugging
Workflow
- Define one reproducible user flow and one metric before changing code.
- Capture device, OS, build configuration, commit, data fixture, and baseline trace.
- Use the narrowest instrument: SwiftUI updates and hitches, Time Profiler, Allocations/Leaks, Network, Energy, or concurrency analysis.
- Correlate the trace to source. Do not optimize from intuition alone.
- Change one ownership, identity, layout, allocation, or scheduling cause at a time.
- Repeat the same flow and compare the same metric.
- Keep the trace, command, and before-after result in the handoff.
SwiftUI checks
- Stable identity in collections.
- Observation scoped to data the view actually reads.
- No expensive formatting, filtering, I/O, or object creation in
body.
- Lazy containers used only where they fit the layout.
- Image decoding and resizing moved off the render-critical path.
- Navigation and sheet state represented by one source of truth.
Read references/trace-receipt.md before claiming a performance improvement.
