MVP+R Architecture with Swift

There are a lot of articles with different design patterns and architectures for iOS development. By default, Apple provides us MVC (Model View Controller) architecture. It was good enough to create great apps at the beginning of iOS development history, but these days, apps became with complex functionality, which requires to keep a lot of services, frameworks, and other business and presentation layers. It’s quite hard to support and extend functionality of the app with this architecture, so the better solution will be to use one of another architectures: MVP, MVVM, VIPER or MVI. In this tutorial I will show one of my favourite architecture solution for iOS: MVP+R.

MVP+R is Modal View Presenter architecture with Router to handle routing between screens.
You may ask:

Why do we need Router if we can handle it with segues which Apple provided us?

It’s quite hard to work with Storyboards and Segues in team with 2 or more developers. Resolving the conflicts in Storyboard during merge or rebase is not pleasant process :)
Router resolves this problem when we make screen navigation in code and it’s also works as Configurator for another screen.

Here is the diagram of the Architecture:

You can find sample project on Github. It’s simple app with fetching track list by search from Last.fm and iTunes.

Each screen contains 5 files:
1) ViewController
2) Presenter
3) Router
4) Contract — file that contains protocols for each screen
5) Storyboard file with one UIViewController

View

Let’s take a look on first screen MusicSearchViewController.swift:

As you can see the MusicSearchViewController has a reference to MusicSearchViewOutput (aka Presenter) protocol and all UI events (such as IBActions, Button touches and so on) are passed to MusicSearchViewOutput.

MusicSearchViewController also implements MusicSearchViewInput protocol which has update function that is called from the Presenter.
View should be passive as much as possible. It is only responsible for notifying Presenter with UI events and updating the content, that’s it :)

Presenter

Now let’s see how Presenter works.

As you can see from the code above — Presenter contains all business logic and implements MusicSearchViewOutput protocol. When user taps on search button, we update view with loading state and Presenter performs search requests from iTunes and LastFm services. After we got the response — we map Track records into MusicTableViewCellModels and update the View. So all logic should be performed in this class.

Router

Now let’s see how we can work with Router.

As you can see, Router implements MusicSearchViewRouting protocol.
When user taps on UITableViewCell, View tells Presenter that some cell with image has been tapped. Presenter gets the image and tells the Router to show the TrackImage screen with selected image. Router creates new View, Presenter, Router and sets the dependencies. After all steps has been completed, Router presents new screen.

So, that’s how I work with MVP+R architecture. If you have any questions feel free to ask me in the comments.