UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

MVC vs MVVM vs VIPER – which to use for iOS?

The reports of MVC's death have been greatly exaggerated

Paul Hudson       @twostraws

Recently a number of blog posts have been published that discuss app architecture in detail, which in itself is nothing interesting. However, these post have all been about – or in response to – a wider discussion about whether the iOS community is over-thinking app architecture, and in particular whether MVC is just misunderstood.

The first article, Much ado about iOS app architecture by Aleksandar Vacić, took a hard-line stance that MVC works just fine when done properly, and with a few extensions around coordinators should be all you need:

Why does every single article, describing any of these new architectures, starts with a variant “Apple’s (sic!) MVC leads to a bloated M(assive)VC”. When I read that, I see: here’s another wannabe who never bothered to learn how to properly Delegate. Who never learned to use container controllers and compartmentalize functionality into embedded controllers. PSA: No one is forcing you to implement multiple DataSources in one Controller. To initiate network calls in viewDidLoad. To parse JSONs in UIViewController. To hard-wire Views with Singleton instances. If you do that, it’s your fault; don’t blame MVC.

A second post, A Better MVC by Apple veteran Dave DeLong, mostly agrees with Vacić, saying:

In my experience, these are pretty much the two fundamental reasons why developers find other architectural patterns so appealing. As a result, we turn to other architectural patterns to try and compensate. We reach for MVVM, or React, or MVP, or FRP, or VIPER, or insert-new-architecture-here. To be clear, there is nothing inherently wrong with any of these patterns. They all solve problems in unique and interesting ways, and it is good to study them and learn the principles they teach. However, I’ve found that building apps based on these patterns tends to pay negative dividends in the long run. All of these patterns tend to be “strangers” to UIKit and AppKit. Because of this difference, you end up with additional hurdles to clear when things change.

So far, so good.

But then came the article MVC by Rui Peres, which takes a rather argumentative stance – Peres attempts to break down the first two articles into one liners to be proved or disproved, then complains no proof is offered for the segments he has pulled out. Read through his response for yourself and make up your own mind, but I'm not entirely sure what he added to the discussion.

Finally, today long-standing industry veteran Ben Sandofsky weighed in with The Presentation Model, which starts by adopting a similar tone to the first two articles:

Stop me if you’ve heard this: "MVC is terrible! We had a massive view controller with networking, collection view layouts, and image caching. We moved away from MVC and everything was fixed!" This isn’t a strike against MVC, but our failure to teach it. When a controller contains network, storage, or layout code, it isn’t MVC. It’s ‘View and a Ball of Mud.’

However, Sandofsky goes on to frame the discussion in terms of Model View Presenter and how it compares to MVVM. It's worth a read, not least for the all-new architecture fad for 2018…

“Does it matter that people say MVVM when they really mean presentation model? Even Apple says MVC when they really mean MVP.” If your team already calls your presentation model a “View Model,” it isn’t worth the disruption to rename everything. For all I care, call it a Cupcake Model.

So, I boldly predict 2018 is going to be the year of the cupcake model – you read it here first.

BUILD THE ULTIMATE PORTFOLIO APP Most Swift tutorials help you solve one specific problem, but in my Ultimate Portfolio App series I show you how to get all the best practices into a single app: architecture, testing, performance, accessibility, localization, project organization, and so much more, all while building a SwiftUI app that works on iOS, macOS and watchOS.

Get it on Hacking with Swift+

Sponsor Hacking with Swift and reach the world's largest Swift community!

Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

Average rating: 4.3/5

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.