MVVM in SwiftUI for a Better Architecture [with Example]

Since the introduction of SwiftUI, the MVVM pattern has become more relevant than ever. Many developers believe this particular pattern aligns well with the SwiftUI data flow.

MVVM incorporates good ideas but also introduces problems due to varying interpretations of the pattern and its perceived rigidity.

In this article, we’ll explore how MVVM fits into SwiftUI, how to leverage its advantages, and how to navigate its challenges.

Table of contents

MVVM is an architectural pattern that helps you structure the code of a SwiftUI app by dividing it into three distinct roles.

• The model represents the app’s data and its business logic.
• The view displays information to the user and enables interaction.
• The view model acts as a bridge between the view and model layers. It contains a view state and handles most of its logic.

The binder is a crucial component of MVVM. It synchronizes the view and view model layers, eliminating related boilerplate code.

The MVVM pattern is not exclusive to SwiftUI or iOS. Microsoft architects initially developed it, and it was integrated into iOS development years after the initial iOS SDK release.

---

In this chapter:

How MVVM works in SwiftUI

Apple doesn’t explicitly endorse any architectural pattern over another. However, SwiftUI is particularly fitted to the MVVM architecture.

• It offers numerous data-independent views that seamlessly align with the view layer of the MVVM pattern.
• It provides mechanisms to bind views to data and automatically update the user interface when the underlying data changes.

A SwiftUI view model is usually implemented as an @Observable class held by a view within a @State property. It is connected to SwiftUI views that allow data input and user interaction through the @Binding property wrapper or action closures.

import SwiftUI

struct ContentView: View {
	@State private var viewModel = ViewModel()

	var body: some View {
		// Views connected to the viewModel property
	}
}

@Observable class ViewModel {
	// Properties and methods
}

Do you need a view model for every SwiftUI view?

The MVVM pattern’s detractors commonly misunderstand it and believe it creates a large amount of useless boilerplate code because it requires attaching a view model to every view.

However, the problem is caused only by a too-strict adherence to MVVM prescriptions, which can cause problems with any other pattern.

Not all views require view models. Specifically, pure views, i.e., modular views that simply display information like Text or Image do not require a view model.

View models should be restricted to root views only when doing so has real benefits. You can read more about these concepts in my free guide on MVC and MVVM in SwiftUI.

Why you should use MVVM in your SwiftUI apps

The clearly defined roles in the SwiftUI MVVM architecture respect the separation of concerns design principle, which is crucial for maintaining well-organized and easily understandable/testable code.

Unfortunately, there’s a misconception among inexperienced developers that MVVM is an obsolete pattern and is no longer necessary in SwiftUI. However, multilayer architectural patterns like MVVM are unavoidable.

SwiftUI manages only the view layer. Without architectural patterns, code accumulates within views, violating fundamental software design principles like the SOLID principles. This results in massive monolithic views with code that is hard to reuse, maintain, and unit test.

The fact that SwiftUI automatically handles view updates does not justify abandoning software development best practices that have existed for decades across various platforms.

You might have seen an anonymous rant against MVVM on Apple’s forums that Google persistently puts at the top of search results.

Skimming through the thread, you can find gems like:

Don’t do Clean / SOLID anti-patterns, be an OOP engineer

developers must stop follow SOLID and “Uncle Bob” bad practices

Agile, SOLID and over testing works like a cancer for development teams.

No wonder that he then supports the so-called MV pattern. If you want to follow that advice, help yourself, but don’t say you weren’t warned.

To see an example of MVVM in SwiftUI, we will build a small app for Hacker News, a news website for developers similar to Reddit, which is known for its (debatable) quality. We will use its web API to fetch the top 10 news stories from the best stories page.

You can find the complete Xcode project on GitHub.

---

In this chapter:

Creating model types to represent the app’s data and business logic

We will start by implementing our app’s model layer. Model types only contain the domain business logic, i.e., the app’s data and the code that manipulates it. They are agnostic of data storage, networking, and user interface presentation.

The Hacker News API uses an item entity to represent all its data, e.g., stories, comments, jobs, etc. Therefore, creating a corresponding Swift type is straightforward:

struct Item: Identifiable {
	let id: Int
	let commentCount: Int
	let score: Int
	let author: String
	let title: String
	let date: Date
	let url: URL
}

extension Item: Decodable {
	enum CodingKeys: String, CodingKey {
		case id, score, title, url
		case commentCount = "descendants"
		case date = "time"
		case author = "by"
	}
}

Since the returned data is in JSON format, our Item struct conforms to the Decodable protocol and provides coding keys to map the JSON fields to our properties. You can read more in my article on parsing JSON in Swift.

Model types should not merely act as empty data containers. Data transformation code is an example of business logic belonging to the model layer of MVVM.

Implementing reusable views decoupled from model types

Reusable content views constitute the second layer of MVVM that we will explore. Let’s start with a view representing a single entry in the top 10 most upvoted Hacker News posts.

struct Entry: View {
	let title: String
	let footnote: String
	let score: Int
	let commentCount: Int

