VIPER Architectural Pattern

VIPER is an architectural pattern like MVC or MVVM, but it separates the code further by single responsibility, also known as an application of Clean Architecture to iOS apps. Apple-style MVC motivates developers to put all logic into a UIViewController subclass. VIPER, like MVVM before it, seeks to fix this problem.

Each of the letters in VIPER stand for a component of the architecture: View, Interactor, Presenter, Entity and Router.

• The View is the user interface. This corresponds to a SwiftUI View.
• The Interactor is a class that mediates between the presenter and the data. It takes direction from the presenter.
• The Presenter is the “traffic cop” of the architecture, directing data between the view and interactor, taking user actions and calling to router to move the user between views.
• An Entity represents application data.
• The Router handles navigation between screens. That’s different than it is in SwiftUI, where the view shows any new views.

With VIPER, you can group together the presenter, interactor, view, router and related code into modules.

Traditionally, a module would expose the interfaces for the presenter, interactor and router in a single contract. This doesn’t make a lot of sense with SwiftUI because it’s view forward. Unless you want to package each module as its own framework, you can instead conceptualize modules as groups.

Modules are a good way to keep the code clean and separated. As a good rule of thumb, a module should be a conceptual screen/feature, and the routers hand the user off between modules.