Expand SwiftUI performance guidance

[jg-oai]

Summary

• expands the swiftui-performance-audit skill with a deeper review guide for diagnosing SwiftUI performance issues
• adds concrete code-smell guidance for identity, observation, layout/preference-chain feedback loops, async work, scoped animation, and collection rendering issues
• adds guardrails for @State as view-owned state rather than an ad hoc cache
• clarifies that lazy-container row-lifetime @State belongs on the stable root view returned from ForEach, because nested child state can be recreated after offscreen content is rebuilt
• adds Swift 6.2-aware lifecycle guidance that .task and async do not automatically move CPU-heavy synchronous work off the main actor, with @concurrent as the explicit opt-in when an async helper must hop off the caller's actor
• refines lazy-stack guidance so lazy containers are recommended for large repeated content when profiling supports the tradeoff, while standard stacks remain preferred for small/simple content
• links related SwiftUI UI/refactor skills back to the performance audit so performance-sensitive SwiftUI work routes to the right guidance

Why

SwiftUI performance problems often come from small architectural choices that are hard to spot in isolated code snippets: unstable identity, broad observation, expensive view-body work, layout feedback loops, or async work attached to frequently recreated views. This update gives Codex more specific guidance for reviewing and improving those patterns in iOS apps.

The goal is to make the Build iOS Apps plugin more useful when developers ask Codex to audit janky scrolling, excessive re-rendering, slow layout, or performance-sensitive SwiftUI refactors.

References

• Identity, lifetime, dependencies, stable list/table identity, and constant row shape are grounded in Apple's Demystify SwiftUI and Demystify SwiftUI performance. Apple describes identity as "how SwiftUI recognizes elements as the same or distinct" and says to "recommend avoiding AnyViews whenever possible."
• Lazy-container ForEach row-state guidance is grounded in SwiftUI's ForEach, LazyVStack, and State documentation. Apple describes ForEach as a structure that "computes views on demand," says lazy stacks create items only when needed, and notes that the "life cycle of state variables mirrors the view life cycle." The root-vs-nested state placement rule is review guidance derived from those lifecycle and lazy-creation semantics.
• Lazy-stack selection and device-profiling guidance is grounded in Apple's Creating performant scrollable stacks. Apple says to "only switch to a lazy stack if profiling your code shows a worthwhile performance improvement" and "Never profile your code using the iOS simulator."
• Observation guidance for @Observable, @State, @Bindable, @Environment, and @ObservationIgnored is grounded in Apple's Migrating from the Observable Object protocol to the Observable macro and Discover Observation in SwiftUI. Apple describes Observation updates around "observable properties that a view's body reads."
• Fast body evaluation, lifecycle-modifier work, layout-reader scope, stored builder closures, frequent updates, and cause-and-effect graph guidance are grounded in Apple's Understanding and improving SwiftUI performance. Apple explicitly says "Keep your view bodies fast," "avoid performing complex, long-running tasks," and "Avoid storing closures in views."
• .task executor guidance is grounded in the Swift 6.2 release notes, which explain caller-context async execution and describe @concurrent as the way to "introduce code that runs concurrently."
• Instruments lanes and profiling workflow guidance are grounded in Understanding and improving SwiftUI performance and Optimize SwiftUI performance with Instruments. Apple describes Update Groups as the lane that "shows when SwiftUI is doing work."
• Scoped animation guidance is grounded in SwiftUI's animation(_:body:) API documentation, which says the animation is "only used on the modifiers defined in the body."
• Preference-chain feedback-loop guidance extends Apple's geometry/environment guidance: Understanding and improving SwiftUI performance recommends thresholding onGeometryChange, and Optimize SwiftUI performance with Instruments warns about fast-changing "geometry values or timers" in the environment. The specific PreferenceKey / anchorPreference framing is a review heuristic derived from that model.
• Manual binding risk applies Apple's stored-closure guidance to Binding(get:set:), because manual bindings store getter/setter closures. Action-capture narrowing and .equatable() triage are review heuristics derived from SwiftUI's identity/dependency/update model and should be treated as guidance, not direct Apple rules.

Validation

• git diff --check origin/main...HEAD