ios-architect

iOS Architect

Keep token usage low by loading only the references needed for the current request.

Load Strategy

1. Always read references/​intake.md first.
2. Read only the references relevant to the build type:

New app from scratch

• references/​new-app-scaffold.md
• references/​feature-scaffold.md
• references/​database-and-migrations.md
• references/​design-system.md
• references/​testing-concurrency-di.md
• references/​privacy-and-compliance.md
• Optional: references/​networking.md — when the app has API-backed features
• Optional: references/​navigation.md — when deep linking or iPad/​multi-column is required
• Optional: references/​foundation-models.md — for on-device AI features
• Optional: references/​liquid-glass.md — when iOS 26+ Liquid Glass styling is requested

New feature

• references/​feature-scaffold.md
• If persistence changes: references/​database-and-migrations.md
• If custom UI components: references/​design-system.md
• If tests/​concurrency concerns: references/​testing-concurrency-di.md
• If API-backed: references/​networking.md
• If navigation/​deep linking changes: references/​navigation.md
• If on-device AI generation/​streaming: references/​foundation-models.md
• If Liquid Glass styling: references/​liquid-glass.md

New cross-domain shared service or model

• references/​testing-concurrency-di.md
• If DB-backed: references/​database-and-migrations.md
• If API-backed: references/​networking.md
• If Apple Foundation Models: references/​foundation-models.md

New design system component

• references/​design-system.md
• If Liquid Glass: references/​liquid-glass.md

New database migration

• references/​database-and-migrations.md

New local SPM package

• references/​new-app-scaffold.md
• references/​testing-concurrency-di.md

Do not bulk-load all references when the task is narrow.

Shared Placement Rule

• Default all model/​repository/​view-model ownership to the feature that uses it.
• Use Shared only for true cross-domain capabilities consumed by at least two domains/​features (e.g. Settings).
• Keep shared capabilities domain-scoped (Shared/​Settings/​...) with their own Domain/​Data/​Presentation split.
• Never create catch-all buckets such as Shared/​Models or Shared/​Data.

Execution Contract

1. Run intake first (build type, name, flow, fields, data source, integrations, test scope).
2. Generate complete, compile-ready files with concrete names.
3. Keep Clean Architecture boundaries strict:
   • Domain — models and protocols only
   • Data — repository implementations and records
   • Presentation — SwiftUI views, view models, feature UI components
   • Keep each layer in the owning feature by default; only promote to shared for proven cross-domain reuse.
4. Use modern APIs (@Observable, @MainActor, Swift Concurrency, Swift Testing). If AI is included, enforce runtime availability checks and deterministic fallback.
5. Validate generated output:
   • New Tuist app: tuist generate + one build
   • Feature/​module changes: targeted build/​tests
6. Report created files, validations run, and assumptions.