When I moved to SwiftUI, I started wondering how much of this still applies. Most of these patterns were created for UIKit, some even for completely different platforms. SwiftUI works very differently. So I went through them one by one and asked myself what problem each pattern was solving, and whether I still have that problem in SwiftUI.

This post is what I came up with (my personal take that can also vary depending on the individual project requirements).

What iOS Architecture Patterns Have in Common

Before comparing them, it helps to look at what they have in common. Every one of these patterns is a way of sorting your code into buckets.

Think of a wardrobe. You could throw all your clothes onto one pile, but getting dressed would be painful. So you sort them: one shelf for shirts, one for pants, a drawer for socks. Architecture patterns do the same thing for code. They give you a place for UI, a place for state and logic, and a place for data.

When I compared the patterns, I noticed that they all have a model and a view. The differences are in the layers between them, and in what I call the plumbing: how those layers talk to each other. Delegates, NotificationCenter, Combine, or bindings built into the framework.

That plumbing turned out to be the key to figuring out which patterns still matter.

MVC (Model-View-Controller): Why SwiftUI Doesn’t Need a Controller

MVC was Apple’s pattern for UIKit, and it’s built around the UIViewController. The controller sits between the model and the view and does most of the plumbing. It connects outlets, listens for data changes, and tells the table view to reload.

The problem with MVC is well known. The controller tends to collect everything, and you end up with what people jokingly call the “Massive View Controller.”

When I looked at MVC from a SwiftUI perspective, I noticed that the controller’s main job doesn’t exist anymore. SwiftUI updates the UI automatically when your state changes. There are no outlets to connect and no table view to reload. The framework does the work the controller used to do.

So for SwiftUI, MVC isn’t really relevant anymore.

MVP (Model-View-Presenter)

MVP replaces the controller with a presenter. The presenter holds the logic, and the view stays passive: it only displays what the presenter tells it to display. In UIKit this was popular for testability, since you could test the presenter without any UI.

But MVP is also mostly about plumbing. The presenter pushes updates into the view manually. In SwiftUI, the view reads state and updates itself, so that manual connection is exactly what SwiftUI removed.

I don’t see a reason to use MVP in SwiftUI either.

VIPER: Too Much Ceremony for Most SwiftUI Apps

VIPER splits each screen into five layers: view, interactor, presenter, entity, and a layer for navigation. It was designed for large UIKit apps and comes with a lot of ceremony. Every layer has protocols, and there are strict rules for how the layers connect.

I spent a bit longer on VIPER, because it does solve real problems. In big teams, that ceremony gives consistency: every screen is built the same way, and everyone knows where things go. That’s valuable.

But when I looked at how much of that ceremony exists to manage UIKit’s plumbing, the answer was: a lot. In SwiftUI, much of it becomes overhead. For most SwiftUI apps, VIPER is too heavy.

MVVM (Model-View-ViewModel): The Natural Fit for SwiftUI

MVVM was created by John Gossman at Microsoft in 2005 for WPF. It splits a screen into three buckets: the model for the data, the view for the UI, and the view model as the layer backing the UI, holding its state and logic.

That’s how I use it in SwiftUI. A view can handle simple state and logic on its own, like a toggle with @State or a quick action on a button tap. But when the logic gets too complex, with network calls, loading and error handling, and state that changes in several ways, it doesn’t belong in the view anymore. That’s the point where I move it out into a view model that backs the UI, and the view goes back to layout and forwarding user actions. SwiftUI makes this split easy, because with @Observable the view reads the view model’s properties and updates automatically, without any extra plumbing.

As long as the logic in a view stays simple, I keep it there. I add a view model when the complexity calls for it, not by default for every screen.

MVC vs MVP vs MVVM vs VIPER: Side-by-Side Comparison

What Belongs in a SwiftUI View Model

Once the logic is complex enough to move out of the view, the next question is what exactly goes into the view model. For a while, my view models collected everything: state, networking, caching, formatting, navigation. They became the SwiftUI version of the Massive View Controller.

So I thought about what the view model is really for, and I landed on two jobs.

The view model holds UI state. That’s everything the view reads to render itself: the list of products, a loading flag, an error message.

The view model changes that state. User actions come in from the view: a tap, a pull to refresh, a toggle. The view model reacts and updates its state. The view never changes the state itself. It tells the view model what happened and then renders whatever the state looks like.

@MainActor
@Observable
final class ProductListViewModel {
    private(set) var products: [Product] = []
    private(set) var isLoading = false
    private(set) var errorMessage: String?

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async {
        isLoading = true
        defer { isLoading = false }

        do {
            products = try await service.fetchProducts()
        } catch {
            errorMessage = "Could not load products."
        }
    }

    func toggleFavorite(for product: Product) {
        guard let index = products.firstIndex(where: { $0.id == product.id }) else { return }
        products[index].isFavorite.toggle()
    }
}

@MainActor
@Observable
final class ProductListViewModel {
    private(set) var products: [Product] = []
    private(set) var isLoading = false
    private(set) var errorMessage: String?

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async {
        isLoading = true
        defer { isLoading = false }

        do {
            products = try await service.fetchProducts()
        } catch {
            errorMessage = "Could not load products."
        }
    }

    func toggleFavorite(for product: Product) {
        guard let index = products.firstIndex(where: { $0.id == product.id }) else { return }
        products[index].isFavorite.toggle()
    }
}

The view stays simple. It reads the state and forwards user actions:

struct ProductListView: View {
    let viewModel: ProductListViewModel

    var body: some View {
        List(viewModel.products) { product in
            ProductRow(product: product) {
                viewModel.toggleFavorite(for: product)
            }
        }
        .overlay {
            if viewModel.isLoading { ProgressView() }
        }
        .task { await viewModel.loadProducts() }
        .refreshable { await viewModel.loadProducts() }
    }
}

struct ProductListView: View {
    let viewModel: ProductListViewModel

    var body: some View {
        List(viewModel.products) { product in
            ProductRow(product: product) {
                viewModel.toggleFavorite(for: product)
            }
        }
        .overlay {
            if viewModel.isLoading { ProgressView() }
        }
        .task { await viewModel.loadProducts() }
        .refreshable { await viewModel.loadProducts() }
    }
}

From these two jobs, I got my rule: if the UI doesn’t read it, it doesn’t belong in the view model.

Where Networking and Data Access Go: The Service Layer

That rule immediately raised the next question: where does everything else go?

The view model doesn’t fetch, decode, or save anything itself. It calls a service and assigns the result to its state. Services handle data access: networking, persistence, authentication.

protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

And this is where I noticed that MVVM stops describing my app. Classic MVVM has three layers: model, view, and view model. Real apps need more than that. Below the view model, I have services for data access, and sometimes separate types for states that the UI never shows, like a token store. Using dependency injection (Dependency Inversion Principle) helps with testing and loose coupling.

None of that is in the original pattern. It’s what I needed to keep each layer focused on one concern.

SwiftUI Navigation with Coordinators: Deep Links and Programmatic Navigation

Navigation was the last piece that didn’t fit anywhere.

Here’s an example that made this clear to me. Say your app is connected to a server, and the user suddenly gets a bonus you want to show in a sheet. Who checks the server? Who presents the sheet? Which view? Which view model? If you put it into one of the existing view models, it’s in the wrong place. The bonus has nothing to do with the product list that happens to be on screen.

The same happens with deep links. When a link opens a specific product, something has to switch to the right tab, push the right screens, and maybe dismiss a sheet that’s currently open. No single view model owns all of that.

So I added coordinators. The way I see it, navigation is UI state too: the current tab, the navigation path, the presented sheet. The view reads it to decide what to show. So a coordinator is an @Observable type on the main actor, just like a view model, but its concern is navigation:

enum ShopDestination: Hashable {
    case productDetail(Product.ID)
    case cart
}

@MainActor
@Observable
final class ShopCoordinator {
    var path: [ShopDestination] = []
    var presentedBonus: Bonus?

    func showProduct(_ id: Product.ID) {
        path.append(.productDetail(id))
    }

    func showCart() {
        path.append(.cart)
    }

    func showBonus(_ bonus: Bonus) {
        presentedBonus = bonus
    }

    func popToRoot() {
        path.removeAll()
    }
}

enum ShopDestination: Hashable {
    case productDetail(Product.ID)
    case cart
}

@MainActor
@Observable
final class ShopCoordinator {
    var path: [ShopDestination] = []
    var presentedBonus: Bonus?

    func showProduct(_ id: Product.ID) {
        path.append(.productDetail(id))
    }

    func showCart() {
        path.append(.cart)
    }

    func showBonus(_ bonus: Bonus) {
        presentedBonus = bonus
    }

    func popToRoot() {
        path.removeAll()
    }
}

The view binds its NavigationStack to the coordinator’s path, and navigating becomes a function call instead of something buried in a view.

For larger apps, I nest coordinators. Each feature has its own coordinator for its own navigation, and an app coordinator sits on top. It owns the child coordinators and handles everything that crosses features, like deep links:

@MainActor
@Observable
final class AppCoordinator {
    var selectedTab: Tab = .shop
    let shop = ShopCoordinator()
    let profile = ProfileCoordinator()

    func handle(_ deepLink: DeepLink) {
        switch deepLink {
        case .product(let id):
            selectedTab = .shop
            shop.popToRoot()
            shop.showProduct(id)
        case .settings:
            selectedTab = .profile
            profile.showSettings()
        }
    }
}

@MainActor
@Observable
final class AppCoordinator {
    var selectedTab: Tab = .shop
    let shop = ShopCoordinator()
    let profile = ProfileCoordinator()

    func handle(_ deepLink: DeepLink) {
        switch deepLink {
        case .product(let id):
            selectedTab = .shop
            shop.popToRoot()
            shop.showProduct(id)
        case .settings:
            selectedTab = .profile
            profile.showSettings()
        }
    }
}

A deep link comes in, the app coordinator switches the tab, and the shop coordinator pushes the product. Programmatic navigation works the same way: whoever needs to navigate calls the coordinator. For the bonus example, a service checks the server, and the coordinator presents the sheet. Each part does one job.

“No View Model” Approaches

Reading SwiftUI architecture discussions online can be confusing. One person says you don’t need view models. Another uses stores. A third puts everything in services. Each one sounds like a different architecture, and you start wondering which one you’re supposed to learn.

Then I look at the code and realize: it’s the same thing I already know, just with a different name. Here’s how I map these approaches back to familiar terms, so you can understand what someone means and move on.

1. “The view is the view model”

The first group says the view itself is the view model. State lives in @State, the logic sits in the view, and there is no extra class.

That’s a valid choice. I do the same for simple screens. If you want to keep the logic in the view, you can.

The trade-off shows up when the screen gets complex. Network calls, loading, error handling and state that changes in several ways all end up in body and its helper functions. The view gets long, and the logic is hard to test without the UI.

2. “No view model”, but a store

Many people who say “no view models” introduce a store once their screens get complex. Look at what that store is:

@Observable
final class ProductStore {
    private(set) var products: [Product] = []
    private(set) var isLoading = false

    func loadProducts() async { ... }
    func toggleFavorite(for product: Product) { ... }
}

@Observable
final class ProductStore {
    private(set) var products: [Product] = []
    private(set) var isLoading = false

    func loadProducts() async { ... }
    func toggleFavorite(for product: Product) { ... }
}

Now compare it to the view model from earlier in this post:

@Observable
final class ProductListViewModel {
    private(set) var products: [Product] = []
    private(set) var isLoading = false

    func loadProducts() async { ... }
    func toggleFavorite(for product: Product) { ... }
}

@Observable
final class ProductListViewModel {
    private(set) var products: [Product] = []
    private(set) var isLoading = false

    func loadProducts() async { ... }
    func toggleFavorite(for product: Product) { ... }
}

It’s the same type with a different name. An @Observable class that holds the state the UI reads and has methods the view calls. That is a view model.

3. A real service, but more code in the view

Others show a service that is injected with dependency injection and only wraps the network client:

protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

That is a real service in my book, and it’s exactly what I use below my view models. It holds no UI state.

But then the loading flag, the error message, the product list and the logic that ties them together have to live somewhere. Without a view model, they go into the view. So this is case 1 again, with more complex code in the view.

4. Called a service, but it holds UI state

The last variant is also called a service. But it’s an @Observable class with isLoading, errorMessage and the list the view displays, plus methods the view calls on user actions.

@Observable
final class ProductsService {
    private(set) var products: [Product] = []
    private(set) var isLoading = false

    func loadProducts() async { ... }
    func toggleFavorite(for product: Product) { ... }
}

@Observable
final class ProductsService {
    private(set) var products: [Product] = []
    private(set) var isLoading = false

    func loadProducts() async { ... }
    func toggleFavorite(for product: Product) { ... }
}

That’s a view model again. Usually it’s a view model that also does the networking, so it mixes UI state and data access in one type. It’s the same mix that turned view controllers into Massive View Controllers.

My advice: look at the code, not the name

If it’s an @Observable class that holds UI state and has methods the view calls, it’s a view model, whatever it’s called.

I know not everyone will like this classification. Some people see “store” as its own pattern. But a new name doesn’t make a new architecture. What matters is the concern of each type: UI state in one place, data access in another. If you call your view model a store, that’s fine. If your store also does the networking, that’s the real problem.

That’s my advice for reading about architecture online: don’t lose your mind over every new name. Look at the code, map it to what you already know, and move on. We don’t need to reinvent the wheel and give it a fancy acronym when the existing terms already describe it.

Not everyone will agree with this classification, and that’s fine. The name matters less than the concern of each type: UI state in one place, data access in another.

Why I Don’t Follow One Architecture Pattern Strictly

After going through all of this, I realized I can’t really give my approach a clean name. It’s MVVM at its core, with services below and coordinators for navigation, and it doesn’t follow every rule of the original pattern.

When I discussed this with other developers, someone described Apple’s own approach as “soft MVVM.” At first, calling a pattern “soft” sounded strange to me. But it describes pretty well what I do too: take the idea, keep the parts that solve my problems, and leave out the rest. For a simple screen that just displays some data, I don’t even add a view model.

I think that’s the healthier way to look at patterns. Someone made them up for a specific framework at a specific time. MVVM was created for WPF 20 years ago, and SwiftUI will keep changing too. What matters is the concern of each layer, not following the pattern’s name to the letter.

