Hey there! I moved my blog to http://sunshinejr.com
There will be a lot of stuff about iOS and Open Source in general, so if you are interested in these, please give it a shot ;-)
MVVM — MVC done right.
Architecture in iOS has become a quite popular topic. Personally, I love it. We have acknowledged that architecture is something that needs careful though. Addressing it resulted in multiple techniques the iOS scene rarely/never used. MVVM, clean architecture-like implementations like VIPER, Redux-like unidirectional data flow architectures like ReSwift and also Elm architecture ports are only a handful of what we’ve got in the store. The most popular of these has to be MVVM (at least most widely used nowadays, besides MVC). You can see many blogposts/talks about it - I’m guilty as well. Most of them compare it to MVC and how superior it is. Let’s just stop for a minute and go through the basics of these two architectures. What if MVVM is just a new, properly written MVC? 🤔
First of all, what is this MVC architecture we often dismiss as inferior compared to MVVM?
Most of the time it’s this old spaghetti code where the ViewController has all responsibilities in the world. And we want to forget about it as fast as we wrote the original code.
How about MVVM, though? Well, in MVVM we think about View + ViewController as one unit - a view layer - and the whole business logic is moved to a separate object - a ViewModel. This way we split our code in two layers: UI and logic.
This is a very good first step, but still the logic can be tricky and we can end up with a massive view model in no time. This led to multiple new concepts/patterns used with MVVM: Coordinators/FlowControllers, reactive programming, caching/networking layers, using multiple ViewModels with mediators and so on. The question we should ask is: why was it harder to use these concepts with MVC?
There should be as many answers for that question as UI frameworks on GitHub, but I feel like the biggest problem was with having both logic and UI in the same object. You’d need to have more discipline to keep things tidy and readable than with two objects having different responsibilities. This is when architecture comes into play - it’s there to help you, so if you are sticking to your architecture choices even though it’s driving you insane and does not help you nor your team at all, please reconsider. But, going back to the MVC problems:
What if I told you that you can copy the thinking from MVVM - that View + ViewController is just a view layer - to MVC?
What if I told you that the real responsibility of Controllers in MVC does not differ from current state of ViewModels in iOS MVVM? That most of the time we are using it wrong?
Then we could say that the current state of iOS MVVM is the new, properly written MVC. What we needed was a shift of mind - to stop thinking about ViewControllers as a panacea and think about structuring our code better.
In the end, does it matter what name we use for our architecture? If we are consistent with it, have all the responsibilities documented and it’s easy to reason about - probably not. We could even use iOS architecture name generator to spice things up (thanks Guilherme for the meme). The real problem is to find an architecture that fits the project well, helps us and our team be more productive, makes it easier to test our code, is not too complicated and doesn’t produce too much boilerplate. There are even more requirements, but name is probably the less significant one.
I’m also guilty of using the term MVVM, but actually writing MVC code. I don’t mind it, though. When we think about MVC in iOS, we don’t have many nice things to say. To forget about this stereotype we would have to work hard, like really hard. Thus, I’m keen to stick with the current naming to distinguish between the “old” and the “new” MVC. In reality it’s just a naming convention, but if it helps, hell yeah I’ll go for it.
Will you?
