How VIPER changed iOS development

(At least for me…)

I have been developing iOS apps for the past 5 years, much has happened then in the world of iOS development. Objective-C is starting to (slowly) be replaced with Swift and if you don’t master Auto Layout yet, you should definitely consider it heavily. However as much as something changes I always have this gut feeling, that programming for iOS could be done better, cleaner, and that it has nothing to do with the OS itself, or even how Apple develops their APIs, but instead how you think your code, and ultimately how you structure it.

Every time I start a new fresh project, looking at that clean Xcode project I always think “I will get it right this time”, you start coding, after a few weeks you have some solid architecture in place, the app runs with no issues but you still can’t figure out how to effectively unit test everything. You let it go, you unit tested the essentials so everything should be working correctly. Then your Project Manager comes in, with that look in his face which stinks of change requests from the customer and you already start shivering. Your clean, beautiful code, will need some changes. He introduces you to new functionality and you start thinking of how much that View Controller will change, how much it will grow, how much you will hate that code. As any good developer out there you followed all the best practices, MVC, MVVC to architecture your app, but you now reached that infamous Massive View Controller problem.

Meet VIPER

V.I.P.E.R stands for View, Interface, Presenter, Entity and Route and it represents a new pattern that follows the Clean Architecture on iOS. It divides your application logic into smaller layers of functionality, each of them with a strict, predefined responsability. The aim of this article is not to explain you how the pattern works (you can read more about it here), instead to give you my reactions on it, and how I actually fell for it.

First Impression: Holy mother of files!

When I started implementing VIPER on my own projects, my first reaction was “this is way too many files”, I was feeling overwhelmed with the amount of source code files I needed to add into my XCode project just to add a simple screen. The multiple layers that compose the VIPER architecture makes it so, but often in life when something feels complicated, it’s just because you still doesn’t fully understand it. This multitude of files is what will save you in the end.

Second Impression: Bring on those change requests!

Dividing the view into a single layer of responsibility, delegating to the presenter what to show, when to show, depending on the business logic determined by the Interactor made me realize early on two things: 1) If I need to change something I now only need to change one, maybe two layers of responsibility, and 2) Since now source code files get so small it gets easier and easier to manage, and versioning control becomes a breeze, because I can work on the View layer, while a fellow cowork takes care of the Interactor and Data Managers.

Third Impression: Unit Tests that actually test

VIPER got me finally on this last point. Since components in VIPER get to be so small they also get easily testable. I can test business logic without mixing it with View related code which produces cleaner, and smaller test units.

Fourth Impression: Modules, Modules, Modules

You can think of a VIPER app as a set of modules, a module represents a set of functionality within your app, and each module has it’s own View, Interactor, Presenter and Wireframe (Route). Each modules communicate with each other via the Wireframe and should work independently of each other. This improves code reusability and helps you to think your code before actually getting into code. When defining your modules you need to start decoupling the whole app into smaller parts, which brings you to thinking about this parts in more detail and with less clutter.

Final Thoughts

VIPER has a steep learning curve, for simple projects it can be too much, but in the case that your project will grow with time and where you can expect a lot of change requests, the time it takes to take off may actually help you a lot along the way. As anything in life, the best way to say if it works for you is to get a feeling for yourself, so go ahead and give it a try!