Quest for a better architecture : iOS Development — Part 1

Not many days ago when I first started developing iOS apps back in the objective C days, I noticed application architecture. The only architecture people were following was MVC mainly because it was official and Apple was also pushing for it. From Apple’s perspective MVC suits really well to explain how a new API works, but while building even a medium size app, its no longer a chosen architectural pattern. I’m not talking against MVC, thousands application have been developed with this architecture in various platforms, rather I’m trying to say is MVC does not go well with iOS development.

In my early days of development I sensed something wrong with this pattern, but did not know what the problem is. iOS development is highly framework driven, framework will dictate you while writing code. When you are working on a new feature, you go to apple sample code to know how things work or may be any tutorial site which explains the usage of the api that you are interested to include in your feature, you see the code is written in ViewController. If you are new, the possibility is high that you do the same in your app.Eventually you will end up creating a bloated controller known as ‘Massive View Controller’. Over time when your app grows it would be tough to maintain the codebase and trace bugs.

A better architecture should tell where to put which code. It will help you organize your code in a better way. We all know how important it is to adapt SOLID principle and writing DRY code. A better architecture will help you to achieve this goal. It will also help you provide maximum test coverage of your codebase and make your life easy.

Now we will go out and see what options do we have. Lately I noticed growing concern about app architecture in iOS community. Developers are trying out several architectures like MVP, MVVM, VIPER and Clean-Swift (VIP) as an alternative to MVC. Let’s go and check which architecture has advantage over another and their pros and cons as well.


The basic concept is Controller responds to events triggered by a View. It update Model upon an action, and update the View when Model changes. Here we see, the responsibility of View and Model is explicit, we know which code goes there, but where rest of the codes will go. In the worst case scenario, View Controller deals with animations, data persistence, network calls and even routing, resulting ‘Massive View Controller’. In the figure above some of the logic has been extracted into separate objects, such as Code Data (persistence) and Network services.


After MVC, MVVM is the most popular app architecture. MVVM(Model-View-ViewModel) assumes existence of a ViewModel, which is an additional layer that a ViewController communicates with. It contains business logic and to tackle with it, it can contain other objects, such as e.g. Network and Core Data services. If we put view related codes to ViewController, all the remaining codes go to ViewModel, 1000 lines ViewController now becomes 1000 lines ViewModel. This is the drawbacks of MVVM. Responsibilities are not properly distributed.


VIPER is a variant of clean architecture proposed by uncle bob. It is a complete architecture where responsibilities are clearly separated. Now you know where to put which code. With VIPER, it’s also easy to provide test coverage for you code base.
View — Interactor — Presenter — Entity — Router. This architecture clearly enforces to write code in a structured way and divides View Controller’s responsibilities onto smaller objects. There is also an additional component called Router (a.k.a Wireframe), which deals with setting up other view controllers.

In part 2 of this series I will describe about Clean-Swift proposed by Raymond

note : figures have been explicitly taken from blog.