{"id":2644,"date":"2016-04-28T19:11:58","date_gmt":"2016-04-28T19:11:58","guid":{"rendered":"http:\/\/www.ckl.io\/?p=2644"},"modified":"2026-08-15T08:45:44","modified_gmt":"2026-08-15T08:45:44","slug":"ios-project-architecture-using-viper","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/ios-project-architecture-using-viper\/","title":{"rendered":"iOS Project Architecture: Using VIPER"},"content":{"rendered":"\n

When developing an iOS app, it’s important to think about what iOS project architecture you should use. Most developers use the pattern suggested by Apple<\/a>: the so-called MVC (Model-View-Controller) architecture. However, as well-established as it is, the MVC has its flaws.<\/p>\n\n\n\n

For one, because of its simplicity, it leads even the most experienced engineers to put any code that doesn’t belong to a View nor to a Model in the Controller’s logic \u2013 generating huge chunks of code in the controller and really compact views and models.<\/p>\n\n\n\n

In this post, we’ll present VIPER, one of the trending alternatives to MVC that might help you overcome its limitations while keeping your code modular and well-organized, improving your development<\/a> process.<\/p>\n\n\n\n

1. What is VIPER?<\/h2>\n\n\n\n

VIPER is a backronym for View, Interactor, Presenter, Entity and Router. It’s basically an approach that implements the Single Responsibility Principle<\/a> to create a cleaner and more modular structure for your iOS project. The idea behind this pattern is to isolate your app’s dependencies, balancing the delegation of responsibilities among the entities. This is achieved by using the following architecture:<\/p>\n\n\n\n

 <\/p>\n\n\n

\n
\"Viper<\/figure>\n<\/div>\n\n\n

The diagram above illustrates the VIPER architecture, in which each block corresponds to an object with specific tasks, inputs and outputs. Think of these blocks as workers in an assembly line: once the worker completes its job on an object, the object is passed along to the next worker, until the product is finished.<\/p>\n\n\n\n

The connections between the blocks represent the relationship between the objects, and what kind of information they transmit to each other. The communication from one entity to another is given through protocols, which we’ll explain further in this post.<\/p>\n\n\n\n

2. What are the parts of the VIPER iOS project architecture?<\/h2>\n\n\n\n

The VIPER iOS project architecture has five parts: View, Interactor, Presenter, Entity and Router. Each one owns a specific set of responsibilities, and they pass work to each other through protocols. Knowing what every part does, and where its responsibility ends, is the key to using the pattern well. To see how they fit together, we’ll develop a basic application (code also available on GitHub<\/a>) that fetches a list of articles from a REST API and displays them on the user’s screen.<\/p>\n\n\n\n

2.1. View<\/h3>\n\n\n\n

The VIPER View in an iOS application is a UIViewController that contains a sub view, which can be either implemented programmatically or using the Interface Builder (IB). Its sole responsibility is to display what the Presenter<\/strong> tells it to, and handle the user interactions with the screen.<\/p>\n\n\n\n

When the user triggers any event that requires processing, the View<\/strong> simply delegates it to the Presenter<\/strong> and waits for a response telling it what should be displayed next.<\/p>\n\n\n\n

This is how the View<\/strong> for our Article Visualization app would look in Swift:<\/p>\n\n\n

\n\/*\n * Protocol that defines the view input methods.\n *\/\nprotocol ArticlesViewInterface: class {\n    func showArticlesData(articles: [Article])\n    func showNoContentScreen()\n}\n\n\/*\n * A view responsible for displaying a list\n * of articles fetched from some source.\n *\/\nclass ArticlesViewController : UIViewController, ArticlesViewInterface\n{\n    \/\/ Reference to the Presenter's interface.\n    var presenter: ArticlesModuleInterface!\n\n    \/*\n     * Once the view is loaded, it sends a command\n     * to the presenter asking it to update the UI.\n     *\/\n    override func viewDidLoad() {\n        super.viewDidLoad()\n        self.presenter.updateView()\n    }\n\n    \/\/ MARK: ArticlesViewInterface\n\n    func showArticlesData(articles: [Article]) {\n        self.articles = articles\n        self.tableView.reloadData()\n    }\n\n    func showNoContentScreen() {\n        \/\/ Show custom empty screen.\n    }\n}\n<\/code><\/span><\/pre>\n\n\n
2.2. Presenter<\/h3>\n\n\n\n
The Presenter<\/strong> works like a bridge between the main parts of a VIPER module. On one hand, it receives input events coming from the View and reacts to them by requesting data from the Interactor. On the other hand, it receives the data structures coming from the Interactor<\/strong>, applies view<\/span> logic over this data to prepare the content, and finally tells the View<\/strong> what to display.<\/p>\n\n\n\n
Here’s an example of a Presenter<\/strong> for our Article Visualization app:<\/p>\n\n\n
\n\/*\n * Protocol that defines the commands sent from the View to the Presenter.\n *\/\nprotocol ArticlesModuleInterface: class {\n    func updateView()\n    func showDetailsForArticle(article: Article)\n}\n\n\n\/*\n * Protocol that defines the commands sent from the Interactor to the Presenter.\n *\/\nprotocol ArticlesInteractorOutput: class {\n    func articlesFetched(articles: [Article])\n}\n\n\n\/*\n * The Presenter is also responsible for connecting\n * the other objects inside a VIPER module.\n *\/\nclass ArticlesPresenter : ArticlesModuleInterface, ArticlesInteractorOutput\n{\n    \/\/ Reference to the View (weak to avoid retain cycle).\n    weak var view: ArticlesViewInterface!\n\n    \/\/ Reference to the Interactor's interface.\n    var interactor: ArticlesInteractorInput!\n\n    \/\/ Reference to the Router\n    var wireframe: ArticlesWireframe!\n\n\n    \/\/ MARK: ArticlesModuleInterface\n\n    func updateView() {\n        self.interactor.fetchArticles()\n    }\n\n    func showDetailsForArticle(article: Article) {\n        self.wireframe.presentDetailsInterfaceForArticle(article)\n    }\n\n    \/\/ MARK: ArticlesInteractorOutput\n\n    func articlesFetched(articles: [Article]) {\n        if articles.count > 0 {\n            self.articles = articles\n            self.view.showArticlesData(articles)\n        } else {\n            self.view.showNoContentScreen()\n        }\n    }\n}\n<\/code><\/span><\/pre>\n\n\n
2.3. Interactor<\/h3>\n\n\n\n
We can think about this object as a collection of use cases inside of a specific module. The Interactor<\/strong> contains all the business logic related to the entities and should be completely independent of the user interface (UI).<\/strong><\/p>\n\n\n\n
In our Article Visualization app, one use case example is to fetch the list of articles from the server. It’s the Interactor<\/strong>‘s responsibility to make the requests, handle the responses and convert them to an Entity<\/strong> which, in this case, is an Article object.<\/p>\n\n\n\n
Once the Interactor<\/strong> finishes running some task, it notifies the Presenter<\/strong> about the result obtained. One important thing to keep in mind is that the data sent to the Presenter<\/strong> should not implement any business logic, so the data provided by the Interactor<\/strong> should be clean and ready to use.<\/p>\n\n\n\n
In our Article Visualization app, the Interactor <\/strong>would be responsible for fetching the articles from an API:<\/p>\n\n\n
\n\/*\n * Protocol that defines the Interactor's use case.\n *\/\nprotocol ArticlesInteractorInput: class {\n    func fetchArticles()\n}\n\n\n\/*\n * The Interactor responsible for implementing\n * the business logic of the module.\n *\/\nclass ArticlesInteractor : ArticlesInteractorInput\n{\n    \/\/ Url to the desired API.\n    let url = \"https:\/\/www.myendpoint.com\"\n\n    \/\/ Reference to the Presenter's output interface.\n    weak var output: ArticlesInteractorOutput!\n\n\n    \/\/ MARK: ArticlesInteractorInput\n\n    func fetchArticles() {\n        Alamofire.request(.GET, url).responseArray { (response: Response) in\n            let articlesArray = response.result.value\n            self.output.articlesFetched(articlesArray!)\n        }\n    }\n}\n<\/code><\/span><\/pre>\n\n\n
2.4. Entity<\/h3>\n\n\n\n
The Entity<\/strong> is probably the simplest element inside a VIPER structure. It encapsulates different types of data, and usually is treated as a payload among the other VIPER components. One important thing to notice is that the Entity<\/strong> is different from the Data Access Layer, which should be handled by the Interactor<\/strong>.<\/p>\n\n\n\n
In our Article Visualization app, the Article class would be an example of an Entity<\/strong>:<\/p>\n\n\n
\nclass<\/span> Article<\/span>\n<\/span>{\n    var<\/span> date: String<\/span>?\n    var<\/span> title: String<\/span>?\n    var<\/span> website: String<\/span>?\n    var<\/span> authors: String<\/span>?\n    var<\/span> content: String<\/span>?\n    var<\/span> imageUrl: String<\/span>?\n}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
2.5. Router<\/h3>\n\n\n\n
The last and perhaps most peculiar element in the VIPER architecture is the Router<\/strong>, which is responsible for the navigation logic between modules, and how they should happen (e.g. defining an animation for presenting a screen, or how the transition between two screens should be done). It receives input commands from the Presenters<\/strong> to say what screen it should route to. Also, the Router<\/strong> should be responsible for passing data from one screen to the other.<\/p>\n\n\n\n
The Router<\/strong> should implement a protocol that defines all the navigation possibilities for a specific module. That’s a good practice because it enables a quick overview of all the paths an app can take by only looking at a Router<\/strong>‘s protocol.<\/p>\n\n\n\n
Because of a limitation from the iOS framework, only ViewControllers<\/strong> can perform a transition between screens, so a Router<\/strong> must contain a reference to the module’s controller, or any of its children.<\/p>\n\n\n\n
Here’s how our router would look in our Article Visualization app (note that the Router<\/strong> is widely referred to as Wireframe<\/strong>).<\/p>\n\n\n
\n\/*\n * Protocol that defines the possible routes from the Articles module.\n *\/\nprotocol ArticlesWireframeInput {\n    func presentDetailsInterfaceForArticle(article: Article)\n}\n\n\n\/*\n * The Router responsible for navigation between modules.\n *\/\nclass ArticlesWireframe : NSObject, ArticlesWireframeInput\n{\n    \/\/ Reference to the ViewController (weak to avoid retain cycle).\n    weak var articlesViewController: ArticlesViewController!\n\n    \/\/ Reference to the Router of the next VIPER module.\n    var detailsWireframe: DetailsWireframe!\n\n\n    \/\/ MARK: ArticlesWireframeInput\n\n    func presentDetailsInterfaceForArticle(article: Article) {\n        \/\/ Create the Router for the upcoming module.\n        self.detailsWireframe = DetailsWireframe()\n\n        \/\/ Sends the article data to the next module's Presenter.\n        self.sendArticleToDetailsPresenter(self.detailsWireframe.detailsPresenter, article: article)\n\n        \/\/ Presents the next View.\n        self.detailsWireframe.presentArticleDetailsInterfaceFromViewController(self.articlesViewController)\n    }\n\n\n    \/\/ MARK: Private\n\n    private func sendArticleToDetailsPresenter(detailsPresenter: DetailsPresenter, article: Article) {\n        detailsPresenter.article = article\n    }\n}\n<\/code><\/span><\/pre>\n\n\n
3. When should you use VIPER?<\/h2>\n\n\n\n
When creating a project that has the potential to evolve, it’s important to think of a structure that will scale well and enable many developers to simultaneously work on it as seamlessly as possible \u2013 and the MVC structure might not be enough to keep your project sufficiently organized.<\/p>\n\n\n\n
It’s really common for developers to find themselves debugging a huge class, like trying to find a needle in a haystack. With the loose coupling between the objects that VIPER proposes, you’ll notice that:<\/p>\n\n\n\n