Initial impressions using VIPER Architecture in iOS development

Some traditional iOS developers use MVC architecture for long years without try other approaches. The MVC organizes the code, grouping them in one of the three layers (Model, View or Controller). But when we are working in some big projects we need more than three layers to get a better code organization.

The problem of using the plain MVC is the Controller classes handle a lot of work as we see below:

MVC - Model

  • contains entities objects;
  • handles persistence of the each entities;
  • handles the business logic.

MVC - Controller

  • intermediate View and Model objects;
  • handles the views and application logic;
  • tests View logics, data transformation, basic validations;
  • manage Keyboard, tableView delegate and datasource;
  • handles navigation between views;
  • manages and takes part in the responder chain used to handle events.

MVC - View

  • draw and animate the interface;
  • handle the user interaction passing data to Controllers.

Note the Controller responsibility. It explains why developers use too manny #pragma mark to organize their codes. If your controller classes are huge, you have fallen into Massive View Controller problem.

Ok, what can be done now? Searching in the web, there are some articles about another architecture called VIPER.

A brief introduction about VIPER

Viper is an acronym for View, Interactor, Presenter, Entity, and Routing. It has the following functionalities:

Viper - View

  • they are dummy views;
  • contain objects like UIView, UIViewController, UILabel, etc;
  • waits the content from the Presenter;
  • handle user interaction and pass it to Presenter layer.

Viper - Presenter

  • doesn’t know UI objects;
  • get inputs from View layer;
  • handle the view logic (add method will present other screen);

Viper - Routing

  • handle the navigation logic and transition animations;
  • knows objects like UINavigationController, UIWindow, etc;

Viper - Interactor

  • handle the business rules described as use case;
  • translate data between Entity and Presenter layers;

Viper - Entity

  • represent business objects;
  • are simple data structures manipulated by Interactor;

Translate the MVC to VIPER is a split task where each layer will lose some weights. See below how objects will move between both architecture:

Moving from MVC to VIPER architecture

Some critics

There are some critics I noted after build my first project with VIPER definitions.

First, Interactor objects represent one single use case. Sometimes it will be so small that it will increase the number of objects in your project;
Second, Storyboard Segues will conflict with Routing layer;

I think it's ok to use Storyboard Segues to represent the static routing in your application. Wireframes will be useful to turn it dynamic!

Finally, basic configurations already setted in the Storyboard need to be recreated in Wireframes objects.


It's clear that MVC is overdate to real projects and maybe it will lead you to maintain huges Controller classes. VIPER, in the other way, solve it adding more layers with clear objectives. It will costs a little bit more code to turn off some storyboard features but it's worth.


  1. iOS Developer Library at
  2. Architecting iOS Apps with VIPER at
  3. Cascavel Base Framework