Software Dev

The what, why, and how of the RIBs mobile architecture

Continuing my mobile architecture kick, let’s look next at RIBs. In this case, RIBs is not a delicious, slow-cooked entrée but rather a software architecture that Uber developed a few years ago. It lets their 200+ mobile developers knock out features quickly without stomping all over each other.

Why RIBs?

The original design worked well for the first three developers. (via Uber)

Back in 2016, the Uber team had quickly expanded from three mobile developers to 15 to several hundred. But the app’s design did not scale well. It became difficult to add features, from both a UI design and a technical perspective. Citing “quite a few examples of, you know, pretty bad UI”, the design team bravely demanded a rewrite.

The design team came in and said, you know, ‘We probity have to redesign the whole application.’… Everybody was super concerned.

Classic engineering understatement

The Uber engineering team resisted the rewrite (which can be nightmare on a large app) for a year, but eventually came around to its necessity. So they defined a few goals for the new design (99.99% reliability, scaling to ~1000 developers, …) and experimented with that they knew – MVC, MVVM, MVP, and VIPER.

Nothing worked. 🤦🏻‍♂️

The problem is that all these architectures are based around the view, and if you base everything around the view, everybody has to integrate at one point, and that becomes a mess at the scale that we have.

The state tree solution

So they came up with a fresh idea, which was to model the whole app as a state tree. Much to their surprise, it worked really well. 🤷🏻‍♂️

We haven’t found an application that you couldn’t model with this very nicely.

The crack architecture team spent six months reworking some “super ugly looking” core app flows, and then turned the rest of the team loose on the new architecture.

And now we have RIBs and the modern Uber app.

Whoa! That looks too easy! (via Uber)

But how does it work?

A RIB is a combination of Router/Interactor/Builder (plus Presenter/View, but I guess “RIBPV” doesn’t sound very good). Each RIB represents a state of the app, which can have sub-states as children.

For example, the root of the tree has two children: logged-out and logged-in. Every RIB under logged-in can safely assume that the user is logged in — and it has an authenticated user token to prove it. 🔑

RIBs present themselves hierarchically on top of each other on the screen. Or some RIBs just do background support don’t show themselves at all.

No auth token for you, left side. (via Uber)

For more…

Pretty cool, eh?

Okay, I’ll stop here since this is a conceptual overview (aka a teaser) and not a tutorial. ✋ For more details, see the original Uber presentation below or try it yourself at the RIBs GitHub repo.

Up next in the architectural series, we’ll attack The Composable Architecture, which is responsible for at least one cool game and, like RIBS, has a concrete implementation rather than just a bunch of vague ideas. 🙏

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.