“I wanted to try building my first Swift app and already spent 2 weeks learning best practices and architectures, and I’m totally lost right now” — the type of comment I’ve seen so many times under various blog posts about architecture in iOS. For people who just start with iOS development — MVC is the right choice, period. It’s easy to learn and start using. Whether they end up with a massive controller or not isn’t important — the goal is to build something that WORKS.
But this is not how professional production apps are built. In addition to the attribute“it’s working!”, not least important traits are
- “it’s maintainable by the original team”
- “it can be easily picked up by another team”
- “it’s adaptable for quickly changing business requirements”
- “it’s fully testable”
- “multiple people can easily work on the same screen in parallel”
This is where MVC, even at its best variant, where all the concerns are extracted to other modules, fails totally — it’s too tightly coupled with everything. You cannot simply take it away — it binds all the modules in a knot that cannot be cut. You’re right, there is no silver bullet (and there cannot be). But there are fundamental principles that guarantee your program will have much fewer problems down the road — SOLID, DRY, GRASP and Connascence.
And architectural patterns are practical applications of these basic principles, so they shouldn’t be treated as ready-to-use recipes, no! The job of the programmer is to look at it, understand how it solves the most common problems and pick up interesting ideas from it, but not blindly copy-pasting the entire thing, which of course won’t suit best for a random app.
