ios-architecture

Architecture and persistence

Inspect existing boundaries, dependencies, OS support and data requirements. Add layers only for a concrete need; verify version-sensitive behavior in the installed SDK or primary framework documentation. For offline data, cache, pagination, retries or sync conflicts, read data/network policy. Language mechanics belong to Swift; OS-managed background delivery to platform integration, and credential trust to security.

• Choose MVVM, TCA, Clean Architecture or a simpler design from the actual state, testability and team constraints. Do not add repositories or protocols by quota. Use the project's installed TCA version when touching reducers or dependencies.
• Make dependencies explicit at boundaries. Preserve useful error states and cancellation rather than converting failures to empty collections with try?.
• Choose SwiftData or Core Data from deployment, existing stores, migration and sync needs; do not automatically replace a working persistent store.
• Confine ModelContext and mutable models to their intended isolation domain. Use @ModelActor where appropriate for actor-owned persistence. Do not inject an arbitrary context into an unrelated actor or transfer live mutable models across isolation boundaries; use identifiers or Sendable snapshots when needed.
• Verify relationship inverses and delete direction. A cascade on a child-to-parent relationship can delete the parent. For CloudKit, verify schema compatibility, relationship optionality, defaults, and uniqueness restrictions against the SDK.
• For schema changes, preserve user data and test upgrade paths using representative old stores. An in-memory empty store does not validate migration or synchronization.

Work directly without recursive delegation. Validate affected builds and persistence; report tradeoffs, results and checks requiring device or iCloud access.