RIBs

When I joined my current company, I have been asked to look into the RIB’s architecture as the very first assignment. I have neither worked on it previously nor learned about it.

I started learning RIB’s as if it is new programming language for me, as it looked very strange architecture to me.

As a developer we all know, every app is developed following some kind of architectures or design patterns. Choosing an architecture for an app depends on lot of factors such as team size, project size, type of the apps, release cycles etc… And the chosen architecture should be continuously re-evaluated when the app grows.

Let’s see why we should decide to choose RIBs over other architectures and what problems does it resolve.

First of all let’s see what exactly RIB is ???

RIBs is a Cross platform architecture mobile framework, developed by Uber in order to develop a clean architecture through which app will be completely driven by business logic and the business logo will be completely decoupled from view tree.

RIB’s is a framework — where in, MV* and VIPER are architecture patterns.

About RIBs:

RIBs is a variation of VIPER that is introduced by UBER in 2017.

The benefits of the architecture are —
Modularity: Each feature is developed in a way that does not depend on another unless it is Core RIBs. This architecture makes it easier for engineering/development teams to work in parallel & develop features in RIBs, without worrying how one feature will affects another.

Extensibility: The tree-like architecture can be extended vertically by adding children(subclasses) and horizontally by adding siblings or segregating business logic (Extensions) in different workers.

Reliability: The core vs non-core concept implemented using the plugin framework allows us to disable non-core parts of the code, so we can move fast but minimise breaking things.

RIB’s stand for:

R — Router: Listens to Interactor and responsible for attaching or detaching child RIBs, in simple terms responsible for navigation between RIBs.

I — Interactor: Majorly consists of interacting with API’s/Services, listens to presentable protocols

B — Builder: A builder is responsible for creating all the RIBs components, all the children will be instantiated from Builder.

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

RIB’s advantages:-

• Business logic drives the app, not the view tree. Unlike with MV*/VIPER, a RIB does not have to have a view. This means that the app hierarchy is driven by the business logic, not the view tree.
• Independent business logic and view trees. RIBs decouple the business logic from that of view hierarchies. This allows the application to have a deep business logic tree, isolating business logic nodes, and maintaining a shallow view hierarchy making layouts, animations and transitions easy.
• Each RIB is a separated component which has a clear dependencies and definitions. Each RIB can be developed and tested separately.
• Feature development made easy, as Engineering team can work on multiple RIBs parallel, without affecting another.
• RIBs can be called as straight migration from MVVM since the logic of ViewModel can be split into Interactor and Presenter.

But there are some downside too:-

• RIBs framework depends on RxSwift for message passings which can be a blocker for projects where a different reactive framework is used.
• Many boilerplates code for simple components (which can be solved with the provided code templates)

Spoken so much about RIBs so far, now let us see how RIBs framework make a difference from other architectural patterns.

As we all know MVC & MVP patterns are too simple to use for new generation apps, which as complex as any website.

In my previous organisations, have been extensively working on MVVM with a team size of 5–7 members. MVVM served quite well.

But MVVM comes up with some issues too:

• We sometimes have some massive view models where the business logics behind the features are complex.
• We have our navigation logics inside our view controllers which clutter the view controllers code (it can be solved by using Coordinators pattern though).
• We have bad code coverage since we can’t test all app logics due to strong couplings between components where we have to mock a lot of things to be able to test a simple component.
• No clear dependency enforcing.

Since the team and the complexity of the app growing fast, to make app more robust, testable and modular — we can choose VIPER or RIB architecture.

And that’s it for this story, Thank you for reading :)