I don’t think that we choose MVC often enough. Here and there I discover some podcast episodes and some articles which would tell a story how MVC can be used successfully in a large iOS project. I cherish this moments because I think that MVC can work great while been misunderstood and undervalued by many iOS developers.

Bohdan Orlov has written this post on Medium about four iOS patterns: MVC, MVP, MVVP and VIPER. Bohdan warns readers about dangers of MVC and shows alternative patterns advancements. Table below with ratings on a scale from one to five from Bohdan’s perspective. One point is not given to any criteria — even the worst system is better than no system at all.

Criteria MVC MVP MVVM VIPER
Code size 5 4 3 2
Testability 2 3 5 5
Separation 2 3 4 5
Total 9 10 12 12

MVVM and VIPER have the most points. Seniors relying on unit tests, value separation and don’t mind complexity. VIPER is too tedious and complex to keep up with in big and medium teams, but MVVM often comes as a winner.

MVC is misunderstood. Most of developers I’ve met told me that MVC is out of date, primitive and not suited for modern needs. I don’t agree with them, I think that MVC is not causing massive view controller problem when used as intended. Each view controller should serve only single purpose. It’s not costly to add more than one view controller per screen. For difficult screens with many requirements func addChild(_ childController: UIViewController) can be used.

For me personally, product quality is the only thing that matters. I think that maximum amount of effort should be put into making product better through iterative improvements. View controllers are difficult and often impossible to test separately. Unit testing is generally good, but it shouldn’t drive the project design. Separating view controller and view model, designing proper abstract interface between them helps with mocking but is extremely costly in code size and time. When choosing between less code and better code coverage, I would choose less code and I would write less tests. Simpler code is easier to maintain, it will have less bugs and it will enable team to focus on refining the app. I think MVC can work great in many different scenarios, it integrates well with Apple frameworks, it’s easy to start with which helps with iterative process.

Bohdan shows us that with each new pattern amount of code doubles. Each new pattern brings more abstractions and MVC wins with least amount of them. I think the power of MVC in its simplicity. I wish we value simplicity more, it pays back a lot when debugging others people code.

Finally, I agree with Bohdan that we should think carefully before committing to a pattern, and don’t forget that it’s possible to use multiple patterns in a single project:

Therefore, it is natural to have a mix of architectures in same app. For example: you’ve started with MVC, then you realised that one particular screen became too hard to maintain efficiently with the MVC and switched to the MVVM, but only for this particular screen. There is no need to refactor other screens for which the MVC actually does work fine, because both of architectures are easily compatible.