iOS design patterns — Part 2 (VIPER)

In the first part, here, we toured on MVC, MVP and MVVM, three of the most famous design patterns used in iOS application development. This final part will explore the VIPER design pattern.

Lately, VIPER is treated as the extended version of MVVM which provides more modularity as compared to its contenders.

iOS Design Patterns - VIPER.png
VIPER architecture
It basically comprises of —
  1. View(Controller) which presents UI to the user and forwards the actions on UI to the Presenter to handle.
  2. Presenter handles the UI actions sent by View. This handling is totally independent of the UI controls. In addition to this, Presenter takes help of the Interactor to process the model(Entity) if need be.
  3. Interactor mainly contains the business logic and integrates with the other parts of the application. It also owns and manages the Entity.
  4. Entity is just a dumb data structure to store data. As said, it is owned by the Interactor and concealed from the other modules.
  5. Router is a special component in the VIPER architecture, which explicitly deals with the navigation actions coming from the Presenter. The router can very well inject the dependencies through Presenter. Navigation (Wireframing) is the only responsibility that Router takes care of.

As a good practice, iOS applications contain multiple storyboards, each representing the unique feature of the application. VIPER could very well be used in the same aspects. Instead of architecting a single screen, if a complete functionality, like creating a profile for the user, is architected through VIPER, the code will be finely modular and can be tested correctly. VIPER perfectly works in the direction of separating the responsibilities.

Separation of responsibilities makes TDD(Test-Driven-Development) easier. In VIPER, test cases can be written against the functionality provided by the Interactor, as Interactor is the component which deals with the business logic.

With these benefits, it does come with the pain of writing too many classes and maintaining them. Also, forwarding the events in the hierarchy is the duplication sometimes. VIPER comes with the strict learning curve too. There is a huge difference in the Apple’s MVC and the VIPER.

In my recent visits to the dev conferences, I have seen many developers and tech leads experimenting with this pattern and in their experiences, they have been highly benefited with it. In one such conference, Sonam Dhingra gave a wonderful talk on Using VIPER to build a framework.

Sonam Dhingra presenting about VIPER

Conclusion

The design is the evolving process and design patterns are the output of it. As we all know there is no perfect design pattern which works for all the use cases and hence we have so many alternatives available. At the end, it totally depends on us, the developers, to think and decide, considering all the pros and cons. There is no obligation to use just one design pattern in the application, we could very well use a mix of all as per our need.

Leave a Reply