Introducing Clean Swift Architecture (VIP)

Forget MVC, now!

https://clean-swift.com/clean-swift-ios-architecture/

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.

How about today?

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. 🚀

About the Clean Swift Architecture

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.

Installing the Clean Swift Template in Xcode_Clean Swift becomes more and more popular amongst iOS Developers. This short tutorial will show you how to install the…_medium.com

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:

• Models
• Router
• Worker
• Interactor
• Presenter

Communication

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.

Clean Swift (VIP) Flow Diagram

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.
• Response - 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:

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

Routing in Clean Swift (VIP) Architecture_Learn how to use the Router component properly_hackernoon.com

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:

1. Business Logic Protocol - declare all the Interactor methods in this protocol, so they can be available for use in the ViewController.
2. 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! 👋

Check out my latest project:

‎1x2 BET - Soccer Tips & Odds_‎HOT ODDS Each day, we generate a list of the hottest odds in the world. These are odds that have dropped the most…_apple.co

Read more stories on Medium:

Your ultimate guide to the Google Maps SDK on iOS, using Swift 4_Many iOS apps use Google Maps. This is a very common feature, so I have decided to prepare an ultimate guide on the…_medium.freecodecamp.org

SWIFT — Custom UIView with XIB file_Custom UIView with XIB file is a very common practice in iOS Development. Custom UIView classes don’t contain XIB files…_medium.com

How to add Spotlight support to your iOS app_A Swift tutorial that will make your app available in Spotlight search_hackernoon.com

Core Data Relationships_Understanding One-to-One and One-To-Many relationships_hackernoon.com

Understanding Auto Layout in Xcode 9_All you need to know about Auto Layout_hackernoon.com

Subscribe to my Newsletter: