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...