swiftui-performance-audit

Janky scrolling usually comes from unstable identity or heavy work in `body`. Use stable domain identifiers instead of `id: \.self`, pre-filter and pre-sort collections before rendering, and move formatting or image decoding off the main thread.

Profile a Release build on a real device using the SwiftUI Instruments template, which combines the SwiftUI timeline with Time Profiler. Inspect Long View Body Updates, correlate with the Time Profiler call tree, and use the Cause and Effect Graph to find what triggers updates.

Excessive updates typically come from broad observation, such as many views reading a shared `@Observable` collection or environment value. Narrow the observable surface, scope state closer to leaf views, and use `Self._printChanges()` in debug builds to inspect dependencies.

Use `equatable()` only when the equality check is cheaper than recomputing the subtree and the view inputs are value-semantic and stable. It is not a blanket fix for redraws and can add overhead if equality checks are expensive.

Many issues can be found through code review alone, such as formatters created in `body`, inline filtering in `ForEach`, and main-thread image decoding. Profiling is requested only when code review cannot explain the symptom or runtime evidence is needed.

Debug builds distort SwiftUI timing and allocation behavior, and the Simulator can miss device-only rendering and memory issues. Always capture traces in Release configuration on a physical device for reliable measurements.