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 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