swiftui-performance-audit
SwiftUI Performance Audit
Overview
SwiftUI is slow in two ways. Either one update takes too long (a body, a layout pass or an image decode that does not fit in a frame), or there are too many updates (views recomputed because something they depend on changed, although nothing they show did). Both end as work on the main thread, and the person sees a frozen control or stuttering motion. An audit names which of the two is happening, on which view, caused by which dependency or call, and proves the fix with the same measurement taken before and after. Guessing from code alone is allowed as a first pass, but it must be labelled as a hypothesis until a trace confirms it.
Instructions
1. Name the symptom and the conditions
Ask for, or find in the report: the exact interaction (for example "typing in the search field on Orders"), device model and OS version, build configuration, how much data is on screen, and whether it was always slow or regressed.
| What the person sees | Term | Numbers to hold on to | First tool |
|---|---|---|---|
| A tap, keystroke or screen opening responds late | Hang: the main run loop is busy | Under 100 ms is rarely noticed; Apple's tools start reporting at 250 ms | Hangs instrument with Time Profiler |
| Scrolling or animation stutters | Hitch: a frame arrived late | A frame has 16.7 ms at 60 Hz and 8.3 ms at 120 Hz. Organizer hitch rate: up to 10 ms/s good, up to 25 warning, up to 50 critical | Hitches instrument, SwiftUI instrument |
| CPU busy or battery drain while nothing seems to change | Excess updates | Count of body updates per interaction | SwiftUI instrument, Update Groups lane |
| Memory climbs while scrolling | Usually full-size images | Peak memory before and after | Allocations template |