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 of how MVC can be used successfully in a large iOS project. I cherish this moment 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 the dangers of MVC and shows alternative pattern advancements. The 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 within big and medium teams, but MVVM often comes as a winner.

MVC is misunderstood. Most of the 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 the massive view controller problem when used as intended. Each view controller should serve only a 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, product quality is the only thing that matters. I think that a maximum amount of effort should be put into making a 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 a 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 fewer tests. Simpler code is easier to maintain, it will have fewer bugs and it will enable the 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 an iterative process.

Bohdan shows us that with each new pattern amount of code doubles. Each new pattern brings more abstractions and MVC wins with the 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’s 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 the 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 does work fine because both architectures are easily compatible.