iOS Architecture: MVVM + C

The first iOS architecture we learned was probably the MVC, it is a standard architecture Apple provides through all their documents. After we wrote some code, added some features, the original MVC could gradually change to another MVC (Massive). At this point, we want to seek some better solutions to help us maintain the code as clean as possible. Here comes the MVVM, which represents Model-View-ViewModel, and even better, with the C part, represents Coordinator. Now we have a fantastic architecture for our iOS apps. The original concept of MVVM was introduced by Microsoft in 2005. Model means the application’s business model. View means user interface. ViewModel means the business logic between your Model and View. All View’s presented data is driven by ViewModel. So, we simplify the View’s responsibility, which only contains the UX code, no logic anymore. All data formatter, calculation, and validation are all handled by ViewModel. This is where our business logic lives. Another benefit of adopting MVVM is it’s easy to add unit tests. That’s my favorite part. In the next blog, I will talk about unit tests in iOS apps. Now, let’s introduce the last part C. Coordinator takes care of the view's transition work. Because the view transition should not belong to any view, so it should not be handled by View or ViewModel. For example, viewA -> viewB -> viewC and viewA -> viewC are all valid transitions. When viewA wants to do a transition, it just tells its coordinator which view it wants to go, then the coordinator handles the transition logic. I wrote a project to demonstrate how this architecture works. The GitHub link is here: MVVM-C - iOS Architecture: Model-View-ViewModel and Coordinator 🏛 The demo project is a mock news app. There are three views: main, login and register. The workflows are: main -> login -> register or main -> register, and when the user is done in login or register, they go back to main. Though the app is quite simple, it’s enough to illustrate how MVVM and coordinator works. Let’s start from AppCoordinator. This is the root coordinator, it launches the main view, other view’s coordinator will inherit from it. There is a trick here. I use a stack to track each view. This is very useful when checking whether there is a memory leak. Because when init a new view, the push print will give a log, and when deinit a view, the pop print will give a log. If the pop log does not show up, we probably have a memory leak. Let’s see one more coordinator: LoginCoordinator. The start function initializes the LoginViewModel, then injects it into LoginViewController. And make the login view as the presented view. It also implements LoginViewModelDelegate, which will hand over two transition work to the coordinator. It just like ViewModel says I have done my job, now the user wants to go there, please handle that. Let’s see the ViewModel part. I created a superclass called ViewModelController. It accepts a viewModel property in its initializer. Each ViewController inherits from it, so every controller could separate its business logic to its ViewModel counterpart. Using register workflow for example. The RegisterViewController contains the code for UI elements, such as email label, textfield and register button, etc. When the user touches the register button, it calls RegisterViewModel’s register function to handle the validation work and the further network request. Here is the code for its ViewModel: We can see in the register function, it first calls the validate function, this is where our business logic lives. For different fields, we have different validation rules. If all requirements are satisfied, it calls dataModel to do the network request. As you see, DataModel is another separation. By doing this, we can easily make some mock stuff to test our ViewModel. I will talk about unit tests in the next blog. See you soon.