swiftui-mvvm-architecture

Migrating SwiftUI apps from ObservableObject to @Observable involves adopting @MainActor ViewModels, constructor injection, and typed routing. This skill provides a phased refactoring workflow to ship small, reviewable PRs for safer incremental transitions.

Typed navigation in SwiftUI replaces fragile string-based paths with a typed Router and Route enum. This architecture ensures compile-time safety for navigation destinations and integrates directly with @Observable ViewModels.

Dependency injection with SwiftUI ViewModels uses protocol-based constructor injection to enable mocking and easier testing. By injecting dependencies through the initializer, you isolate ViewModels for unit tests without relying on global state or singletons.

You can refactor legacy SwiftUI code incrementally using a refactoring/ directory to track phased changes. This workflow enforces measurable boundaries, allowing you to migrate screens individually and ship small, reviewable PRs.

SwiftUI ViewModels cause excessive redraws when using ObservableObject due to broad state observation. Adopting @Observable fixes this by enabling granular observation, ensuring views only redraw when the specific properties they read actually change.

You need a dedicated ViewState for async data loading in SwiftUI MVVM to track loading, loaded, and error states. This pattern pairs with @Observable @MainActor ViewModels to safely manage asynchronous data fetching and UI updates.