Why You Should Still Know Them All

That doesn’t mean you can skip MVC, MVP, and VIPER. You should still be able to explain all of them:

• Communication. When you mention MVVM or VIPER, other developers immediately understand what you mean.
• Documentation. Pattern names make your codebase easier to explain.
• Job interviews. You’ll be asked about them, and you need to explain what they are and how they differ.
• Legacy code. Many apps still have UIKit parts built with MVC or VIPER, and you might work with them.

How I Structure SwiftUI Apps

• Move logic into a view model when it gets too complex for the view. Simple state and logic can stay in the view. Network calls, loading and error handling, and complex state changes belong in a view model.
• Keep the view model for UI state. It holds the state the view reads and changes it in response to user actions. If the UI doesn’t read it, it doesn’t belong there.
• Move data work into services. Networking, persistence, and authentication go below the view model.
• Use coordinators for navigation. Treat navigation as UI state, and nest coordinators as your app grows, so deep links and programmatic navigation have one clear place.
• Know the other patterns. Understand MVC, MVP, and VIPER well enough to explain them and work with them in older code.
• Add layers when your code needs them. Not because a pattern tells you to.

If you want to go deeper into how to structure your SwiftUI apps, from views and view models to services and coordinators, check out my course.

The post MVC, MVP, MVVM, VIPER Which Ones Matter for SwiftUI? appeared first on swiftyplace.

In this post, I’ll show how dependency injection in SwiftUI works as an app grows, with one example that goes from a single screen to a full app. Passing the service through the view’s initializer works for a single screen, but breaks down once the screen is used inside other views. That’s why I put services into the SwiftUI environment, which also makes previews and UI tests easier.

Starting Simple: Passing the Service Through the View’s Initializer

First, the setup. It’s the same as in Dependency Injection in Swift: a protocol for the service, a live implementation, a mock, and a view model that gets the service through its initializer. You can read how to set this up in more detail in this blog post.

nonisolated protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

nonisolated struct LiveProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [Product] { /* request, decode */ }
}

nonisolated struct MockProductService: ProductService {
    var products: [Product] = []

    func fetchProducts() async throws -> [Product] { products }
}

@MainActor
@Observable
final class ProductViewModel {
    private(set) var state: LoadingState<[Product]> = .idle
    private let productService: ProductService

    init(productService: ProductService) {
        self.productService = productService
    }

    func load() async {
        state = .loading
        do {
            state = .loaded(try await productService.fetchProducts())
        } catch {
            state = .failed("Couldn't load products.")
        }
    }
}

nonisolated protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

nonisolated struct LiveProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [Product] { /* request, decode */ }
}

nonisolated struct MockProductService: ProductService {
    var products: [Product] = []

    func fetchProducts() async throws -> [Product] { products }
}

@MainActor
@Observable
final class ProductViewModel {
    private(set) var state: LoadingState<[Product]> = .idle
    private let productService: ProductService

    init(productService: ProductService) {
        self.productService = productService
    }

    func load() async {
        state = .loading
        do {
            state = .loaded(try await productService.fetchProducts())
        } catch {
            state = .failed("Couldn't load products.")
        }
    }
}

We start with a single screen that shows the products. The view creates its view model in @State, and the service is written right there:

struct ProductsScreen: View {
    @State private var viewModel = ProductViewModel(productService: LiveProductService())

    var body: some View {
        ProductListView(state: viewModel.state)
            .task { await viewModel.load() }
    }
}

#Preview {
    ProductsScreen() // calls the real API
}

struct ProductsScreen: View {
    @State private var viewModel = ProductViewModel(productService: LiveProductService())

    var body: some View {
        ProductListView(state: viewModel.state)
            .task { await viewModel.load() }
    }
}

#Preview {
    ProductsScreen() // calls the real API
}

The view model itself is fine: it takes a protocol in its initializer. But the view hard-codes which service to pass, so the preview always calls the real API. Without a network connection, it shows an error; with a slow one, a spinner.

The fix is the same idea one level up: the view gets the service through its own initializer. The live service is the default, so nothing changes for the rest of the app:

struct ProductsScreen: View {
    @State private var viewModel: ProductViewModel

    init(productService: ProductService = LiveProductService()) {
        _viewModel = State(initialValue: ProductViewModel(productService: productService))
    }

    var body: some View {
        ProductListView(state: viewModel.state)
            .task { await viewModel.load() }
    }
}

#Preview {
    ProductsScreen(productService: MockProductService(products: Product.samples))
}

struct ProductsScreen: View {
    @State private var viewModel: ProductViewModel

    init(productService: ProductService = LiveProductService()) {
        _viewModel = State(initialValue: ProductViewModel(productService: productService))
    }

    var body: some View {
        ProductListView(state: viewModel.state)
            .task { await viewModel.load() }
    }
}

#Preview {
    ProductsScreen(productService: MockProductService(products: Product.samples))
}

• The app keeps calling ProductsScreen(). Only the preview passes the mock.
• _viewModel = State(initialValue:) sets the initial value of the @State property from inside init. The underscore accesses the property wrapper itself instead of the wrapped value.
• The initial value is only used the first time. SwiftUI keeps the first view model for as long as the view is on screen. If the parent later re-creates ProductsScreen with a different service, the new one is ignored.
• Keep the view model’s init cheap. Every time the parent re-creates the ProductsScreen struct, this init runs and creates a new ProductViewModel, which SwiftUI then throws away. That’s fine as long as the initializer only stores its dependencies and doesn’t start any work.

This works as long as the screen is only previewed on its own. As you’ll see next, it breaks down as soon as the screen is used inside other views.

Why Initializer Injection Breaks Down as the App Grows

Now the app grows. ProductsScreen becomes one tab in a RootTabView, next to a FavoritesScreen that works the same way:

struct RootTabView: View {
    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen()      // default: live service
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen()     // default: live service
            }
        }
    }
}

#Preview {
    RootTabView() // both tabs use the real API and the real UserDefaults
}

struct RootTabView: View {
    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen()      // default: live service
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen()     // default: live service
            }
        }
    }
}

#Preview {
    RootTabView() // both tabs use the real API and the real UserDefaults
}

The preview of ProductsScreen still works, because it passes the mock itself. But the preview of RootTabView creates both screens with their defaults, the live services. There’s no way to reach in and change that from the outside.

With initializer injection, the only fix is to pass the services through the parent:

struct RootTabView: View {
    let productService: ProductService     // not used here, only passed on
    let favoritesService: FavoritesService // not used here, only passed on

    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen(productService: productService)
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen(favoritesService: favoritesService)
            }
        }
    }
}

#Preview {
    RootTabView(
        productService: MockProductService(products: Product.samples),
        favoritesService: MockFavoritesService()
    )
}

struct RootTabView: View {
    let productService: ProductService     // not used here, only passed on
    let favoritesService: FavoritesService // not used here, only passed on

    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen(productService: productService)
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen(favoritesService: favoritesService)
            }
        }
    }
}

#Preview {
    RootTabView(
        productService: MockProductService(products: Product.samples),
        favoritesService: MockFavoritesService()
    )
}

This works for one level. Here’s how it gets worse as the app grows:

• RootTabView takes dependencies it doesn’t use. It only has the services so it can pass them to its children.
• Every new level adds the same parameters. If ProductsScreen shows a ProductDetailScreen with its own view model, ProductsScreen also needs to pass the service on, even though its own view model already has one.
• Every new service adds a parameter to every view in the chain. Add a cart service, and RootTabView, ProductsScreen, and every view in between get another parameter.
• Every view above needs this to be previewable. If one view in the chain uses the default instead of passing the service on, every preview above it calls the real API again.

That’s why I don’t pass services through view initializers. I prefer to put them into the environment.

The Solution: Services in the SwiftUI Environment

The environment solves exactly the problem from the previous section. A value set on a view reaches every view below it, and none of the views in between need to know about it.

Put the service into the environment

With the @Entry macro, this is one line per service in an extension on EnvironmentValues:

extension EnvironmentValues {
    @Entry var productService: ProductService = LiveProductService()
    @Entry var favoritesService: FavoritesService = LiveFavoritesService()
}

extension EnvironmentValues {
    @Entry var productService: ProductService = LiveProductService()
    @Entry var favoritesService: FavoritesService = LiveFavoritesService()
}

• The type is the protocol. If it were LiveProductService, you couldn’t put a mock in its place.
• The default is the live service. If nobody sets a value, every view gets the live service, so the app works without any setup at the root.
• A live default is safe here because the services are stateless nonisolated Sendable structs. Without an injected value, SwiftUI may create the default more than once, and for a stateless service, extra copies change nothing.

Read it and create the view model

The screen reads the service with @Environment. The environment isn’t available yet when the view’s init runs, so the view model can’t be created there anymore. Instead, it’s an optional and gets created in .task:

struct ProductsScreen: View {
    @Environment(.productService) private var productService
    @State private var viewModel: ProductViewModel?

    var body: some View {
        Group {
            if let viewModel {
                ProductListView(state: viewModel.state)
            } else {
                ProgressView()
            }
        }
        .task {
            if viewModel == nil {
                viewModel = ProductViewModel(productService: productService)
            }
            await viewModel?.load()
        }
    }
}

struct ProductsScreen: View {
    @Environment(.productService) private var productService
    @State private var viewModel: ProductViewModel?

    var body: some View {
        Group {
            if let viewModel {
                ProductListView(state: viewModel.state)
            } else {
                ProgressView()
            }
        }
        .task {
            if viewModel == nil {
                viewModel = ProductViewModel(productService: productService)
            }
            await viewModel?.load()
        }
    }
}

• .task runs every time the view appears, for example when the user switches back to this tab. The if viewModel == nil check makes sure the view model is only created the first time.
• The view model is created exactly once.

RootTabView goes back to having no parameters at all:

struct RootTabView: View {
    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen()
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen()
            }
        }
    }
}

struct RootTabView: View {
    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen()
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen()
            }
        }
    }
}

Override it where you need a different service

Now one modifier on any view replaces the service for everything below it:

#Preview("Root") {
    RootTabView()
        .environment(.productService, MockProductService(products: Product.samples))
        .environment(.favoritesService, MockFavoritesService())
}

#Preview("Products") {
    ProductsScreen()
        .environment(.productService, MockProductService(products: Product.samples))
}

#Preview("Root") {
    RootTabView()
        .environment(.productService, MockProductService(products: Product.samples))
        .environment(.favoritesService, MockFavoritesService())
}

#Preview("Products") {
    ProductsScreen()
        .environment(.productService, MockProductService(products: Product.samples))
}

It doesn’t matter how deep ProductsScreen sits in the hierarchy. The override on the parent preview reaches it. You only set it on the views that need a different service: in previews, or on one part of the app that should use another service.

Variant: keep the view model non-optional

If you don’t want the optional view model, there’s a middle way. ProductsScreen keeps its initializer from the first example, and the view that shows it reads the environment and passes the service in:

struct RootTabView: View {
    @Environment(.productService) private var productService
    @Environment(.favoritesService) private var favoritesService

    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen(productService: productService)
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen(favoritesService: favoritesService)
            }
        }
    }
}

struct RootTabView: View {
    @Environment(.productService) private var productService
    @Environment(.favoritesService) private var favoritesService

    var body: some View {
        TabView {
            Tab("Products", systemImage: "bag") {
                ProductsScreen(productService: productService)
            }
            Tab("Favorites", systemImage: "heart") {
                FavoritesScreen(favoritesService: favoritesService)
            }
        }
    }
}

• ProductsScreen stays as simple as in the first example, with a non-optional view model.
• Only the parent touches the environment, and an override on its preview still reaches both tabs.
• The caveats from the first example come back: the initial value is only used the first time, and the view model’s init must stay cheap.

Why This Matters for UI Tests

The same property pays off again in UI tests. A UI test runs the app in a separate process, so it can’t pass a mock into a view. All it can do is launch the app with arguments.

With initializer injection, the app would have to pass the mock down every chain of views to every screen. With the environment, the app reads the argument and sets the mock once, wherever it should apply. Here it’s set at the root, for the whole app:

@main
struct ShopApp: App {
    private let productService: ProductService

    init() {
        if ProcessInfo.processInfo.arguments.contains("-uiTesting") {
            productService = MockProductService(products: Product.samples)
        } else {
            productService = LiveProductService()
        }
    }

    var body: some Scene {
        WindowGroup {
            RootTabView()
                .environment(.productService, productService)
        }
    }
}

@main
struct ShopApp: App {
    private let productService: ProductService

    init() {
        if ProcessInfo.processInfo.arguments.contains("-uiTesting") {
            productService = MockProductService(products: Product.samples)
        } else {
            productService = LiveProductService()
        }
    }

    var body: some Scene {
        WindowGroup {
            RootTabView()
                .environment(.productService, productService)
        }
    }
}

Every screen in the app picks up the mock, and none of them knows it’s running in a UI test. How the test passes the launch argument, and how to set up different scenarios, is the topic of UI Testing SwiftUI Apps With Mock Services.

If only one feature should use the mock, set the same .environment on that feature’s view instead, like the products tab. Everything in that branch gets the mock, and the rest of the app keeps the live service.

Keeping Previews Safe

The live default has one downside. If a preview forgets the override, nothing tells you: the preview uses the live service and calls the real API. With one service that’s easy to remember. With several, every preview has to override every one of them.

A small view extension collects all mocks in one place:

extension View {
    func injectMockServices() -> some View {
        self
            .environment(.productService, MockProductService(products: Product.samples))
            .environment(.favoritesService, MockFavoritesService())
    }
}

#Preview {
    RootTabView()
        .injectMockServices()
}

extension View {
    func injectMockServices() -> some View {
        self
            .environment(.productService, MockProductService(products: Product.samples))
            .environment(.favoritesService, MockFavoritesService())
    }
}

#Preview {
    RootTabView()
        .injectMockServices()
}

When you add a new service, you add its mock here once, and every preview that uses injectMockServices() gets it.

To use a live service for one preview and mocks for everything else, set the specific value before the modifier:

#Preview("Real Product API") {
    RootTabView()
        .environment(.productService, LiveProductService()) // must come before injectMockServices()
        .injectMockServices()
}

