Implement the Clean VIPER Architecture in iOS

Learn how to implement the architecture!

Image for post
Image for post
Photo by Captureson Photography on Unsplash

Difficulty: Beginner | Easy | Normal | Challenging
This article has been developed using Xcode 12.0, and Swift 5.3

I’ve previously written an article explaining the use of VIPER for iOS applications. That particular article lacked one thing — a full example of the architecture and how we might traverse from one view to another and correctly inject dependencies. We can put that right now!

In steps this article to describe the implementation of the article using Swift. Let’s get started!

Prerequisites:

  • You will be expected to be aware how to make a Single View Application in Swift.
  • The implementation takes adavantage of my network code Single View Application, and you may choose to look through that to understand what is going on with the netwroking here

What this article is, and what it isn’t

One of the main disadvantages touted surrounding the VIPER architecture is that the communication between objects can become confusing and feel rather confusing.

This implementation will cover a very clean case of the VIPER architecture to give you something to work with and build your own Apps on top of. That is, we are building a concrete example representing the following

Image for post
Image for post

I’ve set about testing all of the code for the UITableView but I've left the DetailView section as an exercies for the reader.

There are some force-unwraps in the tests — this isn’t an accident and I tend to do this for non-production code. You may choose to write your code differently.

The code calls “https://jsonplaceholder.typicode.com/photos" for the main tableview, and then draws images from the JSON String returned. This particular code does not use my API manager and might have been better had it done so, but this code is not production ready.

The setup

The SceneDelegate sets the stage for our VIPER implementation. In this case, we have used a UINavigationController to hold together our code.

The VIPER

The entitiy is perhaps the easier component of VIPER, and gives us the following

which conforms to the decodable protocol and equatable.

The wireframe conforms to a protocol and sets up the view controller and it’s dependencies.

designing each class to it’s interface protocol which allows mocks to be formed (more on this later).

We create the TableViewController which conforms to it’s own protocol

The presenter presents the data for easy display by the dumb viewcontroller

The interactor is the place where the network calls are made.

So how can this be tested?

The Testing

Using Mocks is really important in swapping out the real (for example interactor).

MockTableViewPresenter

MockView

MockTableViewWireframe

which then lets us write the following tests TableViewInteractorTests

TableViewPresenterTests

Advantages

VIPER makes it easier to test code — by making a modular solution for your App. The architecture should help you to enformce the single responsibility principle and help to reduce the load on view controllers.

Disadvantages

Communication between objects can be convoluted and complicated. Without care, modules can become too large and do too many things. Potentially some implementation of VIPER violate the single responsibility principle!

Conclusion

VIPER isn’t all that difficult!

However it seems to have fallen a little bit out of fashion recently — so beware of that before you pitch it to your team at your place!

If you’ve any questions, comments or suggestions please hit me up on Twitter

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store