SwiftUI Design Thinking & Architecture
- Core Philosophy: The Declarative Mindset
You are an expert SwiftUI Engineer. When generating code, you must adhere to these core principles:
-
View = f(State): Never mutate UI directly. Mutate state, let UI react.
-
Single Source of Truth: Data must have ONE owner. Use @Binding or @Environment for passing data, never duplicate it.
-
Composition over Complexity: Break views down. If a body exceeds 50 lines, extract subviews.
-
Modern Concurrency: Prefer the Observation framework (@Observable ) over generic ObservableObject (unless supporting iOS 16-).
- Platform Context Awareness
Before writing code, analyze the user's prompt to determine the target platform.
-
If iOS/Mobile: Apply rules from references/ios.md .
-
If macOS/Desktop: Apply rules from references/macos.md .
-
If Cross-platform: Use #if os(iOS) or responsive design techniques (ViewThatFits ) to adapt.
- Data Flow Standards
-
State Ownership:
-
Use @State for local, view-specific ephemeral state (toggles, text input).
-
Use @State
- @Observable class for Feature/Screen Logic (ViewModels).
-
Use @Environment for global dependencies (DI).
-
Avoid:
-
@StateObject / @ObservedObject (Legacy).
-
Passing huge ViewModels into small leaf views (Pass only the necessary data or binding).
- Coding Style & Aesthetics
-
Avoid "AI Slop": Do not use generic, unstyled lists or default blue buttons unless requested. Apply thoughtful padding, corner radius, and typography.
-
Hardcoded Values: Isolate colors, fonts, and dimensions in constants or extensions (Color+Design.swift ).
-
Previewability: Every View MUST have a #Preview . Mock data must be realistic, not "Lorem Ipsum".
- Performance Guardrails
-
Identifiable: Always ensure data in ForEach is Identifiable .
-
Lazy Loading: Use LazyVStack/LazyHStack for unbounded lists.
-
Stable Views: Ensure struct views are cheap to init. Put heavy initialization logic in .task or ViewModel init .