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 an

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: https://github.com/mozilla-mobile/firefox-ios/blob/21e9d294343fb43af967c73cb142603d4dc59b57/Client/Frontend/Browser/BrowserViewController.swift https://github.com/mozilla-mobile/firefox-ios/blob/21e9d2943... 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.