The MVVM Pattern
Separate view, view model, and model concerns.
The MVVM Pattern is a free Swift Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Swift Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What Is MVVM?
MVVM stands for Model-View-ViewModel. It is an architectural pattern that separates your app into three layers, each with a single clear responsibility.
- Model — data and business rules
- View — what the user sees
- ViewModel — the bridge that prepares Model data for the View
The goal is separation of concerns: each layer changes for its own reason, independently of the others.
The Model Layer
The Model holds your raw data and the rules that govern it. It knows nothing about the screen or how things are displayed.
Models are usually plain structs or domain objects. They are easy to test because they have no UI dependencies.
struct User {
let id: UUID
let firstName: String
let lastName: String
let isPremium: Bool
}
struct Order {
let items: [String]
let total: Decimal
}The View Layer
The View is purely presentational. In SwiftUI it is your View structs; in UIKit it is your UIViewController and its subviews.
A good View contains no business logic. It only renders state and forwards user actions to the ViewModel.
struct ProfileView: View {
@StateObject var viewModel: ProfileViewModel
var body: some View {
VStack {
Text(viewModel.displayName)
if viewModel.showBadge {
Text("Premium")
}
}
}
}The ViewModel Layer
The ViewModel sits between Model and View. It takes raw Model data and transforms it into presentation-ready values the View can show directly.
It also exposes intents (methods) the View calls when the user interacts.
final class ProfileViewModel: ObservableObject {
@Published var displayName: String
@Published var showBadge: Bool
init(user: User) {
displayName = user.firstName + " " + user.lastName
showBadge = user.isPremium
}
}Why Separate Concerns?
When formatting, networking, and rendering are all tangled inside a view controller, that file becomes a massive, untestable blob.
By splitting responsibilities:
- The Model can be reused across screens
- The ViewModel can be unit tested without a UI
- The View stays small and declarative
What Belongs in the Model
Put in the Model:
- Domain entities (
User,Product) - Business validation rules
- Persistence and networking abstractions (often via services the ViewModel calls)
Never put UI strings, colors, or formatting in the Model.
What Belongs in the ViewModel
The ViewModel handles presentation logic:
- Formatting dates, currency, and names into display strings
- Deciding which UI states are visible (loading, error, empty)
- Coordinating calls to services and exposing results
final class CartViewModel: ObservableObject {
@Published var totalText: String = ""
func update(with order: Order) {
let formatter = NumberFormatter()
formatter.numberStyle = .currency
totalText = formatter.string(from: order.total as NSNumber) ?? "-"
}
}What Belongs in the View
The View should only:
- Lay out and render UI elements
- Read published state from the ViewModel
- Forward taps and gestures by calling ViewModel methods
If you find an if deciding business rules inside a View, that logic likely belongs in the ViewModel.
Data Flow in MVVM
The flow is one direction for data and the reverse for actions:
- Model -> ViewModel -> View for data
- View -> ViewModel for user intents
The View never talks to the Model directly. This keeps dependencies pointing inward toward your domain.
MVVM vs MVC
In classic MVC, the controller often grows huge because it owns formatting, networking, and view wiring all at once.
MVVM extracts that presentation logic into the ViewModel, leaving the controller (or SwiftUI View) thin. The ViewModel is UI-framework agnostic, so it is far easier to test.
A Complete Slice
Here is a small but complete MVVM slice tying the layers together.
struct Account { let balance: Decimal }
final class AccountViewModel: ObservableObject {
@Published var balanceText: String
init(account: Account) {
balanceText = "$" + "\(account.balance)"
}
}
struct AccountView: View {
@StateObject var viewModel: AccountViewModel
var body: some View { Text(viewModel.balanceText) }
}Quick Check
Test your understanding of MVVM responsibilities.
Recap
You learned the three layers of MVVM and their boundaries:
- Model — raw data and business rules, no UI
- ViewModel — presentation logic and intents
- View — pure rendering of ViewModel state
Keeping these concerns separate makes your code testable, reusable, and easy to reason about. Next we will wire a ViewModel to a View with bindings.
Frequently asked questions
Is the “The MVVM Pattern” lesson free?
Yes — the full text of “The MVVM Pattern” is free to read here on the web, and the Swift Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Swift Academy course, upgrade to CoddyKit PRO.
What will I learn in “The MVVM Pattern”?
Separate view, view model, and model concerns. You practise Swift Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Swift Academy?
No prior experience is required. Swift Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “The MVVM Pattern” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Swift Academy lesson?
Yes. Every Swift Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.