that doesn't change the fact that you have a model in which 2 of the 3 roles just fuck around doing nothing, and 1 is doing everything (and has more classes). If you ask youself the question: "what does this logic belong to?" and most of the time it's the same good damn role, then are the roles useful as guideline?
I wrote "when you are in a situation..." - but that's not generally my experience, instead controllers are often cluttered with rendering details like colors and animations, networking code, or things that I would've put in the model layer.
To give some context, I remember reading an article about massive view controllers and one example was Firefox for iOS, so I've dug up a snapshot of its main view controller, which exhibits all the things people hate about Apple's MVC:
I have met Swift teams who would have proudly refactored this outdated MVC code into a "modern" MVVM pattern, replacing the 2000 LOC controller with one 2000 LOC ViewModel and a 500 LOC controller (because you still need UIViewControllers in the Apple world).
But in my opinion the bigger issue is the insistence of only having one controller, or view model, or whatever per screen. As soon as you find a way to divide all the interconnected concerns of this screen, the layers and their names are not really that interesting.
which begs the question what do you need MVC for, what is it if not a way of structuring code? If you can just structure your code by splitting to multiple files abitrarily, regardless of MVC
As I understand it, MVC is just how Smalltalk built its GUI toolkit: for each widget, the view did the rendering, the controller responded to user events and the model held the data. All the GUI toolkits that followed combined the view with the controller, which is why MVC seems to make no sense.
As for structuring your code, someone (I don't remember who) offered the suggestion that out of all the parts that the framework gives you, your application logic doesn't belong in any of them.
I don't think splitting up the controller part into multiple classes is a break from MVC. Nobody would demand that the view or model layer consists of a single class per screen, why should the controller layer follow this rule?
I actually agree with what you said in some way. Projects should start with whatever is the most boring, straightforward architecture possible, and then evolve it organically.
But for UIKit projects, that boring foundation is to vaguely follow Apple's idea of MVC, at least so that JSON parsing and font size adjustments don't happen directly in an IBAction.
back when I was still doing Android, there was this trend in Android to throw away Google MVC and just have everything as view (and none of fragment, activity and all that crap). The rest of your code you just slice up in ways that makes sense. You platform-dependent logic just reuses the same activity to access the junk google provides.
First, MVC isn’t flat. The (V)iew of an MVC triad can itself be an MVC.
Second, MVC is a UI pattern. Decouple your business logic from your UI. Put it in a utility or “service” layer (which itself can adopt patterns to manage complexity, as needed).
