Today we're going to analyze the VIP (Clean Swift) Architecture. And, as we did in previous videos with VIPER, MVC, MVVM, and MVP, we will decide if we can call VIP a Software Architecture or a Design Pattern.

The Clean Swift Architecture or, as also called, "VIP" was introduced to the world by clean-swift.com and, just like VIPER and other patterns, the main goals for the architecture were Testability and to fix the Massive View Controller problem.

The name VIP can be confused with VIPER, and interestingly enough the creators of VIPER almost called it VIP but decided to drop the name because it could stand for “Very Important Architecture,” which VIPER creators thought it was derogatory.

VIP is very similar to VIPER as both originated from Uncle Bob's Clean Architecture ideas.

So can we consider VIP a Software Architecture or just a Design Pattern?

The VIP diagram describes its main structure, which explains its acronym definition: the ViewController/Interactor/Presenter relationship, or as they call it: The VIP cycle.

The VIP cycle differs from the VIPER relationship model described in our previous video. In VIPER, the communication between Interactor and Presenter, and View and Presenter is bidirectional.

Instead, VIP follows a unidirectional approach, where the ViewController talks to the Interactor, the Interactor runs business logic with its collaborators and passes the output to the Presenter, and the Presenter formats the Interactor output and gives the response (or view model) to the ViewController, so it can render its Views.

Does this unidirectional communication model define an architecture? Also, are those 3 components (the ViewController, Interactor, and Presenter) enough to describe the Application Architecture?

It may seem like an architecture, but the VIP cycle is such a limited outlook of the application that we consider it a Design Pattern. And this design pattern has a name already: MVP. Regardless of what we call it, the MVP design pattern is not a software architecture.

However, VIP or "Clean Swift" has more components than just ViewControllers, Interactors, and Presenters, for example, Data Models, Routers and Workers.

Like VIPER, the Clean Swift author describes that VIP can have less or even more layers of separation, as needed. But the core must follow MVP or the VIP cycle! So the VIP cycle sounds more like an organizational design pattern that can solve the Massive View Controller problem and make your code more testable, but it doesn't describe the big picture or the “Software Architecture.”

VIP or Clean Swift, just like VIPER and other patterns, is trying to solve class dependency issues like the Massive View Controller and testability, rather than module dependency issues, like modularity. With the described Clean Swift components, we may end up with testable code but Spaghetti Architecture.

VIP also encourages the use of templates to "facilitate" its implementation. It can be very convenient to have templates, but, at the same time, it may create a limited framework to think. We don't believe there's a design pattern or "template" that can solve all the problems and can be infinitely extended. We believe that, instead of trying to fit every problem into a template, every software architecture must be carefully crafted to solve the system challenges. For example, some systems would benefit more from an Event-Driven (Producer/Consumer) streaming model where other systems would not.

Let's have a look at the Clean Swift sample project (CleanStore) dependencies diagram.

CleanStore sample project class and module dependencies diagram.

As you can see, there are arrows everywhere, crossing module boundaries, so changes to the software can break multiple modules (and of course, numerous tests...).

In the Clean Swift sample app, the application is separated in scenes (or modules). There’s a List Orders Scene, Create Order Scene and Show Order Scene. A higher level look at the modules dependencies shows that scenes are highly coupled with each other and with other system’s components.

High-level modules dependencies diagram shows a highly coupled architecture.

Another way to look at the application architecture is to examine its modules in a circular form so we can see the dependencies between the modules. The closer to the center, the more abstract and independent the module is.

High-level modules dependencies diagram shows a highly coupled, monolithic architecture.

Different than Uncle Bob’s Clean Architecture, we can see services, frameworks, and drivers in the core rings. Also, inside each scene, some Interactors might contain business logic, and they depend on frameworks and other services. Throughout the codebase, we can even notice that core models are used in all levels of abstraction (UI/Presentation/Business Logic/Routing/Services/Workers) which is a no-no in Uncle Bob’s Clean Architecture.

The VIP sample app architecture is a highly coupled and monolithic architecture. If we want to create a somewhat testable monolith, it might work well. However, we might quickly find out that the lack of modularity prevents us from scaling the team, moving fast and prevents us from achieving key business metrics. For example:

Deployment Frequency
Estimation Accuracy
Lead Time for Changes
Mean Time to Recover

As explained in the previous video, we believe that software architecture is less about types, classes, and even responsibilities and more about how the components communicate to each other, how they depend on each other, and what is the shared understanding of the senior developers regarding: What are the important parts? What is coupled? What is decoupled? What is hard to change, What is easy to change? How is the data flowing between layers and why – is the data going in one direction? Two directions? Multiple directions? Can we support the business short and long-term goals?

We would like to reinforce that our codebases are like living organisms and they're changing all the time. So does the architecture. It's continually evolving, and there are no templates for that.

At Essential Developer, we do believe software architecture has a strong correlation with Product Success, Product Longevity, and Product Sustainability. We advise professional developers to learn from Uncle Bob's Clean Architecture, VIP, VIPER, MVC, MVVM, MVP, and other patterns, but not try to copy and paste solutions. Remember: Every challenge is different, and there are no silver bullets.

VIP, VIPER, MVC, MVVM, MVP, as design patterns, can guide you towards more structured components. However, they don't define the big picture or the Software Architecture. So, use them with care!

For more, visit the Clean iOS Architecture Playlist.

Subscribe now to our Youtube channel and catch free new episodes every week.