/ swift

VIPER architecture with Swift

Decouple - separate, disengage, or dissociate (something) from something else.

Why do we need it?

Decoupling makes our code easier to maintain because changing one part of the code will not cause issues with the rest of the code. It also simplifies code testing, especially unit testing. If many developers work on the same project, it is easier to divide the work into independent tasks.

Module - a distinctive attribute or aspect of something, is just another word for a feature. A Module in iOS presents itself to the outside world as a standard UIViewController

That is where VIPER enters the scene.
VIPER is just a way to separate an application into distinct layers.

View simply holds the layout. It can be stored as a XIB file, a storyboard, or even a text file.

Interactor is responsible for networking operations, persistence, business logic, data management and so on.

Presenter is responsible for strictly updating the view (EventHandler) and Wireframe initializes modules and defines the navigation to the next module.

Entity is the object model.

Router is in charge of navigation.

Let's see what happens with VIPER when a user taps a button on the screen...


View -> ViewController -> EventHandler -> Presenter -> InteractorInput -> Interactor {do some long operation} ... response ... Interactor -> InteractorOutput -> Presenter -> Wireframe -> ViewController -> View

To glue all the parts together VIPER is extensively using protocols.

EventHandler is a protocol that connects a View Controller to a Presenter.
InteractorInput and InteractorOutput are the protocols that associate a Presenter with an Interactor.

Some helpful links:

A to-do list example app that uses VIPER architecture

Intro to VIPER architecture by objc.io