Architecture patterns in iOS

In the recent past, I have been spending some time learning about the rookie mistakes most software developers make. To be honest, I have been called out every too often.

The one mistake I am most guilty of however is, not planning before starting on a project. It has happened to the very best of us. You start on this amazing new shiny project, from the very first day you can see it. The success of the project, the ebb and flow so to speak. Often, this excitement shots the part of the brain that is supposed to make logical decisions. So what do you do, you get right down to it and start writing code. Five days later, the project starts on a downward spiral. You start to imagine that you misjudged this project. Maybe it’s not such a cool project, after all, maybe it’s a case of the good old bait and switch. The truth however is, you are the problem. It is not the project, it never was. The project has remained the same, it is you who changed. 💔 If you do not plan, you will most probably get lost in all of it. After the excitement has worn off, all you will have is spaghetti code. Then you will most probably abandon it or worse still write horrible uninspired code. Now that we have called ourselves out, let’s look at one of the most important things to plan on. All hail architecture patterns! 👯

What is an architecture pattern you ask? It is a general reusable solution to a commonly occurring problem.

Why should you care about it? Architecture patterns make work easier for both you and your teammates. With the separation of concerns, it is easier to debug and navigate the code base.

Wow! That was a lot of words and no code. Now that you are still here 🤗, I will reward you with some code. 🎉

Enough talk, show me the code!!!

MVC

We will start off with this very common but misunderstood pattern 😢. MVC has been around for a really long time. You know MVC, it is that low maintenance pattern next door. Chances are if you have written iOS code, you probably used the MVC pattern. It is the pattern on which the iOS SDK is built. This pattern separates all code into either model, view and controller.

Model; this is where the data resides. It is responsible for persistence, modelling objects and parsing.

View; this is responsible for anything the user interacts with, it is what is seen on the screen such as labels and text fields.

Controller; this mediates between the model and the view.

MVC Example

shown above, the model basically models the data. In this example, it describes the meal data item as having two properties.

The view and the view controller are very tightly coupled in this example. If someone was to ask what the difference between the view and view controller in MVC, I would say I am not sure. MVC, therefore, fails in the separation of concerns. It has therefore been named the Massive View Controller owing to the fact that the view controller tends to become massive and almost impossible to navigate.

MVC is however perfect when building small projects. This is because it is easily learnable. When a project is not very complex, using a pattern other than MVC might be considered over-engineering.

MVVM

MVVM is basically MVC only with more elaborate separation of concern. It’s abbreviations stand for model, view and view model. MVVM is MVC’s fancier and more high maintenance friend.

Model; as in MVC this deals with the data logic

View; just as in MVC. The view controller is known as the view.

ViewModel; it is responsible for exposing the data objects from the model to the view in the form they should be presented.

MVVM example

MVVM retro?

How does MVVM work?

The view controller sends an event to the view model.
In MVVM, the view model knows nothing of the view controller. This makes it easily reusable. It also is fully separated from the view so testing is very easy as one does not have to mock the views.

Why MVVM?

Mvvm is definitely more distributed and therefore easier to test.

MVVM -C

While the MVVM pattern is amazing, it has one shortcoming; it does not put into the consideration the app routing aspect.

App routing? Say you have an app with several screens what handles the movement from one screen to the next, app routing takes care of this flow. Enter MVVM -C, it is basically MVVM with the zing factor that is a shiny coordinator. The coordinator handles the flow and navigation of the app.

MVVM -C example

Retro

Why MVVM -C? While MVVM solves a lot of the coupling problems introduced by MVC, the moment you introduce navigation in the view model, the coupling problem is reintroduced.

How does MVVM -C work? It works exactly the same as MVVM except that we add the coordinator to solve the navigation problem.

Benefits?

Better separation of concerns — here we have four separate entities with each performing a specific task.

Easily testable; isolating navigation from the view model means that the view model becomes even easier to test.

Reusable code; we can reuse the code when we eliminate the navigation from the models

Very dynamic navigation; it is very easy to inject various views from different places. The coordinator has no knowledge of what came before or what will come after. We can, therefore, place it wherever we want.

MVP

MVP is an abbreviation for model, view and presenter.

Model; This holds the business logic and business rules encapsulating the data part of the app.

View; This consists of elements from UIKit and it’s basically what we interact with on screen.

Presenter; This has the logic to handle the user interactions. It communicates with the model layer, converts data to a UI friendly format.

MVP example

When I first read about this, I realised it is very similar to MVVM. In MVVM as in MVP, there is the separation of view UIKit logic and view business logic and putting it in another file. It appears that the presenter is the view model with a different name. 🐑 🐺 Get it, a wolf in sheep’s clothing? 😆 However, one major difference to note is that unlike in MVVM, the part of the app that handles the business logic(presenter) has some knowledge of the view. In the MVVM, the view model is totally dumb with no knowledge of the view.

VIPER

Viper is the only of the architecture patterns that does not take the MV(X) pattern. Viper has five layers, doing a lot more separation of concerns. Viper abbreviates View, Interactor, presenter, entities and router.

View; This consists of the UIKit elements. These don’t contain any business logic.

Interactor; This contains the business logic associated with the data. It is basically what fetches data from the model layer.

Presenter; This contains the UI business logic. It prepares the data to the format it is required by the UI. It communicates with all the other layers.

Entities; These are basically the data objects

Router; This is in charge of the interaction between the modules.

I found it a bit hard to showcase viper using a playground snippet as it is massive. However there a lot of resources online on how to use Viper.

Retro

Why viper?

The viper architecture wins with distribution and testability. As you may have observed, it has the most separation of powers. More distribution translates to easier testability.

Battle of the architectures? ⚔️

When working with the different architectures, it is important not to ask which is the best but which is the best for your situation. This means you use the simplest possible. For instance, if I was building a simple news app, it would make sense to use MVC. However, if my app scaled and I introduced some other functionality like login, it would help to introduce more separation of concern. Therefore, the question that which is the best architecture pattern does not really have an answer. If you ever find yourself asking that question, take a step back and re-evaluate your situation.

If you learned something from my musings or enjoyed my lame/ non-existent jokes please clap for this piece. I would love for other people to be part of my learning network.