iOS Architect

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

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.