The problem is that the Cocoa framework, even after the advent of Swift, has always been created with MVC in mind. We're now at a point in iOS where trends have rolled around and now people are saying to pick MVC because that was Apple's intention, other architectures were created because people were doing it wrong:
Obviously most significant production apps are using variant architectures such as at the bare minimum having view models, and the introduction of SwiftUI and popular earlier frameworks such as RxSwift also complicates things. Most apps aren't using pure MVC, sure, but it doesn't mean that the architecture isn't scalable. The alternatives might also be pretty gnarly:
That's an interesting article. I find iOS architecture fascinating and spend a lot of time thinking about it. It seems like "MVC" in common usage (based on talking to other iOS devs) means spaghetti, but I guess it doesn't have to be like that.
To me that article proposes a more disciplined MVC than what I've seen in real codebases. I think a lot of the architectures people come up with (like the second one you linked) try to build that discipline in. I try not to be dogmatic and instead go to core principles. Do I know what this class is supposed to be doing? Are my data and view layers reasonably separated with minimal glue code? Can a new dev easily navigate this project?
It's an endless discussion with no right answer. Thanks for sharing!
https://medium.com/flawless-app-stories/the-only-viable-ios-...
Obviously most significant production apps are using variant architectures such as at the bare minimum having view models, and the introduction of SwiftUI and popular earlier frameworks such as RxSwift also complicates things. Most apps aren't using pure MVC, sure, but it doesn't mean that the architecture isn't scalable. The alternatives might also be pretty gnarly:
https://developer.squareup.com/blog/ziggurat-ios-app-archite...