Setup the launchpad
In this walkthrough, we’ll learn how to use the VIP clean architecture pattern to develop apps for Apple platforms.
We will develop a Clean SpaceX app where we will be showingcasing information regarding the rockets which have been made and experimented with by SpaceX.
Compared to MVVM, MVC or VIPER the VIP architectural pattern is one of the least known patterns in iOS development. They’re basically different implementations of Uncle Bob’s Clean Architecture pattern.
VIP simply stands for View — Interactor — Presenter.
The VIP architecture for writing clean Swift code was introduced by Raymond Law. He created a clean-swift website where you can read about how to use VIP patterns in UIKit.
VIP was actually created to fix MVC, or Massive View Controllers, a common problem in UIKit apps where View Controllers become the main object where code is kept and they become drastically huge in that most if not all of your logic is kept within them. This can also cause a lot of issues for you later down the lane when your objective is to expand your app by adding more and more features. Furthermore, VIP is unidirectional which saves up the trouble of getting our code components to be mixed up with each other.
The View is generally your app’s UI. It role is to send requests to the interactor every time the user interacts with the UI.
The Interactor takes care of your app’s business logic, such as fetching or sending data from the network or saving data in a database. When the view requests something, the interactor does the processing and sends the result as a response to the presenter.
The Presenter handles the presentation logic. It formats the received data into view models suitable for display and then passes it to the view.
CleanSpaceX is a sample project I created for demonstration of clean architecture’s implementation. It majorly consists of only two Scenes ie Rockets and
Their names are pretty self-explanatory of what purpose they are serving, Rockets Scene is fetching the list of SpaceX rockets along with the details from their open source endpoints and
RocketDetails Scene is showing detail of specific selected Rocket.
Here you see the structure of the scene created with each component distinct from one another. So now let’s look at each one of them one by one. Before that take a quick preview of what we are gonna build.
In this component, all of the models related to the desired controller will be saved. It will be of type struct and mostly it will contain Request, Response, and
In the above model, you can clearly see structs for Request, Response, and ViewModel and from there it makes things pretty obvious.
Request would include parameters that need to be sent to any network call (which in our case is to SpaceX). The
Response would include parameters that are to be expected in response to our network call and
ViewModel is the section where the above parameters are mapped as per use case.
The router’s job is to perform all tasks related to transitioning and passing data between view controllers.
Above we are covering both of the cases where we are not only navigation to another view controller but we are passing some data along to our destination view controller. Note that there are two protocol defined named
RocketDataPassingis a protocol that contains the data that needs to be passed to the destination controller.
RocketsRoutingLogicis that protocol in which all the methods used for routing are kept.
The Worker component handles all the Network requests and responses. The Response struct (which we used in Models) will get the data ready for the Interactor. It will handle the success/error response, so the Interactor would know how to proceed.
The interactor is the most significant component of them all and works as a moderator between Worker and Presenter. Initially, it communicates with the
ViewController which passes all the Request parameters needed for the Worker. Before proceeding to the Worker, a validation is done to check if everything is sent properly. The Worker returns a response and the Interactor passes that response towards the Presenter.
Here note that a couple of protocols are being used named
RocketsBusinessLogic and they serve the following purpose:
RocketsDataStore— is used for passing data between view controllers
RocketsBusinessLogic— is used for declaring all the Interactor methods in this protocol, so they can be available for use in the ViewController.
After getting the Response from the Interactor, it’s time to format it into a ViewModel and pass the result back to the
ViewController. Presenter will be in charge of the presentation logic. This component decides how the data will be presented to the user.
Presenter There is only one protocol declared which stores the presentation logic methods. In the
presentFetchRockets() function a delegate method is being called that is declared in our associated view controller. This is how it connects itself with the view controller.
Now it’s time to see it all work, all the components have been aligned with one another but still, we require one last major step to perform in order for this entire flow to work.
Here as you can see that a simple table view has been declared along with its delegates which are being used to show fetched API data in the representable form.
The last step is to trigger the interactor which will eventually start our cycle where a request will be sent and we’ll get back a response from the Presenter. During this time if the user wants to navigate somewhere then we’ll bring the
Router into action.
You can get the entire project from this link. Feel free to play around with it and let me know any recommendations. Please note that we can also install a clean swift template in our Xcode which will allow us to create a complete Scene using the editor.
For learning how to configure Xcode please refer to this walkthrough.