Top 5 most used iOS Architectures

The most important thing to understand about architecture is: what components are there to carry out a given responsibility?

So, let’s talk about responsibilities first, and then the components of each architecture.

Responsibilities

Rendering: it is a responsibility to show on the screen the code written specifically about the visual components: labels, buttons, text fields, images, etc. Typically represented in the code by an .xib and a class of type ViewController.

Data processing: it is the responsibility to process the information in the appropriate format to be sent for rendering. Example: given a list of countries with country name and acronym, if I want to display only the list of countries without an acronym, I would need to do the treatment of the list, to send the ViewController a list containing only the names of the countries. We typically have a class for this responsibility, which can have multiple names, such as ViewModel or Presenter.

Data modeling: it is the responsibility to define the types of data for a given object. In a list of countries with description and acronym, we would have a Country object with two variables: the description and the acronym. Typically known as Model.

Screen flow actions: it is the responsibility to change the flow of the application to another screen, present an alert, return, etc., according to the user’s actions. Typically implemented in Coordinators or Routers (also known as Wireframes).

API requests: it is the responsibility to make HTTP requests to Rest APIs and return the external response to the application. Typically implemented in API or Interactor class.

Are there other responsibilities? Yes, but the above responsibilities are the most common. For example, some applications have a responsibility to tag the flow to an analytics system. Others have a responsibility to do API data conversion treatments for other data models. These responsibilities can be done in specific components, or within any of the components of your project’s architecture.

Architectures

MVC (Model, ViewController)
It has few components, with more responsibilities.
Model:
- Data modeling
ViewController:
- Rendering
- API requests
- Data processing
- Screen flow actions

In the example, you can see that every module has a ViewController and as many Models as needed.

MVP (Model, ViewController, Presenter)
Presenter shares responsibilities with ViewController.
Model:
- Data modeling
ViewController:
- Rendering
Presenter:
- API requests
- Data processing
- Screen flow actions

In the example, you can see ViewController and Presenter in every module, and Models just where its needed.

MVVM (Model, ViewController, ViewModel)
It is the same as MVP, but Presenter has another name: ViewModel.
Model:
- Data modeling
ViewController:
- Rendering
ViewModel:
- API requests
- Data processing
- Screen flow actions

In the example, you can see ViewController and ViewModel in every module, and Models just where its needed.

VIPER (ViewController, Interactor, Presenter, Entity, Router)
With different names, similar to MVVM, with a little more division of responsibilities.
Entity:
- Data modeling
ViewController:
- Rendering
Interactor:
- API requests
Presenter:
- Data processing
Router (also known as Wireframe):
- Screen flow actions

In the example, you can see ViewController, Presenter and Router in every module, and Models and Interactors just where its needed.

MVVM-C (Model, ViewController, ViewModel, Coordinator)
There is also a component widely used in some architectures, which is the Coordinator. It comes to complement architectures such as MVVM, for example, to take responsibility for the flow actions between screens, making the ViewModel more clear. In this case, it would therefore be an MVVM-C architecture. It’s posible to use Coordinator in other architectures: MVC-C, MVP-C, etc. It should work like this: imagine this flow of screens: A → B → C; the Coordinator should implement at least 3 protocols with 1 method inside to push each ViewController to the queue. Then, in the ViewModel you just have to delegate this responsability to the Coordinator, and call the protocol method when the user interacts, for example, touching a button.

In the example, the Coordinator is responsible for flow actions between modules.

Where should I implement Business Rules?
Some people write articles about architecture and explain where business rules should be implemented. For example, in the case of VIPER architecture, business rules must be implemented in the Interactor. Forget that concept. Business rules should be implemented in the Backend. Your application should be limited to making requests to an API, collecting data, making simple treatments, and displaying them on the screen as they arrive. If a given screen has 3 possible layouts depending on the user’s scenario, for example, then the information that defines which of the 3 scenarios we are in must come from the Backend. Ok, but why should it come from the Backend? Simple: it is better to implement the rule only once in the Backend, than in the various front platforms (iOS, Android, Web), and if the business rule changes, the deployment time of Backend systems is much shorter, as it does not need to be submitted to App Store or Google Play for publication.