swiftui-component-audit-workflow

SwiftUI Component Audit Workflow

Purpose

Audit or repair a SwiftUI feature without importing AppKit, UIKit, or generic imperative architecture into a declarative view tree. SwiftUI components stand on their own: they render from explicit values and framework state, own local presentation state, and express user intent through narrow actions. A feature service, when needed, is a direct concrete owner of one capability rather than a wrapper stack.

SwiftData And SwiftUI Rule

Keep SwiftData directly integrated with SwiftUI through modelContainer, environment modelContext, @Query, model objects, and narrow bindings. Do not insert repositories, stores, service mirrors, DTO mirrors, ViewModel caches, or other abstraction layers between SwiftData and SwiftUI. Hand persistence-specific decisions to swiftdata-workflow.

When To Use

• Use for a SwiftUI architecture review, component audit, repair, or refactor.
• Use when reusable views receive ViewModels, stores, services, managers, coordinators, or other collaborating objects.
• Use when state is duplicated, a router or coordinator shadows SwiftUI navigation, or an environment becomes a dependency dump.
• Use when a team needs concrete good/bad SwiftUI examples before implementing a feature.
• Hand SwiftData persistence decisions to swiftdata-workflow, app and scene ownership to swiftui-app-architecture-workflow, and execution to the Xcode build or testing workflows.

Single-Path Workflow

1. Read the relevant Apple documentation through explore-apple-swift-docs before proposing a repair.
2. Inventory each view's stored properties, local state, environment reads, preferences, focus, commands, and outward actions.
3. Classify every dependency:
   • component input: value, narrow binding, or action closure
   • component-local state: @State, derived value, or locally owned @Observable state
   • hierarchy context: existing or custom environment value/action
   • upward layout or presentation fact: preference key
   • active command context: focus or focused value
   • direct persistence state: ModelContainer, modelContext, @Query, model object, or narrow binding
   • non-SwiftUI boundary: networking, import/export, migration, testing, or server sync
   • direct concrete feature service: one capability or cohesive related group with a named app or scene lifecycle owner
4. Report a finding for every reusable view that accepts an external ViewModel, store, coordinator, manager, service, or observable collaborator.
5. Report a finding for every umbrella app service, forwarding service facade, repository/protocol/adapter chain, or service that has no direct capability boundary.
6. Repair from the narrowest honest mechanism outward:
   • replace collaborators with values, bindings, and actions
   • move local presentation state into the owning view
   • use an existing environment action before adding a custom action
   • add a custom environment value or action only for a dynamic or broadly reused hierarchy capability
   • use preferences only for descendant-to-ancestor publication
   • restore direct SwiftData integration when persistence is being mirrored
   • collapse forwarding layers into the concrete feature service that owns the real capability
   • install that service in environment only when independent descendants need direct invocation or observation
7. Remove explicit initializers that only duplicate the synthesized memberwise initializer.
8. Re-audit the changed component boundaries and hand off for build, preview, or tests.