How to design iOS app architecture

With the development of  the system design there has been a lot of architectures for applications on the Internet. And although such architectures can be well thought out and function perfectly in other projects, it does not mean that they will fit your project specifically. In this article we will talk about what app architecture is, how to create the best architecture for your project and what should you pay attention to while developing app architecture.

What is app architecture?

Since applications are designed to meet a particular business goal, very large volumes of data often have to be structured. App architecture is a way to facilitate the code writing for the program. Basically, it is a level of the system design. The reason for creating an architecture before starting to create a code is to develop guidelines and limitations within which the code will be created.

Why not using architecture from the internet?

Before we start talking about designing iOS architecture applications, it’s better to consider in detail the reasons for not using pre-made templates from the Internet. We have already begun to talk about it: different projects require different architectures. There is nothing wrong with learning from already existing architectures, but it is valuable to know that they do not provide development and growth strategies, have a random level of abstraction components and communication, and are well-suited only for teams and applications of the same size.

Main characteristics of a good architecture

There are three main characteristics of a suitable architecture that you must achieve if you are aiming to develop a truly high-quality application.

Balanced division of responsibilities between entities with exacting roles.

With the development of the application, the number of tasks can increase and processes can become more complicated.The easiest way to overcome the complications is to divide tasks among several entities, guided by the principle of single responsibility.


This quality is pretty obvious, especially for those developers whose applications have ceased to work after adding certain features. This is important because tests can find problems before users receive updates for the application, as it will take much more time to set up the work then.

Easy to use

Also important is the quality of the architecture you want to implement. It is worthwhile to write as little of code as possible, since it is always easier to work with the smaller code, and it is much less likely to make mistakes.

Choosing correct architectural pattern

To date, we have several patterns to choose from among them:

  • MVC
  • MVP
  • MVVM

Before talking of every pattern separately, let’s talk about the first three models, because there is something that combines them. They putt the entities of the application into one of three categories:

  • Its responsibility is the domain data and the layer of access to the data
  • Its responsibility is the presentation layer.
  • Controller/Presenter/ViewModel. Its main task is changing the model responding to the user activity. It also bondes Model and View.

Now let’s take a look at each model in more detail.


MVC or Model-View-Controller. Using it you have an ability to offload  the business logic and the data transformation to the Model, but you are unable to offload your work to the View. Mostly main duty of the View is sending actions to the Controller. Although MVC may not be suitable for large projects, it still has many concepts and models that help us reduce the size of our review controllers, such as delegation, composition, dependency input, protocols, etc. With these techniques, testing is also not difficult. So, let’s summarize the information about this model:

  • Division – view and model are separated, but View and Controller are closely linked.
  • Testing – because of poor distribution, you will probably test your model only.
  • Ease of use – the smallest number of codes among other templates.


Unlike the first option, where the View is closely related to the Controller, this option has a mediator (Presenter) that is not related to the lifecycle of the View Controller, and the View has no layout code in the Presenter, but its responsibility is updating the View with data and state.

So let’s look at MVP’s characteristics:

  • Division – most of the responsibilities are the divided between the Presenter and the Model
  • Testing – it is not complicated, it is convenient and there is a possibility to test business logic, because the View is quite easy to use
  • Ease of use – in comparison with the MVC, MVP has a possibility to use a larger code


Compared to the two previous models, MVVM (Model-View-ViewModel) is newer and works a bit differently. It also has a View and Model, but beyond that there is a Mediator, presented as a View Model. According to the fact that MVVM considers the View Controller as a View, and does not establish a strong interaction between the View and Model, it is alike with MVP. It also creates a link between the View and the View Model.

Let’s summarize information about this model:

  • Division – MVVM View is responsible for more things than MVP’s View. MVVM updates its state from the View Model by setting bindings when MVP simply sends all the events to the Presenter and does not update itself
  • Testing – the viewport does knows nothing about the View, which makes testing it easier
  • Easy to use – in a real application where you must redirect all events from the View to the Presenter and update the View manually, the MVVM will be much worse than the MVP if you used bindings.


VIPER works differently than the previous three patterns. It consists of five layers: View, Interactor (works with business logic related to the data), Entities (plain data objects) and Router (works with the segues between the VIPER modules). The logic of the model (data interaction) is moved to Interactor. Only the MV(X) user interface presentation functions are transferred to the Presenter, butthe data capability can not be changed. VIPER is the pattern that clearly identifies navigational responsibility, which is resolved by the Router.

So, let’s summ up the features of the VIPER:

  • Division – distinctive responsibilities
  • Testing – since it depends on the division, then testing is also very easy
  • Ease of use – there should be written a large amount of interface for classes with very small responsibilities


So now you’re probably better off understanding the iOS app architecture theme and why it is important to create an architecture before writing the code. We also hope that pattern information will help you create the most comfortable architecture for your app.