#Preview("Real Product API") {
    RootTabView()
        .environment(.productService, LiveProductService()) // must come before injectMockServices()
        .injectMockServices()
}

The order matters because environment values set closer to the view win. The .environment call directly on RootTabView is applied innermost, so it overrides the value that injectMockServices() sets further out.

The Alternative: DI Containers Like Factory

The environment works, but it has a cost. Every screen now has an @Environment property, an optional @State view model, a .task that creates it, and a nil case to handle. With a handful of screens, that’s fine. With many, it’s the same few lines over and over. That’s usually why people reach for a DI container. One of the most popular one in Swift is Factory.

Another option is Point-Free’s swift-dependencies, which takes a similar approach with a @Dependency property wrapper, and is built around task-local values from the start.

What Factory automates

Each dependency is registered once, in an extension on Factory’s Container. The view model then resolves it with the @Injected property wrapper:

import Factory

extension Container {
    var productService: Factory<ProductService> {
        self { LiveProductService() }
    }
}

@MainActor
@Observable
final class ProductViewModel {
    @ObservationIgnored
    @Injected(.productService) private var productService

    private(set) var state: LoadingState<[Product]> = .idle

    func load() async { /* ... */ }
}

import Factory

extension Container {
    var productService: Factory<ProductService> {
        self { LiveProductService() }
    }
}

@MainActor
@Observable
final class ProductViewModel {
    @ObservationIgnored
    @Injected(.productService) private var productService

    private(set) var state: LoadingState<[Product]> = .idle

    func load() async { /* ... */ }
}

The main win: a simpler view

Compare the screen with the environment version from above. With Factory, the view model gets its service on its own, so the view just creates it:

struct ProductsScreen: View {
    @State private var viewModel = ProductViewModel()

    var body: some View {
        ProductListView(state: viewModel.state)
            .task { await viewModel.load() }
    }
}

struct ProductsScreen: View {
    @State private var viewModel = ProductViewModel()

    var body: some View {
        ProductListView(state: viewModel.state)
            .task { await viewModel.load() }
    }
}

No @Environment property, no optional view model, no nil case, and no creating the view model in .task. And that’s on every screen.

Overrides for previews

Instead of .environment overrides, you register a different version. Here are the same examples as above, with Factory.

The parent preview:

#Preview {
    let _ = Container.shared.productService.register {
        MockProductService(products: Product.samples)
    }
    RootTabView()
}

#Preview {
    let _ = Container.shared.productService.register {
        MockProductService(products: Product.samples)
    }
    RootTabView()
}

Resolving the whole dependency graph

The bigger benefit shows up when dependencies depend on each other. The view model needs a product service, the service needs an APIClient, and the APIClient needs the token store that holds the current auth token. Without a container, someone has to create all of these in the right order and pass each one into the next.

With Factory, each dependency is registered once, together with what it needs:

extension Container {
    var tokenStore: Factory<TokenStore> {
        self { LiveTokenStore() }.singleton
    }

    var apiClient: Factory<APIClient> {
        self { APIClient(tokenStore: self.tokenStore()) }
    }

    var productService: Factory<ProductService> {
        self { LiveProductService(apiClient: self.apiClient()) }
    }
}

extension Container {
    var tokenStore: Factory<TokenStore> {
        self { LiveTokenStore() }.singleton
    }

    var apiClient: Factory<APIClient> {
        self { APIClient(tokenStore: self.tokenStore()) }
    }

    var productService: Factory<ProductService> {
        self { LiveProductService(apiClient: self.apiClient()) }
    }
}

When the view model asks for productService, Factory resolves the whole chain. .singleton makes sure the whole app shares one token store. How to build the same graph without a framework is the topic of Building the Dependency Graph in SwiftUI.

Where it gets harder

• Parallel tests. Registrations live in one shared container, so tests that run at the same time can overwrite each other’s mocks. To keep them separate, each test gets its own container through a @TaskLocal. The drawback is making that work reliably: task-local values only reach code that runs inside the test’s task. Point-Free put a lot of work into this in their swift-dependencies library, and I’m still not sure I’d catch every case. I’d rather not spend my time hunting test failures that only show up sometimes.
• Hidden dependencies. Dependencies no longer show up in the initializer. Nothing reminds you to register a mock, so it’s easy to forget one, for example in a preview, and silently call the live service.
• Multi-window apps. Factory’s scopes are app-wide, not per window. A repository, an object that holds state below the UI like an image cache, is shared by every window if it’s a singleton. On iPad and Mac, each window often needs its own repository, with its own cache or selection, while the token store stays one per app. With the environment, this comes for free: each window has its own view tree, so a repository created inside the WindowGroup content exists once per window. With Factory, you need a custom scope or have to pass a window identifier around. More on per-window lifetimes in Building the Dependency Graph in SwiftUI.

My take

I show DI frameworks as an option, not a recommendation. They look easy at the start: register a dependency, add @Injected, done. The problems come later. If the scopes and overrides aren’t set up right, you get shared state you didn’t expect, like the multi-window case above, and the dependencies no longer show up in the initializer. And once the whole app resolves its dependencies through the framework, moving away from it means touching every view model.

The initializer and environment approach needs more code, but it’s plain Swift and SwiftUI that you can read, understand, and change.

Outlook: MVVM-C

There’s one more way to look at this. With coordinators, views no longer create their view models at all. The coordinator builds each view model with plain initializer injection and passes the dependencies from parent to child coordinator. That replaces most of the environment setup from this post, and gives per-window instances with one coordinator per window.

That’s a bigger topic, so it gets two posts of its own: MVVM-C in SwiftUI: Why, What, and How, and Dependency Injection With MVVM-C.

Summary

There’s also a limit. Everything in this post works because the services are stateless, so a live default and extra copies are harmless. A token store or a repository with a cache holds state, and there a live default would quietly create a second instance. Where and how to create those is the topic of Building the Dependency Graph in SwiftUI.

Get the MVVM SwiftUI Cheat Sheet

The cheat sheet puts the whole system on a few pages: what goes in a view model, which view owns it, how to pass it down the tree, common mistakes, and code skeletons you can copy.

Get the free cheat sheet

Further Reading

• What Is a View Model in SwiftUI, Really?
• When to Use a View Model in SwiftUI (and When It’s Overkill)
• What Should Go in a View Model in SwiftUI?
• Dependency Injection in Swift: Services, Protocols, and Testable View Models

The post Dependency Injection in SwiftUI: Initializer, Environment, or Container appeared first on swiftyplace.

The easiest way to get there is to write that code right into the view model. A URLSession call here, a JSONDecoder there. It works, until you open a preview and it spins forever, or crashes because there’s no server. Or until you try to write a test, and it’s slow, fails randomly, or can’t be written at all.

In this post, I’ll show you how to fix both problems with dependency injection in Swift: move that work into services, let your view models depend on a protocol instead of the real thing, and inject what you need. By the end, every view model can run in a preview and a unit test without touching UserDefaults or the network.

Why keeping UserDefaults Code Inside the View Model becomes a Problem

Let’s start with a simple example. Users can mark products as favorites, and the favorites are saved in UserDefaults. Here’s the version most of us write first, with UserDefaults right inside the view model:

@MainActor
@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let key = "favoriteProductIDs"

    init() {
        // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Reading UserDefaults inside the view model
        favoriteIDs = Set(UserDefaults.standard.stringArray(forKey: key) ?? [])
    }

    func toggleFavorite(_ product: Product) {
        if favoriteIDs.contains(product.id) {
            favoriteIDs.remove(product.id)
        } else {
            favoriteIDs.insert(product.id)
        }
        // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Writing UserDefaults inside the view model
        UserDefaults.standard.set(Array(favoriteIDs), forKey: key)
    }
}

@MainActor
@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let key = "favoriteProductIDs"

    init() {
        // ⚠ Reading UserDefaults inside the view model
        favoriteIDs = Set(UserDefaults.standard.stringArray(forKey: key) ?? [])
    }

    func toggleFavorite(_ product: Product) {
        if favoriteIDs.contains(product.id) {
            favoriteIDs.remove(product.id)
        } else {
            favoriteIDs.insert(product.id)
        }
        // ⚠ Writing UserDefaults inside the view model
        UserDefaults.standard.set(Array(favoriteIDs), forKey: key)
    }
}

This works in the app. The problems show up everywhere else.

Previews keep what you tapped. Tap a heart in the preview, and it’s written to the real UserDefaults. Open the preview again tomorrow, and the favorite is still there. You can’t reliably show the empty state, and to show a screen with three favorites, you have to tap them again every time, or write test data into UserDefaults by hand.

Tests depend on each other. Say one test checks that toggling adds a favorite, and another checks that a new view model starts with no favorites:

@Test func toggleAddsFavorite() {
    let viewModel = FavoritesViewModel()
    viewModel.toggleFavorite(Product.samples[0])
    #expect(viewModel.favoriteIDs.count == 1)
}

@Test func startsWithNoFavorites() {
    let viewModel = FavoritesViewModel()
    #expect(viewModel.favoriteIDs.isEmpty) // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/274c.png" alt="❌" class="wp-smiley" style="height: 1em; max-height: 1em;" /> fails if the other test ran first
}

@Test func toggleAddsFavorite() {
    let viewModel = FavoritesViewModel()
    viewModel.toggleFavorite(Product.samples[0])
    #expect(viewModel.favoriteIDs.count == 1)
}

@Test func startsWithNoFavorites() {
    let viewModel = FavoritesViewModel()
    #expect(viewModel.favoriteIDs.isEmpty) // ❌ fails if the other test ran first
}

Both tests read and write the same key in the same UserDefaults. Whether the second one passes depends on which test runs first, and on what earlier runs left behind. Run them in parallel, and they fail at random. That’s the worst kind of test: one you stop trusting.

The view model has two jobs. It manages the favorites as UI state, and it knows how they’re stored: the key, the format, the storage API. Switch to iCloud or a file later, and you rewrite the view model. Need favorites in a second view model, and you copy the storage code.

UserDefaults is just one example. The problem has a name: a shared external dependency, a resource outside your own code that’s shared with the system, the rest of your app, and other tests. Think of:

• the network
• the file system
• UserDefaults and the Keychain
• HealthKit, location, contacts
• even the current date and time

With the network, it gets worse: requests are slow, and they fail for reasons that have nothing to do with your code. That leads to a simple rule: shared external dependencies go behind a boundary you control. Everything else, like your models and the view model’s own logic, can run for real.

Step 1: Move the Storage Code Into a Service

So the storage code moves into a service. A service is a helper worker: a stateless type that handles one kind of work with a shared external dependency.

nonisolated struct FavoritesService {
    private let key = "favoriteProductIDs"

    func loadFavoriteIDs() -> Set<Product.ID> {
        Set(UserDefaults.standard.stringArray(forKey: key) ?? [])
    }

    func saveFavoriteIDs(_ ids: Set<Product.ID>) {
        UserDefaults.standard.set(Array(ids), forKey: key)
    }
}

nonisolated struct FavoritesService {
    private let key = "favoriteProductIDs"

    func loadFavoriteIDs() -> Set<Product.ID> {
        Set(UserDefaults.standard.stringArray(forKey: key) ?? [])
    }

    func saveFavoriteIDs(_ ids: Set<Product.ID>) {
        UserDefaults.standard.set(Array(ids), forKey: key)
    }
}

• Stateless: it has no properties that change. It takes input, does the work, and returns a result. The favorites themselves stay in the view model.
• Reusable: any view model that needs favorites can use it, like a product list and a product detail screen.
• Ready for the background: it’s nonisolated, so it isn’t tied to the main actor. Reading UserDefaults is fast, but for slow work like network requests, the service can run its functions in the background, as you’ll see in the second example.

The view model keeps its job, managing the state, and hands the storage work to the service:

@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let favoritesService = FavoritesService()

    init() {
        favoriteIDs = favoritesService.loadFavoriteIDs()
    }

    func toggleFavorite(_ product: Product) {
        if favoriteIDs.contains(product.id) {
            favoriteIDs.remove(product.id)
        } else {
            favoriteIDs.insert(product.id)
        }
        favoritesService.saveFavoriteIDs(favoriteIDs)
    }
}

@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let favoritesService = FavoritesService()

    init() {
        favoriteIDs = favoritesService.loadFavoriteIDs()
    }

    func toggleFavorite(_ product: Product) {
        if favoriteIDs.contains(product.id) {
            favoriteIDs.remove(product.id)
        } else {
            favoriteIDs.insert(product.id)
        }
        favoritesService.saveFavoriteIDs(favoriteIDs)
    }
}

One naming rule I stick to: a service never holds UI state. If something called a “service” has @Observable properties that views read, it’s a view model with the wrong name.

Step 2: Dependency Injection With a Protocol (the Dependency Inversion Principle)

Moving the storage code into a service cleaned up the view model. But it didn’t solve the preview and test problem yet. The view model creates the service itself, so it’s still locked to the real UserDefaults:

@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let favoritesService = FavoritesService() // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> always the real UserDefaults

    // ...
}

@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let favoritesService = FavoritesService() // ⚠ always the real UserDefaults

    // ...
}

No preview or test can change that. The fix is to flip the dependency around. Instead of depending on the concrete service, the view model depends on a description of what it needs: a protocol. That’s the Dependency Inversion Principle (DIP): high-level code, like your view model, shouldn’t depend on low-level details, like the code that reads and writes UserDefaults. Both depend on an abstraction in between: the protocol.

The protocol describes what the view model needs:

nonisolated protocol FavoritesService: Sendable {
    func loadFavoriteIDs() -> Set<Product.ID>
    func saveFavoriteIDs(_ ids: Set<Product.ID>)
}

nonisolated protocol FavoritesService: Sendable {
    func loadFavoriteIDs() -> Set<Product.ID>
    func saveFavoriteIDs(_ ids: Set<Product.ID>)
}

The service we wrote above becomes the live implementation:

nonisolated struct LiveFavoritesService: FavoritesService {
    private let key = "favoriteProductIDs"

    func loadFavoriteIDs() -> Set<Product.ID> {
        Set(UserDefaults.standard.stringArray(forKey: key) ?? [])
    }

    func saveFavoriteIDs(_ ids: Set<Product.ID>) {
        UserDefaults.standard.set(Array(ids), forKey: key)
    }
}

