swiftui-performance-audit

Audits interface rendering performance starting from code, looking for invalidation storms, unstable list identity, heavy work inside view bodies and layout thrash. When static inspection is not decisive the skill stops guessing and hands the user a procedure for collecting a trace on a release build, then asks for the call tree and timeline screenshots before concluding. That division of labour is the honest part, since no profiling happens automatically and the analysis is only as good as the diagnostics supplied. Symptom-only reports are asked for minimal reproducing code first. Oversized images that skip downsampling are flagged as a common cheap win.

Use case: Diagnosing janky scrolling in a SwiftUI screen

This skill diagnoses slow rendering and jank in a ui framework by reading the code first and only moving to a profiler when the review is inconclusive. The workflow is a decision tree: code first review, then guided profiling, then concrete remediation. ## What it does - Looks for view invalidation storms caused by broad state changes. - Flags unstable list identity, such as identifiers regenerated on every render. - Finds heavy work inside the view body, including formatting, sorting and image decoding. - Checks for layout thrash from deep stacks and geometry readers. - Catches large images that are not downsampled and hierarchies with implicit animation everywhere. - Guides a profiler session when the code review does not explain the symptom. ## When it is the wrong choice It reasons about code and described symptoms, so a performance problem that only appears under real data or on a specific device can stay hidden. The profiler path needs a release build, a reproduced interaction and an exported trace, which is real work and cannot be done for you. The findings are ranked by likelihood rather than measured, so two plausible causes may need to be fixed one at a time to find the culprit. And it is a diagnosis tool: applying every suggestion at once makes it impossible to tell which change actually helped. ```json { "focus": [ "invalidation storms from broad state changes", "unstable list identity", "heavy work inside the view body", "layout thrash", "large images without downsampling" ], "next_step": "profile a release build and export the trace" } ``` ## Working notes - Profiling uses a release build and the framework specific template. - A trace or screenshots of the relevant lanes are what the review needs. - Symptoms and reproduction steps are collected before any diagnosis.