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