VIPER

Go to the Wiki Overview

VIPER is an approach to software architecture in iOS apps that was at its peak popularity around 2015.

This is different from a mere Design Pattern because it provides a lot of scaffolding to prepare a large chunk of functionality.

VIPER
VIPER, illustrated. Picture credit: Jeff Gilbert, Conrad Stoll, and Lin Zagorski of Mutual Mobile, used with permission.

VIPER stands for:

  • View.
    • Is being told what to display by the Presenter.
    • Its affordances (interactive UI components) tell the Presenter about actions that the user performs.
  • Interactor: contains the business logic.
  • Presenter: the thing that assembles the view.
    • Is instructed by the Interactor.
    • Reacts to user input in the view. In iOS examples, it’s the eventHandler of a UIViewController.
    • Most closely resembles the Controller of MVC.
  • Entity: the model.
    • “Entity”, in the verbal tradition that informed the terms of Domain Driven Design, is chiefly about persistent data: things with an identity over time. Not a model in the MVC sense, which merely states that it’s the data that’s displayed, but with permanence.
  • Router: navigation logic.

You’d have many “VIPER”s per app, not just one of each. They form a module (in the broadest sense). You can think of these modules as iOS scenes.

If you have many of these components, each with their 5 sub-components that correspond to the “VIPER” acronym, then you need something else to hold it all together. Unlike the ouroboros snake, the “VIPER”s aren’t just biting their tails and form a huge circle of connected serpents. (Sorry for stretching the metaphor a bit! 🙂)

Instead, you’d have entry points via so-called Wireframes. Wireframes implement the Router responsibility to transition from scene to scene. The term “Wireframe” struck, I believe, because its job is to act as a Router between scenes by connecting (‘wireframing’) all the pieces needed for diplay.

The classic iOS example of a Wireframe entry point performs these things:does:

  1. It owns the Presenter (and other VIPER components that are needed).
  2. When being routed to, it creates the UIViewController (and keeps a reference to it as long as it’s on screen, or forever, depending on the view lifecycle);
  3. it connects the Presenter to the viewController.eventHandler output port to react to user events;
  4. Finally, it presents the view controller – modally, for example, or by pushing it onto a navigation stack.

The term that stayed with me from experimenting with VIPER is the role of the “Presenter”: a service that configures a view (or view hierarchy) to display its stuff.

This can pair nicely with MVVM, if you think of the “view model” as a data structure that represents the view. Then the presenter assembles this tailor-made representation and passes it to the view. Depending on the data flow of your app, this role can also be accomplished by a regular Factory (or simply a custom initializer in Swift).

Posts on the topic

Apr 17 2023

VIPER Added to the Wiki

May 9 2022

Dependency Injection and the Tree of Knowledge

Oct 15 2016

Clean Swift aka VIP Architectural Approach

Aug 12 2016

When You Code, You Design Both Structure and Information Flow

Aug 9 2016

MVVM Is Quite Okay at What It Is Supposed to Do

Mar 25 2016

5 Heuristics for "I have a complicated nested view controller setup. How do I handle passing data?"

Mar 18 2016

VIPER by Experience: How to Set Up an iOS Project

Dec 14 2015

iOS View Architectures and VIPER Explained

Oct 13 2015

How to Move Bootstrapping Code Out of AppDelegate

Jul 18 2015

How Coursera Uses VIPER to Architect Transitions Between App Features

Jun 19 2015

So I've finished my model, now what?

Mar 13 2015

VIPER iOS App Architecture Approach

Jan 2 2015

Storyboard Segues VS Tell Don't Ask Principle

Dec 18 2014

Making Good Use of Singletons in Refactoring the iOS App Calendar Paste