Today we're going to analyze the VIPER iOS Architecture and decide if we can call it a Software Architecture or a Design Pattern like the MVC, MVVM and MVP design patterns we talked about in the previous video.

VIPER was introduced to the world in 2014, and the main goals for the architecture were Testability and to fix the Massive View Controller problem. Later on, a more detailed article was released in one of the objc.io Issues.

The detailed article explains the motivations for using VIPER:

Testability
Fixing the Massive View Controller issues
Application Design based on Use Cases
Fitting well with Platform Frameworks (like UIKit)
Building features as Independent Modules

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

The VIPER diagram defines a structure which seems like an architecture but may create a limited outlook of the application. Even though VIPER is presented as an architecture to solve the "MVC" limitations (where components can only be seen as Models, Views or Controllers), VIPER may have the same limitations (where components can only be seen as Views, Interactors, Presenters, Entities, or Routers).

In reality, the authors say that VIPER is "mainly" divided into those types, but can have less or even more layers of separation, as needed. Unfortunately, many developers end up trying to follow the "acronym template" (like it happens with the MVC design pattern).

VIPER can solve the Massive View Controller problem and make your code more Testable, but it doesn't solve the "Software Architecture" problem. By following the VIPER template, we may end up with Clean Code, but Spaghetti Architecture!

For example, let's have a look at the Todo List sample project dependencies diagram.

Todo List sample project class and module dependencies diagram.

As you can see, there are arrows pointing everywhere. Even crossing module boundaries. Dependencies look out of control, so changes to the software can break multiple modules (and of course, multiple tests).

VIPER was introduced as an iOS implementation of Uncle Bob’s Clean Architecture. If we compare the two, they have similarities, especially in their layers names. However, a closer look shows that, at least by analyzing the VIPER Todo List example, they don’t share the same structure and goals. In Uncle Bob’s Clean Architecture, the Frameworks and Drivers (e.g. UIKit and CoreData) are just “details” or “plugins” to the Business Logic Layer. Instead, in common VIPER implementations, the frameworks end up at the center of the application. (There are also crucial data flow differences that Paul Stringer explains in this article.)

VIPER Todo sample project “Onion Layers” diagram separate by features and dependencies with the frameworks at the center

We believe that software architecture is less about your responsibilities and more about how the components communicate with each other and how they depend on each other. What is coupled and why? What is decoupled and why? What is hard to change and why? What is easy to change and why? How is the data flowing between layers – is the data going in one direction? two directions? multiple directions? Can we support short and long-term business goals?

Regardless if we're following or not some sort of named architecture like VIPER, our software is structured in many components that can be coupled or decoupled. This software structure or the components structure is our architecture.

Our codebases are like living organisms, and they're changing all the time. So does the architecture. It's constantly changing. And It can move in a positive or negative direction.

Modularity, for example, is a good architecture trait, but not all architectures are modular. If we don't have modularity in our systems, it doesn't mean we don't have an architecture. However, we might quickly find out that the lack of modularity prevents us from moving fast and prevents us from achieving key business metrics. For example:

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

At Essential Developer, our main drives are Empathy, Integrity, and Economics. Business metrics are part of Economics. When we make decisions such as the system architecture, we must care about Economics. And we do believe that Software Architecture has a strong correlation with Product Success. Product Longevity. Product Sustainability.

In our experience, MVC, MVP, MVVM, and VIPER are good design patterns when used with care. However, they are not enough to define the “Software Architecture” of our systems.

For more, visit the Clean iOS Architecture Playlist.

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