Agent Skills: Stop Stuffing Workflows Into Your Rules File
Salatiel Lima | Apr 29, 2026
Summary
- VIPER offers a cleaner, more elegant alternative to MVC and helps avoid massive view controllers, but it is more complex and can produce more code than MVC if not implemented correctly.
- The architecture involves significant bureaucracy and boilerplate, such as implementing handlers across View, Presenter, Router, and Contract files, which can scale painfully across a full application.
- VIPER is not recommended for teams lacking strong knowledge of development practices, protocol orientation, and object orientation, nor for projects with very short timelines due to its long ramp-up time.
- The decision to adopt VIPER depends on factors like team openness, expertise, project urgency, and project size; trying it on a personal project first is suggested before committing.
If you are familiar with iOS trending topics, you certainly already know VIPER. It’s an alternative to MVC (Model View Controller) pattern and it was already explained in our blog. If you haven’t read yet, I strongly recommend you to do it.
There is a lot of content on the web talking about the VIPER miracles and how this new architecture is much better than the previous ones. But you always have to ask some questions before putting your efforts and resources into an “unknown path”.
On this article, I will clarify some questions about the VIPER workflow and if you should be using it on a new project – or even on your old running app.
VIPER x MVC
Despite all the critics, Apple’s MVC architecture is still a great pattern to use. It’s simple, easy, widespread and probably the most reliable architecture to use. All the iOS frameworks are made over the MVC and developing while using this concept is very flowing.
It’s a really, really simple architecture with three basic modules, Model, View, and Controller. You don’t get stuck on questions like “Where can I put this code? Interactor? Presenter? Should I pass this to Router?”.
But like Uncle Ben says:
“…with great power comes great responsibility.“
With all the MVC simplicity, we developers sometimes have to create a massive view controller and that is what VIPER promises to solve and it does extremely well by the way. VIPER is clean: you can look at your code and say “well this looks pretty and fancy!” and it is indeed an extremely elegant solution.
But there is a downside: its complexity. For a beginner, it can be confusing and if you don’t really know what you are doing you can end with more code than you would have with a massive view controller.
Bureaucracy
Protocols, they are great! Seriously, my work has become so much better since Swift implemented it. Their common use is to define the behaviors of an object and VIPER uses that approach to declare behaviors on its modules.
But sometimes, all this bureaucracy can get a bit painful. To call a new screen, for example, you have to implement the action handler on your View, create a function on the Presenter, which will simply call the Router’s function to then call your new screen. Besides all that work, you will have to implement the signature of this new functions in the Contract file.
If you scale that for your entire application, the amount of boilerplate can be massive and not pleasant to be implemented.
The dev skills
If you are working on a team, the people that work with you have different sets and levels of skills, right?
If you have a team composed by devs without a good knowledge of good development practices, architecture, protocol orientation, object orientation, etc – then maybe implementing VIPER is not a good idea.
This architecture is a little bit more complicated than MVC, so before you start using it, it’s crucial for your team to have a good acknowledgment in how to build iOS apps, so focus on improving your team’s skills before.
Ramp up time
Does your project have really, really, short timelines? Keep away of VIPER!
One of my biggest problems with VIPER is the ramp up. To start a project, you lose a lot of time by setting up the basics. Of course that, with more expertise, your time will decrease But, for your first project with VIPER, choose a project with an environment that you can take time for thinking, testing and implementing.
Wrapping up
If you stayed with me until now, you already know the answer to the article title. But if you’re a quick reader and just want a summary, the answer is: It depends.
Before choosing between VIPER, MVC, or any other architecture you should answer a few questions:
- Is my team open to this new approach?
- What is the level of expertise of my team?
- Am I in a hurry with my new project?
- Can I afford the cons of this new architecture?
- Will this project gonna be big? or become bigger?
- And again, is my team REALLY open to this new approach?
If you have more “nays” than “yays” maybe a good path is learning more about the architecture and implementing it on a personal project, to have a real perception about the implementation.
Always remember: it’s not because a topic is a Hypertrend that is going to fit well with your solution or that it’s better than the one you are currently using.
That’s all folks! Have you got any considerations? Questions? Experiences? Share them on comments. See ya!
FAQ
What is VIPER and how does it compare to MVC?
VIPER is an alternative to the MVC (Model View Controller) pattern. While MVC is simple, easy, widespread, and reliable with three basic modules (Model, View, and Controller), VIPER is a cleaner and more elegant solution that addresses the issue of massive view controllers in MVC. However, VIPER is more complex than MVC.
What are the downsides of using VIPER?
VIPER's main downsides are its complexity and bureaucracy. Beginners can find it confusing and may end up with more code than with a massive view controller. Additionally, simple actions like calling a new screen require implementing an action handler on the View, creating a function on the Presenter, calling the Router's function, and implementing signatures in the Contract file, which can lead to massive boilerplate when scaled across an application.
When should I avoid using VIPER?
You should avoid VIPER if your team lacks good knowledge of development practices, architecture, protocol orientation, and object orientation. You should also keep away from VIPER if your project has very short timelines, since the initial ramp-up takes a lot of time setting up the basics.
What questions should I ask before choosing VIPER?
Before choosing VIPER, MVC, or any other architecture, ask: Is my team open to this new approach? What is the level of expertise of my team? Am I in a hurry with my new project? Can I afford the cons of this new architecture? Will this project be big or become bigger? And again, is my team REALLY open to this new approach?
How can I get started with VIPER if my project isn't a good fit?
If you have more 'nays' than 'yays' when answering the key questions, a good path is to learn more about the architecture and implement it on a personal project to gain a real perception of the implementation before applying it to a professional project.
About the author.
