MVVM in SwiftUI: Using view models without overengineering
Article Summary
Antoine van der Lee tackles the most common SwiftUI mistake: slapping a view model on everything. His approach? Start simple, add MVVM only when it actually solves a problem.
This practical guide from SwiftLee shows how to use MVVM in SwiftUI without falling into the overengineering trap. Van der Lee walks through when view models add value versus when they just create unnecessary abstraction, using a real contact deletion workflow as an example.
Key Takeaways
- Use @Observable and @MainActor for modern SwiftUI view models
- Add view models only for async workflows, validation, or testable logic
- Keep business logic in repositories, not bloated view models
- Simple views displaying data don't need view models at all
- Name methods after user actions, not implementation details
MVVM in SwiftUI works best when you start without it and add view models only when they improve testability, readability, or state management.
About This Article
SwiftUI developers often can't tell when MVVM actually helps versus when it just adds complexity. The result is bloated codebases where view model layers mostly duplicate what's already in the model.
Antoine van der Lee suggests a practical test: only add a view model if your view needs to handle async work, transform data, validate input, contain logic worth testing, or talk to multiple services. Use @Observable and @MainActor for the implementation.
This cuts down on unnecessary abstraction while keeping tests intact. Simple views stay simple. Complex screens get the separation they need without making the code harder to navigate or read.