← ClaudeAtlas

ios-swiftui-architectlisted

Build or refactor iOS SwiftUI views/components: navigation, TabView, sheets, async state, responsive stacks/grids, state ownership, environment injection, previews, and performance-aware declarative UI.
Xopoko/plug-n-skills · ★ 3 · Web & Frontend · score 76
Install: claude install-skill Xopoko/plug-n-skills
# iOS SwiftUI Architect Use for iOS SwiftUI UI structure and component choices. Read the nearest local example before introducing a new pattern. ## Start - Existing project: identify screen model (list/detail/editor/settings/tab), search for nearby examples (`rg "TabView\\("`, etc.), then read `references/components-index.md`. - New app: start with `references/app-wiring.md` for TabView + NavigationStack + sheets, then expand route/sheet enums as screens appear. - For scroll-driven reveals, read `references/scroll-reveal.md` before hand-rolling gestures. ## Rules - Prefer `@State`, `@Binding`, `@Observable`, and `@Environment`; avoid unnecessary view models. - If iOS 16 or earlier is supported, use `ObservableObject` with `@StateObject` at the owner and `@ObservedObject` for injection. - Keep views small, composed, and project-formatted. - Use `.task`/`.task(id:)` with loading/error states; read `references/async-state.md` for cancellation/debouncing. - Put shared app services in `@Environment`; keep feature-local dependencies as explicit inputs. - Prefer newest SwiftUI APIs that match deployment target and call out minimum OS. - Maintain legacy patterns only inside legacy files. - Sheets: prefer `.sheet(item:)`, avoid `if let` inside sheet bodies, let sheets call `dismiss()` internally. - Scroll reveals: derive one normalized progress value from scroll offset instead of parallel gesture state machines when possible. ## State Ownership | Scenario | Pattern | | --- | --