nonisolated struct LiveFavoritesService: FavoritesService {
    private let key = "favoriteProductIDs"

    func loadFavoriteIDs() -> Set<Product.ID> {
        Set(UserDefaults.standard.stringArray(forKey: key) ?? [])
    }

    func saveFavoriteIDs(_ ids: Set<Product.ID>) {
        UserDefaults.standard.set(Array(ids), forKey: key)
    }
}

The protocol is nonisolated and Sendable, so the view model on the main actor can hold it, and implementations aren’t tied to the main actor.

Now the view model receives whichever implementation you want through its initializer, with the live service as the default:

@MainActor
@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let favoritesService: FavoritesService

    init(favoritesService: FavoritesService = LiveFavoritesService()) {
        self.favoritesService = favoritesService
        favoriteIDs = favoritesService.loadFavoriteIDs()
    }

    func toggleFavorite(_ product: Product) {
        if favoriteIDs.contains(product.id) {
            favoriteIDs.remove(product.id)
        } else {
            favoriteIDs.insert(product.id)
        }
        favoritesService.saveFavoriteIDs(favoriteIDs)
    }
}

@MainActor
@Observable
final class FavoritesViewModel {
    private(set) var favoriteIDs: Set<Product.ID> = []
    private let favoritesService: FavoritesService

    init(favoritesService: FavoritesService = LiveFavoritesService()) {
        self.favoritesService = favoritesService
        favoriteIDs = favoritesService.loadFavoriteIDs()
    }

    func toggleFavorite(_ product: Product) {
        if favoriteIDs.contains(product.id) {
            favoriteIDs.remove(product.id)
        } else {
            favoriteIDs.insert(product.id)
        }
        favoritesService.saveFavoriteIDs(favoriteIDs)
    }
}

In the app, nothing changes: FavoritesViewModel() uses the live service. Previews and tests pass in a mock. That’s all dependency injection is: the view model gets its dependencies from outside instead of creating them itself.

Initializer injection is the simplest way, and it’s what this post uses. It’s not the only one. In a real SwiftUI app, the bigger question is how dependencies get from the app’s entry point to every view model that needs them, especially when several view models share one instance. Common approaches are the SwiftUI environment and a dependency container. That’s a topic of its own, which I cover in SwiftUI Dependency Injection: Initializer, Environment, or Container?.

What You Gain: Previews for Every State

Here’s where the protocol pays off first. A mock conforms to the same protocol, but instead of touching UserDefaults, it starts with whatever favorites you give it and keeps everything in memory:

nonisolated struct MockFavoritesService: FavoritesService {
    var favoriteIDs: Set<Product.ID> = []

    func loadFavoriteIDs() -> Set<Product.ID> { favoriteIDs }
    func saveFavoriteIDs(_ ids: Set<Product.ID>) {}
}

nonisolated struct MockFavoritesService: FavoritesService {
    var favoriteIDs: Set<Product.ID> = []

    func loadFavoriteIDs() -> Set<Product.ID> { favoriteIDs }
    func saveFavoriteIDs(_ ids: Set<Product.ID>) {}
}

Now each preview injects a differently configured mock. @Previewable @State makes the preview the owner of the view model, just like the parent view in your app, so it’s created once instead of on every preview update:

#Preview("No Favorites") {
    @Previewable @State var viewModel = FavoritesViewModel(
        favoritesService: MockFavoritesService()
    )
    FavoritesView(viewModel: viewModel)
}

#Preview("With Favorites") {
    @Previewable @State var viewModel = FavoritesViewModel(
        favoritesService: MockFavoritesService(
            favoriteIDs: Set(Product.samples.prefix(3).map(.id))
        )
    )
    FavoritesView(viewModel: viewModel)
}

#Preview("No Favorites") {
    @Previewable @State var viewModel = FavoritesViewModel(
        favoritesService: MockFavoritesService()
    )
    FavoritesView(viewModel: viewModel)
}

#Preview("With Favorites") {
    @Previewable @State var viewModel = FavoritesViewModel(
        favoritesService: MockFavoritesService(
            favoriteIDs: Set(Product.samples.prefix(3).map(.id))
        )
    )
    FavoritesView(viewModel: viewModel)
}

Every state of the screen is one click away in Xcode, and tapping favorites in the preview never changes what’s saved on your Mac or simulator. Keep sample data like Product.samples next to the model, so previews and tests share it.

What You Gain: Reliable Unit Tests for View Models

The same mock makes unit tests straightforward. Inject it, call a method, and check the state:

import Testing

@MainActor
struct FavoritesViewModelTests {
    @Test func toggleAddsFavorite() {
        let product = Product.samples[0]
        let viewModel = FavoritesViewModel(favoritesService: MockFavoritesService())

        viewModel.toggleFavorite(product)

        #expect(viewModel.favoriteIDs == [product.id])
    }

    @Test func toggleRemovesExistingFavorite() {
        let product = Product.samples[0]
        let viewModel = FavoritesViewModel(
            favoritesService: MockFavoritesService(favoriteIDs: [product.id])
        )

        viewModel.toggleFavorite(product)

        #expect(viewModel.favoriteIDs.isEmpty)
    }
}

import Testing

@MainActor
struct FavoritesViewModelTests {
    @Test func toggleAddsFavorite() {
        let product = Product.samples[0]
        let viewModel = FavoritesViewModel(favoritesService: MockFavoritesService())

        viewModel.toggleFavorite(product)

        #expect(viewModel.favoriteIDs == [product.id])
    }

    @Test func toggleRemovesExistingFavorite() {
        let product = Product.samples[0]
        let viewModel = FavoritesViewModel(
            favoritesService: MockFavoritesService(favoriteIDs: [product.id])
        )

        viewModel.toggleFavorite(product)

        #expect(viewModel.favoriteIDs.isEmpty)
    }
}

This solves the leaky test problem from the beginning. With the live service, the first test would write a favorite to the real UserDefaults, and the second test, or the next run, would find it there. With the mock, every test starts with exactly the favorites it sets up, and nothing is left behind. That also means the tests are fast and can run in parallel.

Test what the view model is responsible for: how its state changes when you call its methods. What you don’t test here is UserDefaults itself, and you don’t test the UI; the view model only exposes state.

A Second Example: Loading Products From the Network

The same pattern works for every shared external dependency. The network adds two things the favorites example didn’t need: the work is slow, so it should run in the background, and the screen now has loading and error states.

The protocol describes what the view model needs, and the live service does the request and decoding in the background with @concurrent:

nonisolated protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

nonisolated struct LiveProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [Product] {
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Product].self, from: data)
    }
}

nonisolated protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

nonisolated struct LiveProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [Product] {
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Product].self, from: data)
    }
}

The view model receives the service through its initializer and manages the loading state:

@MainActor
@Observable
final class ProductViewModel {
    private(set) var state: LoadingState<[Product]> = .idle
    private let productService: ProductService

    init(productService: ProductService = LiveProductService()) {
        self.productService = productService
    }

    func load() async {
        state = .loading
        do {
            state = .loaded(try await productService.fetchProducts())
        } catch {
            state = .failed("Couldn't load products.")
        }
    }
}

@MainActor
@Observable
final class ProductViewModel {
    private(set) var state: LoadingState<[Product]> = .idle
    private let productService: ProductService

    init(productService: ProductService = LiveProductService()) {
        self.productService = productService
    }

    func load() async {
        state = .loading
        do {
            state = .loaded(try await productService.fetchProducts())
        } catch {
            state = .failed("Couldn't load products.")
        }
    }
}

The mock can now do three things: return products, throw an error, or wait to show the loading state:

nonisolated struct MockProductService: ProductService {
    var products: [Product] = []
    var error: Error? = nil
    var delay: Duration = .zero

    func fetchProducts() async throws -> [Product] {
        try await Task.sleep(for: delay)
        if let error { throw error }
        return products
    }
}

nonisolated struct MockProductService: ProductService {
    var products: [Product] = []
    var error: Error? = nil
    var delay: Duration = .zero

    func fetchProducts() async throws -> [Product] {
        try await Task.sleep(for: delay)
        if let error { throw error }
        return products
    }
}

That gives you a preview for every state of the screen, including the empty and error states that are usually hard to reproduce:

#Preview("Loaded") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(products: Product.samples)
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Empty") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(products: [])
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Error") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(error: URLError(.notConnectedToInternet))
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Loading") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(delay: .seconds(3600))
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Loaded") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(products: Product.samples)
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Empty") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(products: [])
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Error") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(error: URLError(.notConnectedToInternet))
    )
    ProductListView(viewModel: viewModel)
}

#Preview("Loading") {
    @Previewable @State var viewModel = ProductViewModel(
        productService: MockProductService(delay: .seconds(3600))
    )
    ProductListView(viewModel: viewModel)
}

And the tests check how the state changes for success and failure:

@MainActor
struct ProductViewModelTests {
    @Test func loadStoresProducts() async {
        let viewModel = ProductViewModel(
            productService: MockProductService(products: Product.samples)
        )
        await viewModel.load()
        #expect(viewModel.state == .loaded(Product.samples))
    }

    @Test func loadFailureSetsErrorState() async {
        let viewModel = ProductViewModel(
            productService: MockProductService(error: URLError(.timedOut))
        )
        await viewModel.load()
        #expect(viewModel.state == .failed("Couldn't load products."))
    }
}

@MainActor
struct ProductViewModelTests {
    @Test func loadStoresProducts() async {
        let viewModel = ProductViewModel(
            productService: MockProductService(products: Product.samples)
        )
        await viewModel.load()
        #expect(viewModel.state == .loaded(Product.samples))
    }

    @Test func loadFailureSetsErrorState() async {
        let viewModel = ProductViewModel(
            productService: MockProductService(error: URLError(.timedOut))
        )
        await viewModel.load()
        #expect(viewModel.state == .failed("Couldn't load products."))
    }
}

For #expect to compare states, LoadingState and Product need to be Equatable. No server, no network, no waiting: these tests give the same result every time.

Building Up: Sharing Networking Logic With an API Client

As your app grows, you’ll have more services: products, cart, orders. Each one builds a URL, sends a request, and decodes the JSON. The same few lines, repeated in every service. This is where services really pay off: logic that several of them need can move into one shared place.

For networking, that’s usually a small APIClient:

nonisolated struct APIClient {
    var baseURL = URL(string: "https://api.example.com")!

    @concurrent
    func get<T: Decodable>(_ path: String) async throws -> T {
        let url = baseURL.appending(path: path)
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(T.self, from: data)
    }
}

nonisolated struct APIClient {
    var baseURL = URL(string: "https://api.example.com")!

    @concurrent
    func get<T: Decodable>(_ path: String) async throws -> T {
        let url = baseURL.appending(path: path)
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(T.self, from: data)
    }
}

Every live service uses it, and only describes what it fetches:

nonisolated struct LiveProductService: ProductService {
    private let apiClient: APIClient

    init(apiClient: APIClient = APIClient()) {
        self.apiClient = apiClient
    }

    func fetchProducts() async throws -> [Product] {
        try await apiClient.get("products")
    }
}

nonisolated struct LiveCartService: CartService {
    private let apiClient: APIClient

    init(apiClient: APIClient = APIClient()) {
        self.apiClient = apiClient
    }

    func fetchCart() async throws -> Cart {
        try await apiClient.get("cart")
    }
}

nonisolated struct LiveProductService: ProductService {
    private let apiClient: APIClient

    init(apiClient: APIClient = APIClient()) {
        self.apiClient = apiClient
    }

    func fetchProducts() async throws -> [Product] {
        try await apiClient.get("products")
    }
}

nonisolated struct LiveCartService: CartService {
    private let apiClient: APIClient

    init(apiClient: APIClient = APIClient()) {
        self.apiClient = apiClient
    }

    func fetchCart() async throws -> Cart {
        try await apiClient.get("cart")
    }
}

The how now lives in one place. When you add authentication headers or better error handling, you change APIClient, and every service picks it up. Nothing changes for the view models: they still depend on ProductService and CartService, and previews and tests still use the same mocks.

How the Layers Fit Together, and the Names I Use

Now that you’ve seen services, here’s how all the layers fit together. A quick note on naming: words like “view model,” “service,” and “repository” mean different things to different people, and you’ll find other definitions in other articles and codebases. A common one: many people call something a “service” that holds UI state and the methods that change it. In my naming, that’s a view model. If it holds UI state and is @Observable so views can react to it, it’s the UI backing layer, whatever its name says. A service, in contrast, never holds UI state.

This is my take: the split and the names I’ve found most practical in SwiftUI apps.

The data flow: user taps → view calls a view model method → service works in the background → data comes back → view model updates UI state on the main actor → SwiftUI updates the view.

The dependencies point one way: views talk to view models, and view models talk to services. A view never calls a service directly. If it did, the view model’s state would no longer reflect what happened, and the data flow would be hard to follow.

Wrap-Up

We started with a practical goal: view models you can preview and test without touching UserDefaults or the network. The tool that got us there was the Dependency Inversion Principle. The view model depends on a protocol, the live service is the default, and previews and tests pass in a mock.

But testability wasn’t the only thing we gained along the way:

• Reusable components. Services can be shared by several view models, and an APIClient keeps networking logic in one place.
• Separation of concerns. The view model manages UI state, and the service handles the shared external dependency. Each has one job.
• Clear boundaries. Dependencies point one way, from view to view model to service, so you always know where code belongs and how data flows.

What’s next: in this post, every dependency came in through the initializer. In a real SwiftUI app, the next question is how dependencies get from the app’s entry point to every view model that needs them, especially shared ones. That’s where the SwiftUI environment comes in, and it’s the topic of SwiftUI Dependency Injection: Initializer, Environment, or Container?

Further Reading

• What Is a View Model in SwiftUI, Really?: the definition of the UI backing layer this post builds on.
• What Should Go in a View Model?: how to keep view models focused on one job.
• How I Architect SwiftUI Apps for Swift Concurrency – So the Compiler Stays Quiet: @MainActor, @concurrent, and Sendable: why view models live on the main actor and services run in the background.

Get the MVVM SwiftUI Cheat Sheet

