RIBs - Uber's new mobile architecture that scales to hundreds of engineers by Tuomas Artman

Most well known mobile architectures start to work against you after your engineering team grows large. A new architecture paradigm is needed to support the development of mobile applications with hundreds of mobile engineers.

After investigating all other mobile architectures, Uber created RIB's, a platform-agnostic novel mobile architecture designed with reliability, testability, isolation and maintainability in mind. In this talk, you'll learn about the motivation to create an entirely new mobile architecture, the process that let us re-write the Uber application in 3 months with 200 engineers and an overview of the architecture itself.

# Tuomas Artman
Tuomas is the tech lead for Uber’s mobile architecture and frameworks team. Prior to moving to the Bay area five years ago, he founded one of Finlands leading digital consultancy and spent a year in Shanghai building games and multiuser technology platforms for the Chinese market.

[paulstringer]

Nice to see the Dependancy Inversion Principle and Clean Architecture being applied again to solving the age old software problems of massive teams.

[abuzeidibrahim]

This man is a great story teller, nice presentation.

[strictnonconformist]

I’ve observed that any application architecture that is based around the GUI for dependencies of anything beyond the scope of a single screen just isn’t readily extended/modified/reused. From watching the video, I see an architecture that puts views and data in their appropriate places in relation to views: views are just a window into the soul of an application’s business logic, and data is modified according to business rules, and logically, it doesn’t matter how the views are represented: they’re merely window dressing for end users to present a user-friendly face to do the most important function of an application, which is to transform inputs into outputs for use by users.

Logically, Uber’s applications when architected this way should only ever go awry if the business logic creates unrecoverable states that are undefined: the routing logic is simple, the presentation code (views) should be easy to test.

Almost makes me curious enough to download the Uber app ;)

[koredeaderele]

"three people... working super hard on an off-site" (1:55) something about engineers working during an off-site rubs me the wrong way a bit

[papanino]

I just hate how we've come to this idea that views can't even read or write their own text fields.