swiftui-performance-developer

Slow SwiftUI List scrolling usually comes from unstable identity, variable view counts per row, or heavy work in body. Use stable IDs like `id: \.id` instead of `\.self`, pre-filter collections instead of inline filtering, and avoid AnyView in rows.

Profile via Product > Profile using the SwiftUI template in Release mode, reproduce the slow interaction, then inspect Long View Body Updates (orange over 500us, red over 1000us) and the Hitches lane. Correlate long updates with Time Profiler to find expensive frames.

Excessive re-rendering happens when views depend on broad state that changes frequently. Use `Self._printChanges()` in debug builds to see which dependencies trigger updates, then narrow state scope with @Observable or extract subviews that read only the data they need.

No, splitting SwiftUI views into subviews does not hurt performance because views are lightweight value types describing UI state. SwiftUI only re-evaluates subviews whose dependencies actually changed, so decomposition often improves update granularity.

Layout thrash commonly comes from GeometryReader placed deep in the view tree, fast-changing environment values, or state that forces repeated layout passes. Move geometry reads higher in the hierarchy, use fixed sizing where possible, and gate frequent updates behind thresholds.