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:
- 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
- Most closely resembles the Controller of MVC.
- Entity: the model.
- 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:
- It owns the
Presenter(and other VIPER components that are needed).
- 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);
- it connects the
viewController.eventHandleroutput port to react to user events;
- 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|
|May 9 2022|
|Oct 15 2016|
|Aug 12 2016|
|Aug 9 2016|
|Mar 25 2016|
|Mar 18 2016|
|Dec 14 2015|
|Oct 13 2015|
|Jul 18 2015|
|Jun 19 2015|
|Mar 13 2015|
|Jan 2 2015|
|Dec 18 2014|