The cheat sheet puts the whole system on a few pages: what goes in a view model, which view owns it, how to pass it down the tree, common mistakes, and code skeletons you can copy.

Get the free cheat sheet

The post Dependency Injection in Swift: Services, Protocols, and Testable View Models appeared first on swiftyplace.

In What Is a View Model in SwiftUI, Really?, we defined the view model’s concern: it owns UI state and is responsible for mutating that state properly and consistently.

But adding a view model doesn’t give you separation of concerns on its own. It just gives you another place to put code. And it’s a very convenient place: it’s already connected to the view, it already has state, so one more property or one more method is always the easiest option. Do that for a few months, and the mess that used to live in your view now lives in your view model. You haven’t separated anything. You’ve moved it.

It goes wrong in the other direction too. Logic that belongs in the view model stays in the view, and the view starts reaching in and changing the view model’s state piece by piece. Or UI code drifts into the view model, and you can no longer find what’s on screen by looking at the view.

So once you’ve decided you need a view model, the real question is where its boundaries are. In this post, I’ll show you how to define a view model’s job, what belongs inside it and what doesn’t, and how to spot code that sits in the wrong layer, with examples from a Markdown app, a product browser, a checkout flow, and an auth flow.

Define the Job: One View Model per Use Case

The first decision isn’t about individual properties. It’s about the boundary of the view model itself. Before you add anything, ask: what is the job of this view model? What is it responsible for? Once that’s clear, you give it all the state, the methods, and the dependencies it needs to do that job, and nothing more.

I think of this as scoping view models by use case: one coherent job around one set of state. The state and the methods that mutate it form a unit. They have a reason to live together. When you start adding a different set of state, with methods that have nothing to do with what’s already there, you’re mixing concerns. The view model loses its cohesion: the things inside it no longer have a logical reason to be in the same place.

Let’s go back to the Markdown app from the previous post. It has two clear use cases:

• Themes: all available themes, which one is selected, and creating, deleting, selecting, and saving them.
• Documents: the list of Markdown documents, and loading, creating, renaming, and deleting them.

So the app gets two view models, one for each:

@Observable class ThemeStore {
    private(set) var themes: [Theme] = []
    private(set) var selectedThemeID: Theme.ID?

    var selectedTheme: Theme? {
        themes.first { $0.id == selectedThemeID }
    }

    func createTheme(name: String, colors: ThemeColors) async { /* ... */ }
    func deleteTheme(_ theme: Theme) async { /* ... */ }
    func selectTheme(_ theme: Theme) async { /* ... */ }
}

@Observable class DocumentStore {
    private(set) var documents: [MarkdownDocument] = []

    func loadDocuments() async { /* ... */ }
    func createDocument(title: String) async { /* ... */ }
    func renameDocument(_ document: MarkdownDocument, to title: String) async { /* ... */ }
    func deleteDocument(_ document: MarkdownDocument) async { /* ... */ }
}

@Observable class ThemeStore {
    private(set) var themes: [Theme] = []
    private(set) var selectedThemeID: Theme.ID?

    var selectedTheme: Theme? {
        themes.first { $0.id == selectedThemeID }
    }

    func createTheme(name: String, colors: ThemeColors) async { /* ... */ }
    func deleteTheme(_ theme: Theme) async { /* ... */ }
    func selectTheme(_ theme: Theme) async { /* ... */ }
}

@Observable class DocumentStore {
    private(set) var documents: [MarkdownDocument] = []

    func loadDocuments() async { /* ... */ }
    func createDocument(title: String) async { /* ... */ }
    func renameDocument(_ document: MarkdownDocument, to title: String) async { /* ... */ }
    func deleteDocument(_ document: MarkdownDocument) async { /* ... */ }
}

Why not put both into one AppViewModel? Because themes and documents don’t change together. Deleting a document has nothing to do with which theme is selected. Creating a theme has nothing to do with the document list. They’re separate state, with separate mutations, so they live in separate view models.

And here’s the interesting part: both are used on the same screen. The document detail view shows the document’s content and renders it with the selected theme. That’s fine. A view can use more than one view model:

struct ContentView: View {
    @State private var themeStore = ThemeStore()  
    @State private var documentStore = DocumentStore()
    @State private var selectedFile: MarkdownFile? = nil
    
    var body: some View {
        NavigationSplitView {
            MarkdownFilesListView(documentStore: documentStore, 
                                  selection: $selectedFile)
        } detail: {
            if let selectedFile {
                MarkdownDetailView(themeStore: themeStore,
                                   markdown: selectedFile)
            } else {
                PlaceholderView()
            }
        }
        .task {
           await themeStore.load()
           await documentStore.load()
        }
    }
}

struct ContentView: View {
    @State private var themeStore = ThemeStore()  
    @State private var documentStore = DocumentStore()
    @State private var selectedFile: MarkdownFile? = nil
    
    var body: some View {
        NavigationSplitView {
            MarkdownFilesListView(documentStore: documentStore, 
                                  selection: $selectedFile)
        } detail: {
            if let selectedFile {
                MarkdownDetailView(themeStore: themeStore,
                                   markdown: selectedFile)
            } else {
                PlaceholderView()
            }
        }
        .task {
           await themeStore.load()
           await documentStore.load()
        }
    }
}

This is also why “one view model per screen” doesn’t work. The MarkdownDetailView screen needs state from two use cases. A single screen view model would either duplicate the theme state, or pull both use cases into one class. The use case decides the boundary, not the screen.

Avoid the God View Model

Think about it this way. If you avoid spaghetti code in your views, but then move everything into one giant view model, you haven’t solved anything. You’ve just moved the mess around. And it’s not a new problem. Whatever separation technique you use, there’s always a risk of creating something massive. UIKit had the infamous massive view controller. In SwiftUI, we can end up with massive views. And we can absolutely end up with massive view models too.

The opposite of a focused view model is the god view model: one huge class that holds everything. Themes, documents, settings, user info, sync status, all in one place, with dozens of methods and a file you scroll forever.

Nobody sets out to write one. It happens one feature at a time. The view model is already there and already connected to the views, so adding “just one more thing” is the easiest option. Repeat that for a few months, and you have a god view model.

Here’s why it hurts:

• Hard to understand: you can’t tell what any part of it is responsible for, or which methods touch which state.
• Changes ripple: a change for one feature can break another, because they share the same class and sometimes the same state.
• Everything depends on everything: every view that uses it is connected to all of it, even the parts it doesn’t need.
• Hard to test: to test one behavior, you have to set up the whole thing.
• Merge conflicts: if everyone on the team works in the same file, you’ll be resolving conflicts constantly.

The fix is the same idea as above: split by use case. Not by line count, and not by screen. If a group of state and the methods that change it form their own job, they get their own view model.

UI State: Collect State That Changes Together

Once you know the use case, the same idea works on a smaller scale. Inside a view model, group the state that changes together.

Loading is the classic example. When DocumentStore loads documents, three pieces of state are involved:

private(set) var isLoading = false
private(set) var errorMessage: String?
private(set) var documents: [MarkdownDocument] = []

private(set) var isLoading = false
private(set) var errorMessage: String?
private(set) var documents: [MarkdownDocument] = []

These always change together. Start loading: set isLoading, clear the error. Success: store the documents, reset isLoading. Failure: set the error, reset isLoading. Every mutation has to remember to update all three correctly. Forget one, and you’re in a state that shouldn’t exist, like a spinner and an error message at the same time.

So at the very least, keep these properties together and change them together in one place. Even better, model them as one value with an enum:

enum LoadingState<Value> {
    case idle
    case loading
    case loaded(Value)
    case failed(String)
}

private(set) var state: LoadingState<[MarkdownDocument]> = .idle

enum LoadingState<Value> {
    case idle
    case loading
    case loaded(Value)
    case failed(String)
}

private(set) var state: LoadingState<[MarkdownDocument]> = .idle

Now only valid states are possible, and every transition is a single assignment. The same idea applies elsewhere: form fields belong together with their validation errors, and a selection belongs together with the list it refers to.

What Belongs in a View Model

With the boundaries in place, here’s what actually goes inside.

UI state. The data your views need to render: the list of documents, the selected theme, the loading state, form input.

Derived state. Values that can be calculated from other state should be computed properties, not stored copies. selectedTheme is computed from themes and selectedThemeID. If you stored it as a separate property, you’d have to update it every time either of those changes, and sooner or later you’d forget. Computed properties have nothing to keep in sync. Other examples: canSubmit in a form, formattedTotal in a cart.

Mutations. The methods responsible for changing the state properly and consistently. Creating a theme means adding it, selecting it, and saving, every time, in that order. That sequence lives in one method, so no view has to know about it.

Display formatting. Turning raw data into something ready to show: a formatted price, a relative date, a title combined from several fields. This is about what to show. How it looks is still up to the view.

Gatekeeping. Answering “is this action allowed right now?” as state, for example canSubmit or canDeleteTheme. The view model decides whether something is allowed. The view decides that “not allowed” means a disabled button.

Dependencies. The services the view model needs to do its job, like the file service for ThemeStore or a networking service for loading products. The view model calls them. It doesn’t do their work itself.

What Doesn’t Belong (and Where It Goes)

Just as important is what stays out. Each of these has a better home. This is my personal recommendation that is clear and relatively straightforward to follow.

Layout, styling, and any UI code → the view. Fonts, colors, spacing, animations, which view to show for which state. The view model never says “show a red label here,” and it never contains view code itself. More on that in the next section.

Data structures and intrinsic rules → the model. A Theme struct, a MarkdownDocument, the rule for what makes a valid email address or a maximum cart quantity. These rules belong to the data itself, no matter which view model uses them.

State from another use case → another view model. Even if a view needs it. The document detail view needs the selected theme, but that doesn’t mean the theme belongs in DocumentStore. The view simply uses both.

Services: The Layer Behind the View Model

A view model’s job is managing UI state. But to do that job, it often needs things outside your own code: the network, the file system, UserDefaults, the Keychain, HealthKit. These are shared external dependencies, and working with them is a different job. So that work goes into a service.

A service is a helper worker:

• Stateless: plain functions that do one kind of work, like fetching products or saving themes.
• Off the main actor: heavy work like requests and decoding doesn’t block the UI.
• Reusable: the same API call can serve several view models, like the cart and checkout.
• Replaceable: the view model depends on a protocol, so you can inject a mock for previews and tests.

The view model keeps the state and decides when to call the service. The service does the work and returns the data. I go deeper into services, repositories, and dependency injection in a separate blog post.

Navigation: Coordinators for Presentation State

Simple navigation stays in the view: the user taps a product, and a detail view is pushed. But sometimes logic decides where to go.

Say a shopping app checks for discount offers when the user opens the shop. If the server returns an offer, a sheet should open. That’s three concerns at once:

• Fetching the offers is networking → a service.
• Holding the offers is UI state → the view model.
• Opening the sheet is presentation state → neither of them.

Presentation state gets its own owner: a coordinator. It’s an @Observable class that owns the navigation path and which sheet is shown. It holds only state, never view code. The view model decides that the offer should be shown and tells the coordinator; the view maps the coordinator’s state to the actual sheet.

Coordinators pay off in larger, more complex apps, especially when several developers work on different features. And there, they should always be nested: an app coordinator for the top-level flows, and a child coordinator per feature, like shop or checkout. A single coordinator for the whole app turns into the same god object we just got rid of: it knows every screen, every feature depends on it, and every change touches it. With nested coordinators, each flow owns only its own navigation. The concerns stay separated, dependencies stay local, and features are easy to split into modules.

This pattern is often called MVVM-C, and there are different ways to implement it. I cover how I use it in detail in another blog post: Navigation with Coordinators.

Going Too Far: UI Code in a View Model

It’s possible to swing too far in the other direction, and move things into the view model that clearly belong in the view. The most extreme version is putting actual view code into it.

Imagine an AuthManager with three states: loading, an error, or a logged-in user. Now we add a @ViewBuilder function that returns the screen for each state:

@MainActor
@Observable
final class AuthManager {
    private(set) var state: AuthState = .loading

    @ViewBuilder
    func screenComponent() -> some View {
        switch state {
        case .loading: ProgressView()
        case .failed(let message): Text(message)
        case .loggedIn(let user): Text("Welcome, (user.name)")
        }
    }
}

struct HomeView: View {
    let authManager: AuthManager

    var body: some View {
        authManager.screenComponent()
            .padding()
    }
}

@MainActor
@Observable
final class AuthManager {
    private(set) var state: AuthState = .loading

    @ViewBuilder
    func screenComponent() -> some View {
        switch state {
        case .loading: ProgressView()
        case .failed(let message): Text(message)
        case .loggedIn(let user): Text("Welcome, (user.name)")
        }
    }
}

struct HomeView: View {
    let authManager: AuthManager

    var body: some View {
        authManager.screenComponent()
            .padding()
    }
}

This works. But the view is now “unemployed.” It’s just an empty container that does nothing. And that causes real problems:

• You can’t find your UI. Open HomeView, and you can’t tell what’s on screen. If someone asks you to make the welcome text bold, it’s not there. You jump to AuthManager, look through the cases, figure out which one to change, and bounce between files for a one-line UI tweak.
• Reusability drops. Before, the coupling went one way: the view knew about the view model. Now the view model also knows how the UI looks. If you want the same auth logic with a different design somewhere else, you can’t, because the UI is baked into the observable.
• Testing gets hard. Testing a normal view model is easy: is the state loading, yes or no? Testing a function that returns some View means dealing with SwiftUI’s opaque types, a deeply nested ConditionalContent type that’s hard to assert on, and possibly spinning up SwiftUI just to run a unit test.

So here’s my rule that’s simple enough to actually follow: no UI code in your view models. No some View, no @ViewBuilder, nothing that describes how to draw pixels.

That gives each side a clear job:

• The view maps state to pixels. It decides what to show for a given state and how to style it.
• The view model manages what state the app is in. It handles the data, the logic, the service calls, and the state transitions. If a request fails with a “forbidden” error, the view model stores that error. Whether it shows up as an alert, an inline message, or a banner is the view’s decision.

With that rule, the switch moves back where it belongs:

struct HomeView: View {
    let authManager: AuthManager

