swiftui

SwiftUI Implementation Patterns

Use this skill to keep SwiftUI changes composable, state-safe, and aligned with iOS 17+, MVVM, the new Observation APIs, and Factory for dependency injection.

Delivery Workflow

Use the checklist below and track progress:

SwiftUI progress:
- [ ] Step 1: Discover project conventions and navigation model
- [ ] Step 2: Map screen state, ViewModel ownership, and Factory dependencies
- [ ] Step 3: Compose views into small reusable units
- [ ] Step 4: Wire Observation-based bindings and async work safely
- [ ] Step 5: Verify accessibility, previews, and tests

Platform Assumptions

• Target iOS 17+ by default.
• Prefer the modern Observation model over legacy ObservableObject patterns unless the project still depends on older code paths.
• Do not add compatibility fallbacks for pre-iOS 17 APIs unless the repository explicitly requires them.
• Apple's swiftui-specialist guidance supersedes model memory on framework behavior; when it conflicts with this skill on framework-level correctness (identity, invalidation, environment, deprecations), follow it and keep this skill for project conventions (MVVM, Factory).
• On SDK 27+, @State is a macro: an @State build error after an SDK update is not fixed by reordering init assignments — see swiftui-whats-new-27.
• Use NavigationStack/NavigationSplitView, not the soft-deprecated NavigationView, and the two-parameter/zero-parameter onChange.

State Management Rules

• Keep View types focused on presentation and lightweight interaction wiring.
• Prefer one clear source of truth for screen state.
• Treat the ViewModel as the owner of screen business state in MVVM flows.
• Use the project's existing observation model first; do not mix competing patterns without a reason.
• Keep transient UI state local to the view and move shared/business state into an observable ViewModel.
• Derive display values from state instead of duplicating them.

Property Wrapper Guidance