When SwiftUI was announced at WWDC 2019, jaws dropped. Though still in beta, it’s already made its mark on the Apple developer community. Careful observers noticed SwiftUI uses the Model-View-ViewModel (MVVM) design pattern, whereas “legacy” Apple apps are Model-View-Controller (MVC) builds. But why make the switch?
The simplest way to think of MVC codebases is that the View is what a user sees, the Model is where the logic of your code resides, and the Controller is a segway between the two. It’s circular; the user taps a button in the view, the controller recognizes what the user is looking for, pings the model for the info, and the model gives the data up so the user can see it onscreen.
The MVVM model is a bit less circular, with a lot more back-and-forth. Its flow is MVC-like, but it uses bindings to communicate between the View and Model... and that binding architecture is referred to as the ViewModel. We’ve previously covered SwiftUI bindings, which are represented in code as a $-prefix. With MVVM, the Model still holds all of your app logic, and the View is still what the user interacts with, but the ViewModel makes the interaction between the two much simpler and more discernible in your codebase.
Let’s use a restaurant as an example. In a traditional restaurant, you’d go in, sit down, and a server would take your order, then relay that order to the kitchen. Your table is the view, your server is the controller, and the kitchen is the model. The view orders, the model handles the nuts and bolts, and the controller simply makes sure everything runs smoothly.
Other restaurants are counter-order businesses. You walk up to the counter, tell them what you want, and they make it for you. You (the view) are interacting more directly with the model (the kitchen), but the ViewController (whomever was at the counter taking your order) is still present, and may deliver your food to your table, but the view is handling much more of the interaction.
That's all great, but why did Apple move to MVVM with SwiftUI? Probably many reasons, but there are a few takeaways.
First, we should consider accessibility. Apple made accessibility a focal point of the WWDC 2019 keynote, showing off some really sharp accessibility use-cases and features. The MVVM model makes designing apps less tedious, and allows developers and designers to instead focus on the user experience. SwiftUI wasn’t built specifically for accessibility, of course, but the MVVM pattern it adopts makes implementing those features less problematic for developers and designers.
Second, we should understand MVVM and MVC are simply architectural patterns and choices. To wit, there’s absolutely nothing preventing a developer from using an MVC pattern, or even eschewing SwiftUI for the now-old-school Storyboards feature in Xcode. SwiftUI and MVVC are simply better for single-page apps, or apps that don’t have a deep hierarchy of views. And we’d venture there are a lot of apps just like that using Storyboards, and linking IBOutlets and actions while setting constraints is just clunky.
MVVM is also more nimble. It first popped up in Microsoft Silverlight, Microsoft’s now-defunct framework for writing native and web applications. Though Microsoft described Silverlight as being useful for “mobile and web” applications, Apple has used SwiftUI (and MVVM by extension) to encompass its entire platform market. MVVM is also widely used in JavaScript frameworks.
Colloquially, it seems the Apple app developer community is finding SwiftUI and the MVVM model it uses simpler, and more fun. It’s a new paradigm many are not used to, but it’s livened the mindshare around iOS, macOS, tvOS, watchOS, and iPadOS app development. Across the board, MVVM was exactly what Apple – and its developers – needed.