    var body: some View {
        switch authManager.state {
        case .loading:
            ProgressView()
        case .failed(let message):
            Text(message).foregroundStyle(.red)
        case .loggedIn(let user):
            Text("Welcome, (user.name)").font(.title)
        }
    }
}

struct HomeView: View {
    let authManager: AuthManager

    var body: some View {
        switch authManager.state {
        case .loading:
            ProgressView()
        case .failed(let message):
            Text(message).foregroundStyle(.red)
        case .loggedIn(let user):
            Text("Welcome, (user.name)").font(.title)
        }
    }
}

Now everything you see on screen is in the view, and AuthManager is back to being a plain class you can test with simple assertions.

Example: What Stays Out of a Product Browser

Let’s put this into practice with a product browser. You can search through a list of products and apply filters to narrow down the results. There are network requests, filtering logic, loading states, and error handling, so all of that moves into a ProductViewModel.

First, define the job. This view model fetches products, updates the list when the search or filter changes, manages the loading state, and keeps an error message the UI can show. To do that job, it needs the search query, the selected filter, the methods that perform the fetch, and the service that does the network request in the background:

@MainActor
@Observable
final class ProductViewModel {
    var searchQuery = ""
    var selectedFilter: ProductFilter = .all
    private(set) var state: LoadingState<[Product]> = .idle

    private let productService: ProductService

    func fetchProducts() async { /* ... */ }
}

@MainActor
@Observable
final class ProductViewModel {
    var searchQuery = ""
    var selectedFilter: ProductFilter = .all
    private(set) var state: LoadingState<[Product]> = .idle

    private let productService: ProductService

    func fetchProducts() async { /* ... */ }
}

That’s it. Now the interesting part is what I deliberately kept in the view:

struct ProductBrowserView: View {
    @State private var viewModel = ProductViewModel()
    @State private var isFilterSheetShown = false
    @State private var isGridLayout = true
    @State private var path = NavigationPath()

    // ...
}

struct ProductBrowserView: View {
    @State private var viewModel = ProductViewModel()
    @State private var isFilterSheetShown = false
    @State private var isGridLayout = true
    @State private var path = NavigationPath()

    // ...
}

• Whether the filter sheet is shown. Does the view model need to know a sheet is open to fetch products? No. It cares about which filter is selected, not whether the UI for choosing it is visible.
• Grid or list layout. A display preference. It has nothing to do with fetching or managing products.
• The navigation path. Does the view model need to know the user tapped through to a detail screen? No. If the detail screen needs more data, that’s a different job, with a different lifetime, and only needed once the user is actually there.

All three are about what’s currently on screen: display state, navigation state, interaction state. They have a different concern than the view model’s job, so they stay in the view.

Example: When Logic Should Move In

The opposite happens too: code that lives in the view but belongs to the view model’s job.

Say a shopping app has a checkout flow. A CheckoutViewModel loads the final cart so the user can review it: the items, subtotal, discount, shipping, taxes, and total. Its job is to manage those totals.

Then a new feature request comes in: the user should be able to enter a promo code. In a first version, the promo code logic lives in the view. To make that work, the view model’s totals have to be settable from outside:

@MainActor
@Observable
final class CheckoutViewModel {
    var subtotal: Decimal = 0
    var discount: Decimal = 0
    var shipping: Decimal = 0
    var taxes: Decimal = 0
    var total: Decimal = 0
    // ...
}

@MainActor
@Observable
final class CheckoutViewModel {
    var subtotal: Decimal = 0
    var discount: Decimal = 0
    var shipping: Decimal = 0
    var taxes: Decimal = 0
    var total: Decimal = 0
    // ...
}

And the view does the work:

struct CheckoutView: View {
    var checkoutViewModel: CheckoutViewModel
    @State private var promoCode = ""
    @State private var promoError: String?

    var body: some View {
        Form {
            CartSummarySection(checkoutViewModel: checkoutViewModel)
            Section("Promo Code") {
                TextField("Enter code", text: $promoCode)
                if let promoError {
                    Text(promoError).foregroundStyle(.red)
                }
                Button("Apply") { applyPromoCode() }
            }
        }
    }

    // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Business logic in the view
    private func applyPromoCode() {
        guard promoCode == promoCode.uppercased() else {
            promoError = "Promo codes use capital letters only."
            return
        }

        if promoCode == "SAVE10" {
            // Reads subtotal, changes discount...
            checkoutViewModel.discount = checkoutViewModel.subtotal * 0.1
            // ...then reads three more values to change total
            checkoutViewModel.total = checkoutViewModel.subtotal
                - checkoutViewModel.discount
                + checkoutViewModel.shipping
                + checkoutViewModel.taxes // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> taxes were calculated before the discount
            promoError = nil
        } else {
            promoError = "This code isn't valid."
        }
    }
}

struct CheckoutView: View {
    var checkoutViewModel: CheckoutViewModel
    @State private var promoCode = ""
    @State private var promoError: String?

    var body: some View {
        Form {
            CartSummarySection(checkoutViewModel: checkoutViewModel)
            Section("Promo Code") {
                TextField("Enter code", text: $promoCode)
                if let promoError {
                    Text(promoError).foregroundStyle(.red)
                }
                Button("Apply") { applyPromoCode() }
            }
        }
    }

    // ⚠ Business logic in the view
    private func applyPromoCode() {
        guard promoCode == promoCode.uppercased() else {
            promoError = "Promo codes use capital letters only."
            return
        }

        if promoCode == "SAVE10" {
            // Reads subtotal, changes discount...
            checkoutViewModel.discount = checkoutViewModel.subtotal * 0.1
            // ...then reads three more values to change total
            checkoutViewModel.total = checkoutViewModel.subtotal
                - checkoutViewModel.discount
                + checkoutViewModel.shipping
                + checkoutViewModel.taxes // ⚠ taxes were calculated before the discount
            promoError = nil
        } else {
            promoError = "This code isn't valid."
        }
    }
}

Look at what applyPromoCode() does with the view model. It reads subtotal, changes discount, then reads subtotal, discount, shipping, and taxes again to change total. The view has to know how the totals depend on each other, and it gets it wrong: the taxes were calculated on the old subtotal, so the user sees a wrong total. And the valid codes are hardcoded in the view, when only the server knows which codes exist.

That’s the code smell to watch for: if your view reads one property from the view model, changes another, then reads a third, it’s working with the view model’s internals. That’s a sign the view is handling a responsibility that belongs to the view model.

And look at the job again: managing the totals. Applying a promo code is part of that job. So it moves in, behind a single method. The server validates the code and returns the recalculated cart, and the view model updates all totals together:

@MainActor
@Observable
final class CheckoutViewModel {
    private(set) var items: [CartItem] = []
    private(set) var subtotal: Decimal = 0
    private(set) var discount: Decimal = 0
    private(set) var shipping: Decimal = 0
    private(set) var taxes: Decimal = 0
    private(set) var total: Decimal = 0

    private(set) var isApplyingPromoCode = false
    private(set) var promoCodeError: String?

    private let cartService: CartService

    init(cartService: CartService) {
        self.cartService = cartService
    }

    func loadCart() async {
        // Fetch the final cart and call update(with:)
    }

    func applyPromoCode(_ code: String) async {
        isApplyingPromoCode = true
        promoCodeError = nil
        defer { isApplyingPromoCode = false }

        do {
            // The server validates the code and returns recalculated totals
            let cart = try await cartService.applyPromoCode(code)
            update(with: cart)
        } catch {
            promoCodeError = "This promo code isn't valid."
        }
    }

    // All totals change together, in one place
    private func update(with cart: Cart) {
        items = cart.items
        subtotal = cart.subtotal
        discount = cart.discount
        shipping = cart.shipping
        taxes = cart.taxes
        total = cart.total
    }
}

@MainActor
@Observable
final class CheckoutViewModel {
    private(set) var items: [CartItem] = []
    private(set) var subtotal: Decimal = 0
    private(set) var discount: Decimal = 0
    private(set) var shipping: Decimal = 0
    private(set) var taxes: Decimal = 0
    private(set) var total: Decimal = 0

    private(set) var isApplyingPromoCode = false
    private(set) var promoCodeError: String?

    private let cartService: CartService

    init(cartService: CartService) {
        self.cartService = cartService
    }

    func loadCart() async {
        // Fetch the final cart and call update(with:)
    }

    func applyPromoCode(_ code: String) async {
        isApplyingPromoCode = true
        promoCodeError = nil
        defer { isApplyingPromoCode = false }

        do {
            // The server validates the code and returns recalculated totals
            let cart = try await cartService.applyPromoCode(code)
            update(with: cart)
        } catch {
            promoCodeError = "This promo code isn't valid."
        }
    }

    // All totals change together, in one place
    private func update(with cart: Cart) {
        items = cart.items
        subtotal = cart.subtotal
        discount = cart.discount
        shipping = cart.shipping
        taxes = cart.taxes
        total = cart.total
    }
}

The totals are private(set) again, so no view can change one without the others. The view just hands off the code and shows the state:

Button("Apply Promo Code") {
    Task { await checkoutViewModel.applyPromoCode(promoCode) }
}
.disabled(checkoutViewModel.isApplyingPromoCode)

Button("Apply Promo Code") {
    Task { await checkoutViewModel.applyPromoCode(promoCode) }
}
.disabled(checkoutViewModel.isApplyingPromoCode)

Notice that promoCode stays in the view as @State. It’s plain text input that only this view uses, until the user taps Apply. What moved is the logic that changes the totals.

And there’s a bonus: if promo codes can be applied in several places in the app, that logic now lives in one place instead of being duplicated across views.

A Quick Checklist

When you’re about to add something to a view model, run through these questions:

1. What’s the job of this view model? Does the new code belong to that job? If it’s part of a different job, it belongs in a different view model.
2. Does it own or change UI state? If not, move it to the view, the model, or a service.
3. Is it UI code? No some View, no @ViewBuilder. That stays in the view.
4. Does it change together with the rest of the state here? If yes, keep it close, and update it in the same place.
5. Can it be derived instead of stored? Then make it a computed property.
6. Are several related properties really one state? Then consider modeling them as one enum.
7. Is the view reaching into several view model properties to make one change? Then that logic belongs in the view model, behind a single method.

Wrapping Up

A good view model is focused. It has one clear job, holds the state that changes together, and is responsible for mutating that state properly and consistently. Everything else has a better home: UI code and display state in the view, rules in the model, heavy work in services, and other jobs in their own view models.

This isn’t a decision you make once. As your app grows and new features arrive, keep asking whether new code belongs to an existing view model’s job. Sometimes logic needs to move out, like the filter sheet in the product browser. Sometimes it needs to move in, like the promo code in checkout. The line stays the same: the view model manages state and logic, and the view maps that state to what the user sees.

Get the MVVM SwiftUI Cheat Sheet

The cheat sheet puts the whole system on a few pages: what goes in a view model, which view owns it, how to pass it down the tree, common mistakes, and code skeletons you can copy.

Get the free cheat sheet

Further Reading

• What Is a View Model in SwiftUI, Really?
• When to Use a View Model in SwiftUI (and When It’s Overkill)

The post What Should Go in a View Model in SwiftUI? appeared first on swiftyplace.

That’s a powerful tool. But it’s also an extra file and an extra layer of abstraction. So the question isn’t “should I always use a view model?” The question is: when do the benefits outweigh the cost?

In this post, I’ll walk you through four examples. I’ll show simple and complex versions so you can see exactly where a view model starts to make sense and where it becomes an overblown, unnecessary thing that gets in your way.

The Cost and the Benefit of View Model in MVVM

Before we get into the examples, let’s be clear about what we’re weighing.

The cost of a view model:

• Another file and another type to maintain
• Your code is spread over two places
• To find out what a view shows, you sometimes have to jump to another file
• More objects for SwiftUI to manage

The benefit of a view model:

• Views stay simple and focused on UI
• State mutations live in one place and happen the same way every time
• Several views can share the same state and the same methods to change it
• State can outlive a single view

If a view model doesn’t deliver any of those benefits, you’re only paying the cost. Let’s see what that looks like in practice.

Example 1: From a Color Picker to a Theme Editor

The Simple Version

The first example is a simple document app. Each document is a short text snippet with its own color, and when you open a document, that color is used for the background. At the bottom, there’s a color picker for switching between colors.

Say you’re building an early MVP and want to keep things easy. You might just hardcode the available colors:

struct ColorPickerView: View {
    @Binding var selectedColor: Color

    let colors: [Color] = [.red, .orange, .yellow, .green, .blue, .purple]

    var body: some View {
        ScrollView(.horizontal, showsIndicators: false) {
            HStack {
                ForEach(colors, id: .self) { color in
                    Circle()
                        .fill(color)
                        .frame(width: 32, height: 32)
                        .onTapGesture { selectedColor = color }
                }
            }
        }
    }
}

struct ColorPickerView: View {
    @Binding var selectedColor: Color

    let colors: [Color] = [.red, .orange, .yellow, .green, .blue, .purple]

    var body: some View {
        ScrollView(.horizontal, showsIndicators: false) {
            HStack {
                ForEach(colors, id: .self) { color in
                    Circle()
                        .fill(color)
                        .frame(width: 32, height: 32)
                        .onTapGesture { selectedColor = color }
                }
            }
        }
    }
}

The view has an array of colors and a horizontal scroll view that iterates over them. Tap a color, and it becomes the selected color through the binding. This view is almost entirely UI. There’s no logic here.

So what would a view model look like? The only thing we could move into it is the array of colors:

@Observable
class ColorPickerStore {
    let colors: [Color] = [.red, .orange, .yellow, .green, .blue, .purple]
}

@Observable
class ColorPickerStore {
    let colors: [Color] = [.red, .orange, .yellow, .green, .blue, .purple]
}

That’s it: an observable class holding a hardcoded array. It doesn’t own any state that changes, and it doesn’t take any work off the view. It just adds an extra layer and splits the code across two files. This is definitely overkill. I would stick with the view-only solution here.

When the Requirements Change

Now let’s keep working on the app. Instead of using color just for the background, I want to render Markdown, with colors for the headings, the code blocks, and the document background. I also want users to create their own themes with custom colors and fonts, and those themes need to be saved to disk and loaded again the next time.

The theme picker view itself still doesn’t have much logic. It’s mostly UI code: show this list, show this button, use this styling. The real work happens in a store (aka the view model):

