App modularization with RIBs architecture

An Tran • July 8, 2019


App architecture

Every apps are developed following one or some kinds of architectures or design patterns. Choosing an architecture for an app depends on a lot of factors: team size, project size, type of the apps, release cycle etc... And the chosen architecture should be continuously reevaluated when the app grows.

MVC has been the standard architecture for iOS apps for a long time. But due to the "massive view controllers" problem, community has come up with many alternative architectures such as MVP, MVVM, Viper, RIBs, Redux etc .... with more or less the same goals, separate business logic and app logic into different components to aid SOLID principles.

I have been working intensively with MVVM in the last four years at my current company. With a team of 5-7 developers, MVVM served us quite well. We often have a setup where two developers work together on the same feature. One of them focus on the view controller (UI) part, the other on the service, view model part.

But MVVM comes up with some issues too:

Since our team as well as the complexity of our app is growing fast at this moment. I have taken a look for an alternative architecture for our app.

The goals are:

VIPER and RIBs come into my consideration. Since RIBs seems to be an improved version of VIPER, I decided to create sample project using RIBs to evaluate it.


RIBs is a variation of VIPER that is introduced by UBER in 2017. From their blogs, the motivations for the creating RIBs are:

RIBs are usually composed of the following elements, with every element implemented in its own class:


The sample app will fetch images from using a search term entered by users. The app has a simple navigation step from the result list screen to the detail screen.

The code is available in github:

Some benefits from RIBs that I can observe:

But there are some downside too:


I can see that RIBs architecture can bring great benefits to big apps and big teams where components can be developed and tested by different developers in parallel. It is also suitable when your teams create multiple apps using the same components with similar business logics. For smaller apps and smaller teams, it might be overkilled and will slow you down at the beginning.

Further readings