Senior iOS Developer
A couple of years ago, all of the iOS apps were small containing less than 10 screens. The codebase was small, storyboards were working excellent, and it was easy to maintain your project. From an architectural point of view, MVC was doing a great job.
Today, we are facing big technological advancements and an insane app market growth. In other words, apps are becoming big and complex. We are working on projects that contain 20, 30 or even 40 screens making it impossible to be maintained with MVC.
As technology moves forward, so should we (developers).
Recently, I really got tired from MVC and started looking for a new architecture. After a short research, I have noticed the Clean Swift architecture and instantly fell in love with it! This architecture was exactly what I was looking for. 🚀
Clean Swift (a.k.a VIP) is Uncle Bob’s Clean Architecture applied to iOS and Mac projects. The Clean Swift Architecture is not a framework. It is a set of Xcode templates to generate the Clean Architecture components for you. That means you have the freedom to modify the templates to suit your needs.
In an MVC project, your code is organized around and grouped by models, views, and controllers. In Clean Swift, your project structure is built around scenes. Here is an example how does one scene looks like. In other words, we will have a set of components for each scene that will "work" for our controller. These are the components:
The communication between the components is done with protocols. Each component will contain protocols which will be used for receiving and passing data between them. Worker communicates with Interactor, then Interactor with Presenter and Presenter with ViewController.
I have also designed a Flow Diagram so you can get a visual representation of the relations between these components.
We will store all the models related to the controller. The Models class will be related to each component, as you can see in the Flow Diagram. It will be of type struct and mostly it will contain Request, Response, and ViewModel structs.
For this example, let’s assume you are working with an API call on this scene. You will need the following structs:
The router takes care for the transition and passing data between view controllers. Also, you can use segues, unlike the VIPER architecture where you can’t do that.
The generated router file comes with example methods used for navigating and passing data. The routeToSomewhere() method is an example that shows us how to transition to another view controller by either using a segue or by initializing the destination view controller.
There are two protocols declared:
The Worker component will handle all the API/CoreData requests and responses. The Response struct (from Models) will get the data ready for the Interactor. It will handle the success/error response, so the Interactor would know how to proceed.
This is the “mediator” between the Worker and the Presenter. Here is how the Interactor works. First, it communicates with the ViewController which passes all the Request params 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.
The Interactor also contains two types of protocols like the Router:
Now that we have 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.
There is only one protocol declared in this component which stores the presentation logic methods. In the presentFetchResults() function you can see that I am calling two delegate methods that are declared in the view controller and are expecting a proper ViewModel to present it to the UI. (1) handling the success case, (2) handling the error case.
We are done with the components. I hope that you have understood so far what is going on. But, we are not done yet. This is the last step, and it’s about bringing the components to action. As you can see in the Flow Diagram above, the ViewController will communicate with the Interactor, and get a response back from the Presenter. Also, when there is a need for transition, it will communicate with the Router.
We have created two delegate methods named successFetchedItems() and errorFetchingItems(). These methods are providing us with the proper ViewModel, so we can handle the two cases separately.
I hope that you have enjoyed this tutorial and that it helped you understand the new and exciting Clean Swift architecture. Tried to explain it as detailed as possible. I know that for most people MVC is the comfort zone, but once you get out of it and try something new you will be amazed by the results. Clean Swift contains a bit more coding and few more files than MVC, but that makes it super easy for maintenance and writing test cases. 😎
If you have any questions regarding this architecture, please don’t hesitate to send me a comment below, and I would be glad to assist. Also, don’t forget to 👏 or share this with your friends who are also struggling with MVC. 🤓
Thank you for your attention! 👋
Create your free account to unlock your custom reading experience.