Models

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:

Request - parameters that need to be sent to the API request.

parameters that need to be sent to the API request. Response - intercepts the response from the API and stores the appropriate data.

- intercepts the response from the API and stores the appropriate data. ViewModel - everything that you need to show to the UI is stored here. For example, your API returns objects with 10 parameters, but you only need to show 4 of them.

Router

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:

Routing Logic Protocol - all the methods used for routing are kept under this protocol. Data Passing Protocol - a protocol that contains the data that needs to be passed to the destination controller.

Worker

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.

Interactor

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:

Business Logic Protocol - declare all the Interactor methods in this protocol, so they can be available for use in the ViewController. Data Store Protocol - all properties that should keep their current state are declared here. This protocol is mainly used in the Router to pass data between controllers.

Presenter

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.

ViewController

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.

Conclusion

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! 👋