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.
Originally published at www.essentialdeveloper.com.
We’ve been helping dedicated developers to get from low paying jobs to high tier roles – sometimes in a matter of weeks! To do so, we continuously run and share free market researches on how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.
Let’s connect
If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.
Top comments (0)