The reports of MVC's death have been greatly exaggerated
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.
SPONSORED From August 2nd to 8th you can join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer!
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you're curious you can learn more here.
Link copied to your pasteboard.