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