Swift architecture and data flow
Read docs/ARCHITECTURE.md, then references/state-and-dependencies.md. Use this skill before introducing a model, service, store, persistence mechanism, cache, or app-wide state.
Workflow
- Write the behaviour and invariants without UI terminology.
- Decide whether it is a value, pure operation, external capability, or mutable application state.
- Put values/pure operations in
Domain.
- Define external needs as narrow
Sendable protocols in Infrastructure.
- Implement dependencies separately and construct them at the app boundary.
- Keep view-facing shared state in a main-actor-isolated
@Observable type; rely on the package default rather than repeating @MainActor.
- Own that model once with
@State; pass via @Environment or explicit parameters; expose editable projections through @Bindable/@Binding.
- Model asynchronous UI state explicitly and test each transition.
- Document persistence, migration, sync, conflict, deletion, privacy, and backup semantics before selecting storage.
Guardrails
- No global service locator, mutable singleton, or hidden dependency lookup.
- No networking, persistence, keychain, or business rules in a view.
- No
@AppStorage inside an @Observable model and no secrets in @AppStorage anywhere.
- No cached derived collection without clear invalidation.
- No third-party architecture framework merely to avoid writing small explicit types.
- Do not create a view model per view by reflex; add state coordination only when behaviour needs an owner or test seam.
Review output
Draw the ownership and dependency flow, identify competing sources of truth and stale snapshots, then propose the smallest boundary correction. Include migration implications when storage changes.
1---2name: swift-architecture3description: Design or review feature boundaries, Observation state ownership, dependency injection, persistence seams, caching, and data flow in this SwiftUI template.4license: MIT5---67# Swift architecture and data flow89Read `docs/ARCHITECTURE.md`, then `references/state-and-dependencies.md`. Use this skill before introducing a model, service, store, persistence mechanism, cache, or app-wide state.1011## Workflow12131. Write the behaviour and invariants without UI terminology.142. Decide whether it is a value, pure operation, external capability, or mutable application state.153. Put values/pure operations in `Domain`.164. Define external needs as narrow `Sendable` protocols in `Infrastructure`.175. Implement dependencies separately and construct them at the app boundary.186. Keep view-facing shared state in a main-actor-isolated `@Observable` type; rely on the package default rather than repeating `@MainActor`.197. Own that model once with `@State`; pass via `@Environment` or explicit parameters; expose editable projections through `@Bindable`/`@Binding`.208. Model asynchronous UI state explicitly and test each transition.219. Document persistence, migration, sync, conflict, deletion, privacy, and backup semantics before selecting storage.2223## Guardrails2425- No global service locator, mutable singleton, or hidden dependency lookup.26- No networking, persistence, keychain, or business rules in a view.27- No `@AppStorage` inside an `@Observable` model and no secrets in `@AppStorage` anywhere.28- No cached derived collection without clear invalidation.29- No third-party architecture framework merely to avoid writing small explicit types.30- Do not create a view model per view by reflex; add state coordination only when behaviour needs an owner or test seam.3132## Review output3334Draw the ownership and dependency flow, identify competing sources of truth and stale snapshots, then propose the smallest boundary correction. Include migration implications when storage changes.
rcarmo