Builds clean, performant, accessible SwiftUI views with correct state ownership, scoped invalidation, and smooth list scrolling, and reviews existing SwiftUI code against a concrete frame-time and re-render budget. Use when someone asks "why does my SwiftUI list stutter", "should this be @State or @Observable", "my whole screen re-renders when one row changes", "how do I animate this transition", or wants a SwiftUI view built or refactored. Do NOT use for cross-platform React Native apps - use react-native-pro instead; do NOT use for Flutter widget trees - use flutter-widget-architect instead; do NOT use for Android Compose UIs - use jetpack-compose-builder instead.
Click to play with sound.
---
name: SwiftUI Expert
description: Builds clean, performant, accessible SwiftUI views with correct state ownership, scoped invalidation, and smooth list scrolling, and reviews existing SwiftUI code against a concrete frame-time and re-render budget. Use when someone asks "why does my SwiftUI list stutter", "should this be @State or @Observable", "my whole screen re-renders when one row changes", "how do I animate this transition", or wants a SwiftUI view built or refactored. Do NOT use for cross-platform React Native apps - use react-native-pro instead; do NOT use for Flutter widget trees - use flutter-widget-architect instead; do NOT use for Android Compose UIs - use jetpack-compose-builder instead.
---
# SwiftUI Expert
A SwiftUI screen lives or dies on state ownership: put state in the wrong place and every keystroke re-evaluates the whole tree, lists stutter, and animations tear. This skill builds and reviews SwiftUI views so that invalidation stays scoped to the views that actually read changed data, the frame budget holds under scroll, and the result is accessible by default rather than retrofitted.
## Operating procedure
Work in this order because state design determines everything downstream - fixing state after the view hierarchy is built means rewriting the hierarchy.
### Step 1: Gather inputs
Collect before writing any view code. Where the user does not know, use the default and label it a guess.
- Target devices and refresh rate (default: assume ProMotion 120Hz iPhone plus a 60Hz baseline device).
- Data shape: how many items in the largest list, how often data mutates, whether it streams in.
- Ownership map: for each piece of state, which view creates it, which views read it, which mutate it.
- Accessibility requirements beyond baseline (default: full Dynamic Type + VoiceOver support).
### Step 2: Choose state ownership per value
Pick the narrowest wrapper that works:… load the full skill through Skill Me