iOS Architectures: Should I use VIPER?

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!