Implement the Clean VIPER Architecture in iOS
Learn how to implement the architecture!
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!
- 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
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.
SceneDelegate sets the stage for our VIPER implementation. In this case, we have used a
UINavigationController to hold together our code.
The entitiy is perhaps the easier component of VIPER, and gives us the following
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?
Using Mocks is really important in swapping out the real (for example interactor).
which then lets us write the following tests TableViewInteractorTests
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.
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!
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