	var body: some View {
		VStack(alignment: .leading, spacing: 8.0) {
			Text(title)
				.font(.headline)
			Text(footnote)
				.font(.footnote)
				.foregroundColor(.secondary)
			ZStack(alignment: Alignment(horizontal: .leading, vertical: .center)) {
				Label(score.formatted(), systemImage: "arrowtriangle.up.circle")
					.foregroundStyle(.blue)
				Label(commentCount.formatted(), systemImage: "ellipses.bubble")
					.foregroundStyle(.orange)
					.padding(.leading, 96.0)
			}
			.font(.footnote)
			.labelStyle(.titleAndIcon)
		}
	}
}

#Preview {
	Entry(
		title: "If buying isn't owning, piracy isn't stealing",
		footnote: "pluralistic.net - 3 days ago - by jay_kyburz",
		score: 1535,
		commentCount: 773
	)
}

The crucial aspect is that our view is entirely independent of our Item structure. Instead, it employs simple Swift types like Int and String.

Notice that the Entry view does not have separate stored properties for

• the domain name of the website;
• the date of the story;
• the author.

It merely displays this information as a footnote text. This helps maintain types as loosely coupled as possible, minimizing the impact of changes on existing code.

Writing a view model that encapsulates the app’s logic for a single app screen

The full view must display a list of stories. Most developers typically place the required state and networking code here. However, according to the MVVM pattern, that code belongs in a view model.

To retrieve the best stories from the API, we need to call endpoints:

• The best stories endpoint returns an array of IDs.
• Then, we use the first ten IDs to get data from the story endpoint.

extension ContentView {
	@Observable @MainActor class ViewModel {
		var stories: [Item] = []

		func fetchTopStories() async throws {
			let url = URL(string: "https://hacker-news.firebaseio.com/v0/beststories.json")!
			let (data, _) = try await URLSession.shared.data(from: url)
			let ids = try JSONDecoder().decode([Int].self, from: data)
			stories = try await withThrowingTaskGroup(of: Item.self) { group in
				for id in ids.prefix(10) {
					group.addTask { try await self.fetchStory(withID: id) }
				}
				var stories: [Item] = []
				for try await item in group {
					stories.append(item)
				}
				return stories
			}
		}

		private func fetchStory(withID id: Int) async throws -> Item {
			let url = URL(string: "https://hacker-news.firebaseio.com/v0/item/\(id).json")!
			let (data, _) = try await URLSession.shared.data(from: url)
			let decoder = JSONDecoder()
			decoder.dateDecodingStrategy = .secondsSince1970
			return try decoder.decode(Item.self, from: data)
		}
	}
}

The ViewModel class is @Observable, so any update to its stories property will trigger an update in the connected view. Placing this code outside of SwiftUI views simplifies testing.

The fetchTopStories() and fetchStory(withID:) methods employ Swift’s async await and URLSession to download data from the Hacker News API. Furthermore, the fetchTopStories() method utilizes a task group to parallelly retrieve the data for each story, creating distinct subtasks for each fetchStory(withID:) call.

In this simple example, I’ve placed all the networking code within the view model. However, for a more sophisticated SwiftUI app, a preferable approach to reusing code is constructing a separate Swift networking infrastructure for REST API calls.

SwiftUI view models before the Observation framework

Before the release of the Observation framework, view model classes conformed to the ObservableObject protocol, exposing their properties through the @Published wrapper. Moreover, the @StateObject wrapper was necessary inside SwiftUI views.

If your app doesn’t require support for iOS versions before 17, it’s recommended to migrate your codebase to use the Observation framework.

Adding a view model to a SwiftUI view and triggering events

The final step in implementing MVVM in our SwiftUI app is connecting the view model to a view.

struct ContentView: View {
	@State private var model = ViewModel()

	var body: some View {
		List(model.stories) { story in
			Entry(story: story)
		}
		.listStyle(.plain)
		.navigationTitle("News")
		.task {
			try? await model.fetchTopStories()
		}
	}
}

extension Entry {
	init(story: Item) {
		title = story.title
		score = story.score
		commentCount = story.commentCount
		footnote = (story.url.host() ?? "")
		+ " - \(story.date.formatted(.relative(presentation: .numeric)))"
		+ " - by \(story.author)"
	}
}

#Preview {
	NavigationStack {
		ContentView()
	}
}

The ContentView type holds the ViewModel instance in a @State property. It then initiates network requests by invoking the fetchTopStories() method within its .task modifier and uses a List to show the contents of the stories property of the view model.

The Entry extension allows us to conveniently initialize the view using an Item value within the NewsView even though the Entry view initializer uses simple Swift value types.

Remember to include a NavigationStack in the app structure to display the navigation bar when running the app in the iOS simulator.

@main
struct HackerNewsApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

You might notice a distinction between the Entry and ContentView types. While the former remains wholly decoupled from other app layers, the latter is linked to the ViewModel class and, consequently, to the Item structure.

The ContentView is what I call a root view. Although technically part of the view layer, it shoulders more responsibilities than a pure view, which solely displays data and enables interaction.

You can read more about these concepts in my free guide on MVC and MVVM in SwiftUI.

