A brief introduction to the iOS app architecture patterns

Making an app is an interesting but lengthy process which can involve large groups of designers, developers, project managers, etc. Everything has to run smoothly in order to make a well-functioning application, thus you have to start with a good base. The first step in developing and shaping the user-friendly interface is choosing a good app architecture.
In this article, we are going to focus on iOS App Architecture, but most of the points are equally applicable to other platforms.

App architecture essentially presents a set of techniques and patterns which help developers create a well-structured application.

Why start by choosing the appropriate app architecture?

Mainly, it helps eliminate the possibility of having a nightmare when trying to implement additional features or debug some issues. The less code you write, the less chance there is of something going wrong, and the app architectures help prevent code duplication, bad programming practices, and messy code. This leads to a good base for a healthy code environment. So, starting with the basics, here are some questions to bear in mind when choosing the right app architecture for a business or a project:

• For whom is the application intended?
  
• What are the clients needs and what should the app look like?
  
• How complex is the app?
  
  

MVC, MVP, MVVM or VIPER?

Differentiating between main patterns for iOS such as MVC, MVP, MVVM, and VIPER could pose problems to developers. There are some guidelines which you should take into account when making a decision.

Before explaining the architectural patterns, basic concepts of Model and View should be explained:

• The model represents knowledge - data structures, business logic, and rules. It is completely independent of the user interface.
  
• The view serves as a presentation of data - screens with UI elements where data is displayed and can be modified by the user.
  

The View and the Model never “talk” to each other directly, and the way in which the View is instructed to deal with the Model is what differentiates all these architectural patterns.

MVC (Model-View-Controller)

In the MVC pattern, the instructions are managed by the Controller - the layer where all the wires should be connected. It’s usually least reusable part of the app since it contains domain-specific rules. It “owns” the Model and uses it to define the flow of information. Think of it as an engine or brain - it decides what happens next.
Problem with MVC (at least in iOS environment) is that ViewControllers, which should represent a part of the Controller layer, contains partial state and logic of the View layer. This usually leads to massive ViewControllers and bulky files.

MVP (Model-View-Presenter)

MVP is an alternative to the MVC pattern where the Controller is replaced by the Presenter. In this case, the separation of concerns is as follows:

• ViewController is a part of the View layer only, including all the UI setups and events.
  
• The Presenter is the component dealing with all-things-logic.
  
• The Model stays the same.

It’s important to note that MVP uses passive View pattern, which means that all the actions will be forwarded to the Presenter. It will then trigger the UI updates using delegates and the View will only pass actions and listen to the Presenter updates.

MVVM (Model-View-View Model)

The MVVM pattern also allows taking some of this presentation logic out of the ViewController.
It introduces View Model - layer that has been described as a state of the data in the View - which allows the creation of customized Models for each View.
The idea of MVVM architecture is to have bindings between View and ViewModel which provide automatic synchronization of data and visual representation. This helps avoid the boilerplate code.
View-ViewModel separation is particularly convenient because developers can work on ViewModel code and designers can work on View in Interface Designer.

VIPER

The word VIPER is an acronym for View, Interactor, Presenter, Entity, and Routing. This so-called Clean Architecture pattern divides the app’s logical structure into distinct layers of responsibility. Consequently, it is easier to isolate dependencies (e.g. your database) and to test the interactions at the boundaries between layers. VIPER’s distinct layers help deal with this challenge by providing clear locations for application logic and navigation-related code.

So, with all this information, how can you decide which architecture is best to choose for a certain project?

Well, let’s see what it boils down to.

MVC results in poor testing process - only Model can be examined, V&C (due to the tight connection they have) cannot be tested at all. The robust connection between Controller and View segments proved to be truly “unhealthy” when it comes to software, so a new pattern was developed quickly after. However, it still is the “starter” pattern, the one that developers mostly begin with and improve over time. It should be used for simple and small apps.

Some variations of this simple app design include transition to MVP. Its added benefit is that the View is more loosely coupled to the Model and it is easier to unit test it because interaction with the View is through an interface.
Both MVC and MVP can be quite clean when implemented correctly, so this makes it more of a personal choice.

MVVM’s distribution pattern is better than in MVC, but it is massively overloaded compared to MVP. Testing is of particular importance here. While writing the code you cannot guarantee that the whole project will function properly; tests help to ensure it will.

MVVM provides great testing ground. MVVM should be used for medium-to-large applications and is generally not the pattern intended for new developers as it requires a bit more skill to be implemented correctly. Nevertheless, it is a great paradigm that stands on its own and is only made better with a nice binding framework. The motivation behind MVVM in iOS is that it essentially reduces the complexity of one’s view controllers (combating massive view controller syndrome) and makes one’s presentation logic easier to test.

This is also the case with VIPER. Its module separation is very beneficial once it comes to unit tests, as the great pattern’s distribution lets you test all the functionalities available.
This architecture is intended for large applications since its benefits are not so relevant and noticeable in small apps.

‍