swiftui-patterns

# SwiftUI Patterns ## Overview Native iOS (SwiftUI) is chosen when a task needs deep Apple-platform integration or the app is already native (see native-vs-flutter-decision). Same discipline as Flutter: small composed views, state out of the view, reusable atomic components. **Core principle:** Views are a function of state. Data and business logic live in an observable model, not in the `View`. ## Rules - **Small views, composed.** Extract subviews as their own `View` types (not `@ViewBuilder` funcs) so each has its own body and preview. - **State ownership is explicit:** `@State` for local ephemeral UI only; app/business state in an `@Observable` model (or `ObservableObject`) injected via `@Environment`/init. Views send intents to the model; the model owns the logic and the networking. - **Atomic components:** a shared component library (atoms → molecules → organisms) of reusable views. Reuse before building; grep before adding. - **System styling over hardcoded values:** colors from the asset catalog / `Color` semantic roles, spacing/typography from a tokens file — not scattered magic numbers. Support Dynamic Type and dark mode. - **`#Preview`** every reusable view in its key states (loading/data/error) — previews are your fast feedback loop. - **Value types** (`struct`) for models and view state; reference types only where identity is needed. ## Worked Example ```swift @Observable final class TaskListModel { // owns state + logic, testable private(set)...