@MainActor
@Observable
final class ThemeStore {
    private(set) var themes: [Theme] = []
    private(set) var selectedThemeID: Theme.ID?

    var selectedTheme: Theme? {
        themes.first { $0.id == selectedThemeID }
    }

    private let fileService: ThemeFileService

    init(fileService: ThemeFileService = ThemeFileService()) {
        self.fileService = fileService
    }

    func loadThemes() async {
        themes = (try? await fileService.load()) ?? Theme.defaults
    }

    func createTheme(name: String, colors: ThemeColors) async {
        let theme = Theme(name: name, colors: colors)
        themes.append(theme)
        selectedThemeID = theme.id
        await save()
    }

    func deleteTheme(_ theme: Theme) async {
        themes.removeAll { $0.id == theme.id }
        await save()
    }

    func selectTheme(_ theme: Theme) async {
        selectedThemeID = theme.id
        await save()
    }

    private func save() async {
        try? await fileService.save(themes)
    }
}

@MainActor
@Observable
final class ThemeStore {
    private(set) var themes: [Theme] = []
    private(set) var selectedThemeID: Theme.ID?

    var selectedTheme: Theme? {
        themes.first { $0.id == selectedThemeID }
    }

    private let fileService: ThemeFileService

    init(fileService: ThemeFileService = ThemeFileService()) {
        self.fileService = fileService
    }

    func loadThemes() async {
        themes = (try? await fileService.load()) ?? Theme.defaults
    }

    func createTheme(name: String, colors: ThemeColors) async {
        let theme = Theme(name: name, colors: colors)
        themes.append(theme)
        selectedThemeID = theme.id
        await save()
    }

    func deleteTheme(_ theme: Theme) async {
        themes.removeAll { $0.id == theme.id }
        await save()
    }

    func selectTheme(_ theme: Theme) async {
        selectedThemeID = theme.id
        await save()
    }

    private func save() async {
        try? await fileService.save(themes)
    }
}

Now there’s real state to manage: all the themes and which one is selected. And there are real mutations. When I create a theme, it needs to be added, selected, and saved. When I delete one, the UI state has to update and the change has to be saved for next time. Because every mutation goes through the store, each one ends with the same save() call, and nothing gets forgotten.

Notice that the store doesn’t do the file handling itself. Encoding and decoding all the themes into a JSON file in the documents directory is quite a bit of code, and it has nothing to do with UI state. So that work goes to a separate service that runs in the background. That keeps the store small and focused. I cover this layer in more detail in another post about Services and Repositories.

Where the Store Lives

There’s one more reason the store pays off here. The themes are created and managed in the theme picker sheet, but the selected theme is also needed in the view that renders every Markdown file.

If the store lived inside the sheet or the detail view, it would be created and thrown away every time I navigate back and forth, and the themes would have to be reloaded each time. So I place it at the app’s top level, where it lives as long as the themes are needed, and pass it to every view that uses it.

struct ContentView: View {
    // owned high in the view tree, 
    // lifes for the duration of the app
    @State private var themeStore = ThemeStore()  
    @State private var markdownFileStore = MarkdownFileStore()
    @State private var selectedFile: MarkdownFile? = nil
    
    var body: some View {
        NavigationSplitView {
            MarkdownFilesListView(markdownFileStore: markdownFileStore, 
                                  selection: $selectedFile)
        } detail: {
            if let selectedFile {
                MarkdownDetailView(themeStore: themeStore,
                                   markdown: selectedFile)
            } else {
                PlaceholderView()
            }
        }
        .task {
           await themeStore.load()
           await markdownFileStore.load()
        }
    }
}

struct ContentView: View {
    // owned high in the view tree, 
    // lifes for the duration of the app
    @State private var themeStore = ThemeStore()  
    @State private var markdownFileStore = MarkdownFileStore()
    @State private var selectedFile: MarkdownFile? = nil
    
    var body: some View {
        NavigationSplitView {
            MarkdownFilesListView(markdownFileStore: markdownFileStore, 
                                  selection: $selectedFile)
        } detail: {
            if let selectedFile {
                MarkdownDetailView(themeStore: themeStore,
                                   markdown: selectedFile)
            } else {
                PlaceholderView()
            }
        }
        .task {
           await themeStore.load()
           await markdownFileStore.load()
        }
    }
}

And because all the logic is in one neat package, I can move it wherever I need it later. If the loading code were scattered across views, every change would mean moving a lot more code around.

Takeaway: same feature, different answer. The simple color picker had nothing to manage. The theme editor has state that changes, mutations that need to happen consistently, and several views that need the same state. That’s exactly when a view model earns its place.

Example 2: The About View

The second example is an About screen. It shows the app name, the version number, and a short “About us” text. These are plain strings that I just need to display.

struct AboutView: View {
    let appName = "Markdown Notes"
    let version = "1.2.0"
    let aboutText = "Made with love by a small team."

    var body: some View {
        VStack(spacing: 8) {
            Text(appName).font(.title)
            Text("Version (version)").foregroundStyle(.secondary)
            Text(aboutText)
        }
    }
}

struct AboutView: View {
    let appName = "Markdown Notes"
    let version = "1.2.0"
    let aboutText = "Made with love by a small team."

    var body: some View {
        VStack(spacing: 8) {
            Text(appName).font(.title)
            Text("Version (version)").foregroundStyle(.secondary)
            Text(aboutText)
        }
    }
}

Do I need a view model for this? There’s no logic and nothing to do. I could keep these values as properties, like above, or write them straight into the view body. Both are simple enough.

If I introduced a view model, I’d be moving these strings into a separate layer and adding abstraction for no reason. And it actively hurts you. One of the drawbacks of too much abstraction is that you have to jump around in your code. If I want to know what a label shows, I have to go to another type, look it up there, and come back.

There’s also nothing to manage. These are constants. Nothing mutates during runtime, so there’s no reason for a class, and certainly no reason for @Observable.

Takeaway: if nothing changes, there’s nothing for a view model to manage.

Example 3: A Custom Button Component

The third example is a reusable button. Teams often want preset configurations for buttons: a trash can icon paired with red, a certain padding, a certain style.

The View Model Version

What happens if you use a view model for this configuration? Every button creates and owns its own view model, with properties for the title, color, icon, and action:

@Observable
class CustomButtonViewModel {
    var title: String
    var color: Color
    var icon: String
    var action: () -> Void
    // ...
}

CustomButton(viewModel: CustomButtonViewModel(
    title: "Delete", color: .red, icon: "trash", action: deleteItem
))

@Observable
class CustomButtonViewModel {
    var title: String
    var color: Color
    var icon: String
    var action: () -> Void
    // ...
}

CustomButton(viewModel: CustomButtonViewModel(
    title: "Delete", color: .red, icon: "trash", action: deleteItem
))

This is overkill. There’s no state that changes over time and no logic to manage. I’m just adding another layer with more code.

And it gets worse:

• More work for SwiftUI: every button now has an extra object that has to be allocated and tracked.
• A second source of truth: the button owns its view model, so if you pass a new configuration for the same button, it won’t update.
• More verbose usage: creating a view model just to show a button is a lot of ceremony.

The View-Only Version

Compare that to the simple version, where the button just has normal properties:

CustomButton(title: "Delete", color: .red, icon: "trash", action: deleteItem)

CustomButton(title: "Delete", color: .red, icon: "trash", action: deleteItem)

This is the simplest, most SwiftUI-like version, and it does pretty much everything you need.

For Design Systems: A Styling Struct

Now, what if you really want the same button with different preset stylings? Maybe you’re working with a strict design system that you built together with a UI designer. One clean way to handle this is a struct that bundles the styling properties together:

struct ButtonStyling {
    let foregroundColor: Color
    let backgroundColor: Color
    let icon: String?
    let font: Font

    init(foregroundColor: Color, backgroundColor: Color,
         icon: String? = nil, font: Font = .body) {
        self.foregroundColor = foregroundColor
        self.backgroundColor = backgroundColor
        self.icon = icon
        self.font = font
    }

    // presets
    static let primary = ButtonStyling(foregroundColor: .white, backgroundColor: .blue)
    static let destructive = ButtonStyling(foregroundColor: .white, backgroundColor: .red, icon: "trash")
}

struct ButtonStyling {
    let foregroundColor: Color
    let backgroundColor: Color
    let icon: String?
    let font: Font

    init(foregroundColor: Color, backgroundColor: Color,
         icon: String? = nil, font: Font = .body) {
        self.foregroundColor = foregroundColor
        self.backgroundColor = backgroundColor
        self.icon = icon
        self.font = font
    }

    // presets
    static let primary = ButtonStyling(foregroundColor: .white, backgroundColor: .blue)
    static let destructive = ButtonStyling(foregroundColor: .white, backgroundColor: .red, icon: "trash")
}

These are all constants, because you pass them in once. The initializer gives you sensible defaults, and static presets cover the common cases. Using it stays just as easy:

CustomButton(title: "Continue", style: .primary) { next() }
CustomButton(title: "Delete", style: .destructive) { deleteItem() }

CustomButton(title: "Continue", style: .primary) { next() }
CustomButton(title: "Delete", style: .destructive) { deleteItem() }

The overhead is small. Instead of passing every property individually, you bundle them into a plain struct.

Takeaway: configuration is not state (that changes during runtime). Reach for plain properties or a struct, not an observable.

Example 4: From Login to Account Creation

The Simple Version

For the last example, let’s say we start with a basic login view: two state properties, two text fields, and a login button. There’s no real logic yet, and the view is very simple. No view model needed. I can keep working on it since it’s still in the early stages of development.

struct LoginView: View {
    @State private var email = ""
    @State private var password = ""

    var body: some View {
        VStack {
            TextField("Email", text: $email)
            SecureField("Password", text: $password)
            Button("Login") {
                if !email.isEmpty && !password.isEmpty {
                    print("Try login...")
                }
            }
        }
        .padding()
        .textFieldStyle(.roundedBorder)
    }
}

struct LoginView: View {
    @State private var email = ""
    @State private var password = ""

    var body: some View {
        VStack {
            TextField("Email", text: $email)
            SecureField("Password", text: $password)
            Button("Login") {
                if !email.isEmpty && !password.isEmpty {
                    print("Try login...")
                }
            }
        }
        .padding()
        .textFieldStyle(.roundedBorder)
    }
}

When the Requirements Change

At some point, you have to add a Create Account feature. Now you need:

• Live validation, showing error messages while the user types their email
• Password strength feedback, with a red, yellow, or green indicator
• Loading states, because pressing Create Account sends an API request. While it’s running, the button has to be disabled so the user can’t create the same account twice. Otherwise the first request succeeds and the second fails with “email already taken.”
• Proper error handling, so the user always knows what’s going on

That’s a lot more logic than the simple login view. Especially once network requests are involved, a small view easily grows and grows until it becomes unmanageable.

This is where a view model becomes a state engine. It manages all the state and the mutations, so the view can stay simple:

@MainActor
@Observable
final class AuthViewModel {
    var email = ""
    var password = ""
    private(set) var isLoading = false
    private(set) var errorMessage: String?
    private(set) var isLoggedIn = false

    private let authService: AuthService

    init(authService: AuthService = AuthService()) {
        self.authService = authService
    }

    var emailError: String? { /* live email validation */ }
    var passwordStrength: PasswordStrength { /* weak, medium, strong */ }

    var canSubmit: Bool {
        emailError == nil && passwordStrength != .weak && !isLoading
    }

    func createAccount() async {
        await perform { try await self.authService.createAccount(email: self.email, password: self.password) }
    }

    func login() async {
        await perform { try await self.authService.login(email: self.email, password: self.password) }
    }

    // One place that runs every auth request the same way
    private func perform(_ request: () async throws -> Void) async {
        isLoading = true
        errorMessage = nil
        defer { isLoading = false }
        do {
            try await request()
            isLoggedIn = true
        } catch {
            errorMessage = error.localizedDescription
        }
    }
}

@MainActor
@Observable
final class AuthViewModel {
    var email = ""
    var password = ""
    private(set) var isLoading = false
    private(set) var errorMessage: String?
    private(set) var isLoggedIn = false

    private let authService: AuthService

    init(authService: AuthService = AuthService()) {
        self.authService = authService
    }

    var emailError: String? { /* live email validation */ }
    var passwordStrength: PasswordStrength { /* weak, medium, strong */ }

    var canSubmit: Bool {
        emailError == nil && passwordStrength != .weak && !isLoading
    }

    func createAccount() async {
        await perform { try await self.authService.createAccount(email: self.email, password: self.password) }
    }

    func login() async {
        await perform { try await self.authService.login(email: self.email, password: self.password) }
    }

    // One place that runs every auth request the same way
    private func perform(_ request: () async throws -> Void) async {
        isLoading = true
        errorMessage = nil
        defer { isLoading = false }
        do {
            try await request()
            isLoggedIn = true
        } catch {
            errorMessage = error.localizedDescription
        }
    }
}

This is a shortened version. In a real app, the validation alone adds up to a lot more code. But even with all of that, the view stays small. It manages its text fields, builds the button, and calls the view model. Disabling the button is one line using canSubmit.

Sharing State Mutations Across Views

There’s another big advantage once this logic lives in a view model: it’s no longer tied to a single view.

The create account screen isn’t the only place that deals with authentication. I also have a login screen, and maybe a sign-in prompt somewhere else in the app with a completely different look. All of these views work with the same auth state: whether a request is loading, whether there’s an error, whether the user is logged in. And login state is usually something you need app-wide anyway.

Instead of writing that logic again in every view, I can simply pass the view model along and call its methods:

struct LoginView: View {
    @Bindable var auth: AuthViewModel

    var body: some View {
        VStack {
            TextField("Email", text: $auth.email)
            SecureField("Password", text: $auth.password)

            Button("Log In") {
                Task { await auth.login() }
            }
            .disabled(!auth.canSubmit)

            if let error = auth.errorMessage {
                Text(error).foregroundStyle(.red)
            }
        }
    }
}

struct CreateAccountView: View {
    @Bindable var auth: AuthViewModel

    var body: some View {
        // Different layout, same view model
        Button("Create Account") {
            Task { await auth.createAccount() }
        }
        .disabled(!auth.canSubmit)
    }
}