MVVM isn’t the sole architectural pattern available in SwiftUI.

I’ll begin this section with a disclaimer: it will reflect my strong opinions and critical perspectives on these alternative patterns.

However, sometimes, valuable ideas emerge that can be integrated into your app’s architecture. So, take everything I discuss here with a grain of salt.

---

In this chapter:

MVVM vs. MVC: Local view models and global controllers

MVVM and all other patterns are just variations of MVC, so the latter cannot be considered an alternative. When comparing the MVC pattern diagram, it’s apparent, even to non-experts in graph theory, that MVVM and MVC are nearly identical.

The fundamental disparity between MVC and MVVM in SwiftUI lies in the emphasis on controllers, objects shared across several views, versus view models, which are local objects controlling the behavior of a single view—usually representing a single screen in an iOS app.

However, in MVVM, the necessity for shared objects persists. These are often implemented as singletons, subsequently accessed by individual view models.

I consider singletons an anti-pattern, so I combine the MVVM and MVC patterns in my apps, modeling the view logic through view models and sharing controllers via dependency injection.

import SwiftUI

struct ContentView: View {
	@State private var viewModel: ViewModel?
	@Environment(Controller.self) private var controller

	var body: some View {
		Text("Hello, World!")
			.task {
				viewModel = ViewModel(controller: controller)
			}
	}
}

@Observable class ViewModel {
	private let controller: Controller

	init(controller: Controller) {
		self.controller = controller
	}
}

@Observable class Controller {
	// ...
}

In such cases, view models must be initialized inside the task(priority:_:) view modifier, as recommended in Apple’s documentation.

Any developer complaining that you cannot access environment objects from view models or that passing them through an initializer is “too painful” should not be trusted.

The Model-View pattern and the Elm architecture

The MV pattern (Model-View) seems to be a new contender to MVVM. Some developers assert that MVVM isn’t necessary for SwiftUI and that an app should primarily comprise views and the model.

I consider the MV pattern to be an anti-pattern. It goes against pretty much every software design principle and makes code untestable. This is a high price for the supposed benefit of having a little less boilerplate code.

This concept is occasionally likened to the Elm architecture and often stems from a slide in Apple’s initial SwiftUI presentation.

These show a complete lack of knowledge about design patterns and best practices, paired with the arrogance that a new UI framework somehow necessitates throwing away decades of hard-learned lessons.

Trygve Reenskaug used the same diagram for the MVC pattern 40 years earlier, and it can be easily found on Wikipedia.

Apple developers claim that SwiftUI is architecture-agnostic. However, there is no escaping that any architectural design pattern rests its foundations on MVC.

When you poke, the MV pattern reveals the need for objects shared across views through singletons or as SwiftUI environment objects. You might label those handlers, managers, stores, services, or any other fancy name, but fundamentally, they remain controllers.

Moreover, forgoing a well-defined design pattern leads to these objects lacking distinct roles. Throwing away layers when the general approach has always been adding more results in a messy codebase and model types that encompass responsibilities belonging to other layers.

The Clean Swift architecture and the VIP and VIPER patterns

A family of patterns, including VIP (View-Interactor-Presenter) and VIPER (View-Interactor-Presenter-Entity-Router), stems from what’s commonly known as Uncle Bob’s Clean Architecture.

Much could be said about these patterns, but as I said above, they are all a rehash of MVC with shuffled roles.

One significant flaw of theirs is the proliferation of protocols and generics. While these are necessary in complex apps, every abstraction incurs a cognitive cost. Abstractions should only be used when truly beneficial, not merely because a pattern prescribes them.

However, they cab also introduce ideas worth exploring. For example, the router idea from VIPER can be integrated into MVVM in the form of coordinators to better manage the navigation of a complex SwiftUI app.

The influences of Redux and the Swift composable architecture

Among the options discussed here, The Composable Architecture (TCA) seems to be gaining popularity, especially with support from a dedicated open-source library.

I believe Redux-like architectural patterns, such as TCA, are a terrible choice. They impose functional programming paradigms onto a language and a framework that are not functional but heavily reliant on imperative code and state.

The primary issue with this approach is that it concentrates the entire application state within a single monolithic structure, resulting in tightly coupled code.

Moreover, any change to the data in such a structure can trigger view updates across the entire view hierarchy, even in views unrelated to the updated state components.

Another problem arises from reducers, which introduce substantial boilerplate code typically implemented using numerous Swift switches. This code blatantly violates the Open-closed principle.

Conclusions

The MVVM pattern introduces a crucial architectural idea: the necessity of dedicated objects for views in an iOS app, namely the view models of MVVM.

This article covers only a portion of an app’s architecture. As previously mentioned, complex apps often require global objects.

Relying solely on the MVVM pattern proves overly restrictive. Attempting to force all code into view models will likely lead to complications.

Additionally, a strict adherence to MVVM fails to address specific problems. For instance, why is the NavigationStack in the above example located in the main App structure? What happens in apps with intricate navigation?

Furthermore, adding objects to views can easily disrupt Xcode previews.

An extra layer—the root layer—is required to resolve these issues. For more information, access my free guide below.