This article addresses some interesting, real-world problems with the MVC pattern, problems I've run into myself. When writing iOS applications I also usually end up with something that is better described as M-VC than MVC, where the view and the controller are tightly coupled and usually implemented by the same class. This is not how the MVC pattern was intended.<p>From a cursory read I like the architecture improvements they propose to 'fix' this situations. That said, I can't escape the feeling that for the majority of applications, this is way over-designed/over-engineered, and putting the cart before the horse. Your application should not be written to better suit the MVC (or MVVM-C) pattern, it should be the other way around. Often a merged VC class gets the job done just fine and keeps things simple and concise.<p>In my experience, my own applications end up with a single class that's both the view and the controller, for the simple fact that there is no reason to decouple them. I'm usually not interested in having multiple user-interfaces on top of the same model, so there is no incentive to re-use the controller. Note that IMO there is a clear distinction between decoupling the model from the view and/or controller (which is almost always desirable to separate data and presentation), and decoupling the view from the controller (which have a lot of overlapping resposibilities)<p>To be fair, I haven't written any applications that hat different UI for e.g. iPhone and iPad, and I haven't written any applications that also have a desktop counterpart. But even in those situations, I'm wondering how much there is to be gained from re-using controllers for different user interfaces...
This whole debate about mvc vs mvvm vs i don't know what really start to read like a joke.<p>Here's the truth : your app probably has more than three major components, and the GUI isn't the most important aspect of it. Build your app as if it was to be accessed through a command line or a repl, then add a GUI on top in the end.<p>You'll have reusable, business centric components, and your controllers ( or whatever you call it) won't be bloated.
If you're using storyboards, another way of solving this is to let your segues set up the view models of the source and destination view controllers. You just need to create some segue subclasses for each source/destination combo you need.<p>Better than polluting prepareForSegue, and it totally decouples your UIViewControllers from each other. The coupling is in the segue, which is where it should be.
A relevant previous HN discussion on Martin Fowler's "GUI Architectures" article (<a href="https://news.ycombinator.com/item?id=9770362" rel="nofollow">https://news.ycombinator.com/item?id=9770362</a>)
I work in an MVVM mode daily. The best MVVM frameworks help bootstrap the app shell, but require zero interfacing with the view afterwards, with the 'controller' just being a parent ViewModel. It's turtles all the way down.