struct LoginView: View {
    @Bindable var auth: AuthViewModel

    var body: some View {
        VStack {
            TextField("Email", text: $auth.email)
            SecureField("Password", text: $auth.password)

            Button("Log In") {
                Task { await auth.login() }
            }
            .disabled(!auth.canSubmit)

            if let error = auth.errorMessage {
                Text(error).foregroundStyle(.red)
            }
        }
    }
}

struct CreateAccountView: View {
    @Bindable var auth: AuthViewModel

    var body: some View {
        // Different layout, same view model
        Button("Create Account") {
            Task { await auth.createAccount() }
        }
        .disabled(!auth.canSubmit)
    }
}

Both views look different, but neither of them knows how logging in or creating an account works. They call login() or createAccount(), and the view model takes care of the rest.

This matters because these are complex state mutations. Setting the loading state, clearing old errors, handling a failed request, and updating the logged-in state all have to happen in the right order. If every view did this on its own, I’d end up duplicating very similar code that mutates the same state, and sooner or later one copy would behave slightly differently from the others. With the view model, there’s one place responsible for how the auth state changes, and every view shares those same methods.

This is also why the view model isn’t owned by any one of these screens. It’s owned higher up, where all of them can reach it. I explain this approach in more detail in What Is a View Model in SwiftUI, Really?, under “scope by state, not by screen.”

Takeaway: complex state mutations and state shared across views are exactly what view models are for.

The Pattern Behind the Examples

If you look at the four examples side by side, a pattern shows up. Whenever there was real state to manage and real mutations to get right, the view model paid off. Whenever there wasn’t, it only added cost.

A view model is usually worth it when:

• The view needs real logic: validation, persistence, networking
• State changes over time, and those changes need to be coordinated
• Several views work with the same state and should share the methods that change it
• The state needs to outlive the view that displays it

It’s usually overkill when:

• The view only displays constants or simple values
• You’re configuring a reusable component
• The view model would hold little more than the properties the view already has

Notice that none of these points is about the size of the screen or how important it feels. It all comes back to the definition: a view model owns UI state and is responsible for mutating it properly. If there’s no state to own and no mutations to get right, there’s no job for a view model to do.

Start Simple, Refactor When It Grows

You might have noticed that two of the examples started without a view model and only needed one later. That’s very typical. Most view models aren’t planned up front. They show up when a view starts collecting logic.

So you don’t need to decide on day one. Start with the simplest version that works, and keep an eye out for these signs:

• The view body gets long, and most of it isn’t UI
• State mutations are scattered across subviews, or duplicated in slightly different versions
• It’s getting hard to follow how and when the state changes
• A second view suddenly needs the same state

When you see them, that’s the moment to move the state and its mutations into a view model. I’ll walk through that refactoring step by step in Refactoring to a View Model When Complexity Grows.

Wrapping Up

There’s no solution that fits all. Whether you use a view model in a given situation is really up to you, and it comes down to one question: is this extra layer worth it here?

You don’t have to use one. A view-only solution is often the simplest and best choice. But when your views start collecting state and mutations that need to happen consistently, a view model is a very good tool for managing that complexity.

Once you’ve decided you need one, the next question is what actually belongs inside it. That’s what we’ll look at in What Should Go in a View Model?

Get the MVVM SwiftUI Cheat Sheet

The cheat sheet puts the whole system on a few pages: what goes in a view model, which view owns it, how to pass it down the tree, common mistakes, and code skeletons you can copy.

Get the free cheat sheet

The post When to Use a View Model in SwiftUI (and When It’s Overkill) appeared first on swiftyplace.

So what is a view model, really? In this post, I want to give you a clear, practical definition that you can apply to your own code. Here’s the main rule that I find most practical, so you have something to hold on to:

A view model owns UI state and is responsible for mutating that state properly and consistently.

Notice what’s not in that sentence: a single view. A view model isn’t tied to one view. It can support one view, an entire screen, or several views that share the same state. (Other people might say otherwise, but I am giving you the system that works best for me)

That responsibility is the whole point. In SwiftUI, state drives the UI. When something on screen is wrong, the cause is almost always state that’s wrong. And state goes wrong because the code that mutates it is messy: scattered across views, duplicated in slightly different versions, or running steps in the wrong order. A view model gives those mutations one home, so they happen the same way every time.

That’s it. Everything else in this post explains what that means, why it’s useful, and where the boundaries are.

Where MVVM Comes From

MVVM stands for Model-View-ViewModel. It was introduced in 2005 by Microsoft architects Ken Cooper and Ted Peters. I don’t usually spend much time on history, but here it matters because understanding where the pattern came from helps us understand what it’s actually trying to do.

MVVM was born in Windows Presentation Foundation, or WPF. The UI in WPF is written in XAML, a declarative markup language, and it relies heavily on data bindings and reactive updates. In other words, it’s state-driven, declarative programming. Sound familiar? That’s very close to how SwiftUI works.

So what problem was MVVM designed to solve? It came down to people. In WPF, teams naturally split into two groups: UI-facing developers, who Microsoft called “designer developers,” and logic developers working behind the scenes. The challenge was letting these two groups work in parallel without stepping on each other’s toes.

What kept happening was that logic crept into the view: network requests, formatting, data transformations. The view code became cluttered and hard to maintain, and when everyone has to work in the same file, collaboration breaks down fast.

The solution was to pull that complex logic out of the view and into a separate layer. The view was left with nothing but declarative UI, and the logic developers had their own layer to work in. That separate layer is the view model.

The Backing Layer: A Presentation Layer Pattern

The best way to think about a view model is as the backing layer behind your UI. You have the view on one side and your data on the other, and you place an intermediate layer in between. That layer handles the more complex concerns: state management, formatting, anything you don’t want cluttering your view code.

I like to compare it to an old-school calculator. On the front, you see the buttons and the display. That’s your view. Now imagine you unscrew the case and look inside: the battery, the circuit board, some cables. That’s your backing layer. As a user, you just want to press buttons and get results. You don’t want to see or deal with the internals. A view model works the same way: it keeps the inner workings hidden behind a clean surface.

That’s why I often prefer the term UI backing layer over “view model.” It describes what the thing actually does.

This also leads to an important clarification. Because we’re talking about layers, you’ll sometimes hear MVVM described as a “UI architecture pattern.” That can be misleading, because it gives the impression that MVVM is a full app architecture. It’s not. MVVM is a presentation layer pattern. It’s about the view and the code that directly backs it.

• It’s not about visual design, like layout, colors, or components.
• It doesn’t tell you how to structure your whole app. Networking, persistence, navigation, and dependencies need their own layers and patterns.
• At its core, it’s about separation of concerns within the UI layer.

The Three Layers

Let’s look at each part of the pattern and what it’s responsible for.

The View

The view is the UI layer. In SwiftUI, these are your View structs, and their job is to take state and decide what to display. Logged in? Show the main content. Logged out? Show the login screen.

Views also handle the finer details of presentation. Is a button enabled or disabled? What text goes into a label? What font, what position, what layout? These are all view concerns. The view is the part that makes things look good.

Views also receive user interactions. When someone taps a button, the view picks that up. Sometimes it handles the interaction directly, but more often it passes the user’s intent along to the view model. The view just says “the user tapped this” and moves on.

The View Model

The view model is the UI backing layer. Because SwiftUI is state-driven, everything revolves around UI state, and managing that state can get complex. When do you change it? What moves you from loading to success, or to an error? What happens when a network request comes back? All of this needs to live somewhere, and that somewhere is the view model.

The view model owns the UI state and decides when and how it changes. It can also prepare data for display, like formatting a price, and act as a gatekeeper for what’s allowed to happen.

The Model

The model is your data: the structures your app works with, and the logic that naturally belongs to that data, like validation rules.

You’ll find that different developers mean different things by “model.” Some put their networking code here too. That’s a valid interpretation, but to keep things clear, I keep the model narrow: the data itself, plus the logic intrinsic to it.

What Defines a View Model: UI State + Mutations

You can characterize any view model by two things: what state it holds, and how it can change that state. That’s really all that defines it.

• UI state: the data your views need to render. The items in a list, whether something is loading, an error message, which item is selected, whether a button is allowed to be tapped.
• Methods to change UI state: controlled mutations of that data. Adding an item, logging in, deleting a theme.

Because the view model backs the UI, its state has to be connected to the views that display it. That comes with two technical requirements:

• @Observable: SwiftUI needs to track the state so it can update the views whenever it changes. Without observation, the view has no way of knowing that something happened.
• @MainActor: the UI reads this state, and UI work happens on the main actor. So the state, and the code that changes it, lives there too.

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []   // UI state

    func addItem(id: String) { /* ... */ }    // mutation
    func removeItem(id: String) { /* ... */ } // mutation
}

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []   // UI state

    func addItem(id: String) { /* ... */ }    // mutation
    func removeItem(id: String) { /* ... */ } // mutation
}

There’s one more rule I find really helpful: a view model communicates through state, never through UI instructions. Say a user isn’t allowed to buy a certain product. The view model doesn’t say “disable the button.” It says “this action is not allowed.” The view is the one that translates that into a disabled button.

In the same way, a view model can prepare data for display, like turning a raw price into a formatted string. But it never decides how that information is rendered. It knows what to show, never how to show it. That’s view territory.

Why Put State and Mutations Together?

I like to use the law of proximity here: things that change together should live together.

You can look at UI state from two directions. When the state changes, the UI changes, so the state should live close to the views that use it. That’s true. But the state and the code that changes it belong together just as tightly.

Think about a SwiftUI view hierarchy where several views use the same state, and each of those subviews can mutate it. The state declaration moves higher up the view tree, but the code that changes it is scattered across different subviews. Things get messy quickly. If you want to know where a value was changed, you have to go hunting through the hierarchy.

A view model brings them back together. The state lives in one place, and the methods that change it live right next to it. You get a single source of truth for the state, and one place that’s responsible for changing it properly and consistently.

That gives you a few concrete benefits:

• Consistent mutations: every change goes through the same methods, so it happens the same way every time.
• No duplicated logic: if several views need to make the same change, they call the same method. Duplicated logic tends to drift. Sooner or later you update one copy and forget the other, and your state goes out of sync.
• Easier to follow: when you want to know how the state changes, you look in one place.

Get the MVVM SwiftUI Cheat Sheet

The cheat sheet puts the whole system on a few pages: what goes in a view model, which view owns it, how to pass it down the tree, common mistakes, and code skeletons you can copy.

Get the free cheat sheet

Example: The Shopping Cart

Let’s see how these layers play out with a shopping cart.

The Model

The model is the raw data: a cart item with a product ID and a quantity, and the product information itself.

struct CartItem {
    let id: String
    var quantity: Int
}

struct Product {
    let id: String
    let name: String
    let price: Double
}

struct CartItem {
    let id: String
    var quantity: Int
}

struct Product {
    let id: String
    let name: String
    let price: Double
}

This isn’t what the UI wants to show, though. The view needs a name, a quantity, and nicely formatted prices, all in one place. So we add a display type that has exactly what the view needs:

struct CartDisplayItem {
    let id: String
    let name: String
    let quantity: Int
    let formattedPrice: String
    let formattedSubtotal: String
}

struct CartDisplayItem {
    let id: String
    let name: String
    let quantity: Int
    let formattedPrice: String
    let formattedSubtotal: String
}

The View Model

The view model owns the state of what’s in the cart. It turns the raw data into display items, calculates the total, and acts as a gatekeeper: if the view wants to change the cart, it has to call addItem or removeItem. It can’t reach in and change the items directly, which is what private(set) makes sure of.

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []
    private let products: [String: Product]

    init(products: [String: Product]) {
        self.products = products
    }

    // Converts model data into what the view displays
    var displayItems: [CartDisplayItem] {
        items.compactMap { item in
            guard let product = products[item.id] else { return nil }
            let subtotal = product.price * Double(item.quantity)
            return CartDisplayItem(
                id: item.id,
                name: product.name,
                quantity: item.quantity,
                formattedPrice: formatPrice(product.price),
                formattedSubtotal: formatPrice(subtotal)
            )
        }
    }

    var formattedTotal: String {
        let total = items.reduce(0.0) { sum, item in
            guard let product = products[item.id] else { return sum }
            return sum + product.price * Double(item.quantity)
        }
        return formatPrice(total)
    }

    // Gatekeeper: the view tells us what it wants, we decide if it's allowed
    func canAddItem(id: String) -> Bool {
        true // e.g. check stock or purchase limits
    }

    func addItem(id: String) {
        if let index = items.firstIndex(where: { $0.id == id }) {
            items[index].quantity += 1
        } else {
            items.append(CartItem(id: id, quantity: 1))
        }
    }

    func removeItem(id: String) {
        items.removeAll { $0.id == id }
    }

    private func formatPrice(_ price: Double) -> String {
        price.formatted(.currency(code: "USD"))
    }
}

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []
    private let products: [String: Product]

    init(products: [String: Product]) {
        self.products = products
    }

    // Converts model data into what the view displays
    var displayItems: [CartDisplayItem] {
        items.compactMap { item in
            guard let product = products[item.id] else { return nil }
            let subtotal = product.price * Double(item.quantity)
            return CartDisplayItem(
                id: item.id,
                name: product.name,
                quantity: item.quantity,
                formattedPrice: formatPrice(product.price),
                formattedSubtotal: formatPrice(subtotal)
            )
        }
    }

    var formattedTotal: String {
        let total = items.reduce(0.0) { sum, item in
            guard let product = products[item.id] else { return sum }
            return sum + product.price * Double(item.quantity)
        }
        return formatPrice(total)
    }

    // Gatekeeper: the view tells us what it wants, we decide if it's allowed
    func canAddItem(id: String) -> Bool {
        true // e.g. check stock or purchase limits
    }

    func addItem(id: String) {
        if let index = items.firstIndex(where: { $0.id == id }) {
            items[index].quantity += 1
        } else {
            items.append(CartItem(id: id, quantity: 1))
        }
    }

    func removeItem(id: String) {
        items.removeAll { $0.id == id }
    }

    private func formatPrice(_ price: Double) -> String {
        price.formatted(.currency(code: "USD"))
    }
}