Architecting Uber’s New Driver App in RIBs

This article is the second in a series covering how Uber’s mobile engineering team developed the newest version of our driver app, codenamed Carbon, a core component of our ridesharing business. Among other new features, the app lets our population of over three million driver-partners find fares, get directions, and track their earnings. We began designing the new app in conjunction with feedback from our driver-partners in 2017 and began rolling it out for production in September 2018.

Building an app from the ground up raises numerous questions concerning architecture and design. By far the most simple trap for engineers is to develop in a bubble, working from a fixed idea of how the app should work. Fortunately, customer-focused design has become a strong theme in software development, but identifying your customer isn’t always a straightforward question.

Once we decided to rewrite Uber’s driver app, we turned to our extensive and diverse user base for insights on how to design workflows and which new features would be most useful. The feedback from our driver-partners in cities around the world served as a crucial motivation for our initial UX design.

At the same time, we had another population to consider: the hundreds of engineers, now and in the future, who would be building the app and iterating on features. A well-thought-out app architecture would help these engineers to work more efficiently, delivering features quickly while maintaining reliability.

Fortunately, serving both groups, including implementing a smart workflow and improved features for drivers and a flexible, reliable architecture for our engineers, does not create conflict. In fact, the needs of both groups dovetail nicely.

In this article, we outline how we came up with the core requirements for our new driver app (codenamed Carbon) and discuss how we leveraged a combination of RIBs architecture and plugin design patterns to build our application logic.

First released in 2013, the Uber driver app would accumulate many features over the next four years that would become essential to our driver-partners. As the app grew in complexity, so did Uber as an organization. Hundreds of features in the app were built and maintained by more than 40 different sub-teams across the company. By January 2017, our Android driver app codebase had 428,685 lines of code, contributed by nearly 200 engineers. The iOS app had 720,273 lines of code, contributed by over 200 engineers. More importantly, our apps were installed in more than three million devices and used daily by one million drivers across more than 100 countries.

For Carbon to be successful, we knew we had to deliver all of these existing features (as well as a few new ones) in a timely manner, and parallelize as much as we could.

Product development works best when keeping the end user in mind. To that end, we wanted to build the app together with the Uber driver-partner community. During the initial stage of development, we invested heavily in user research, interviewing 500 drivers in 12 cities across 11 countries.

These interviews helped us design the new app’s UX and determine its most important features. However, there is no way to capture the full experience unless drivers are able to take the app on the road and test in real-world conditions. We needed to build Carbon in a way that would allow us to gather feedback, iterate quickly, and release new versions on a weekly cadence.

The hardest and most important challenge involves reliability during real-world testing. When you introduce a new app, there is an established tolerance for faults or issues during the alpha and beta stages. In our case, the beta phase involved real drivers on the road trying to make money. Achieving reliability was a key goal for Carbon. So, as we moved into the rollout stage, we had to ensure that Carbon would be, at a minimum, as reliable as the existing app even during beta.

Having laid out the constraints of our project, we adopted a staged approach by dividing the project into four phases. The goal of each phase was to unlock the development of the next phase.

Internally, we had a general template describing what all of our apps must include. This template consisted of libraries for networking, storage, ReactiveX, analytics tracking, crash reporting, and our homegrown application architecture framework, RIBs. Leveraging this template, we built an initial skeleton app with the capacity for storage, networking, crash reporting, and infrastructure components. However, in this phase, the skeleton app lacked features or any functionality for drivers, merely serving as the scaffold on which we would build our features.

One of the main benefits of using RIBs architecture is how it puts the emphasis on business logic as the core of the application architecture. In the case of Carbon, a good starting point would be to define the high-level user states for the driver. This led us to define these foundational RIBs:

Internally, we leverage a RIBs tree diagram, as depicted in Figure 2, below, to represent the app architecture. This simple tree-like diagram shows how RIBs components relate to each other.

By focusing on the user state, we can decouple ourselves from the UI. This approach lets us more easily incorporate ongoing feedback from driver-partners into the application design, while enabling us to maintain the fundamental root of the application.

With some base-level scaffolding in place, our focus shifted to collaboration. In phase 2, our goal was to scale development to allow around 40 teams to reliably and seamlessly work in parallel on the same app. Based on our user feedback and in collaboration with design and product teams, we were able to define more detailed RIBs and components:

After incorporating these feature frameworks, our little RIBs tree grew larger, as shown in Figure 3, below.

Before we dive into the specifics, let’s clarify some of the concepts we use in our RIBs architecture:

This is is an object that has start/stop lifecycle methods that directly correlate to a RIBs lifecycle. In other words, a worker added to to a RIB starts when that RIB is attached, and stops when that RIB is detached. Workers ensure that our interactors (the business logic component for a RIB) don’t get too large, and allow for better separation of concerns. (Available in our Android and iOS repositories.)

Plugins are a design pattern that allows us to feature flag our code in a scalable manner. (Learn more about how Uber leverages plugins in a previous article). We first define a public API for our plugins in our core code for integration, and developers can then implement their own instance of this API knowing that this code is implicitly guarded by a feature flag conforming to this interface. Think of each plugin point as if it were a service in a microservice architecture, and the plugin factory as the consumer to that service, which would make the plugins similar to the API or the contract between them.

Combining RIBs, Plugins, and Workers, we now can define what we consider to be core and non-core components in our architecture. Core components are considered essential and can’t be disabled by a feature flag. Non-Core components, on the other hand, can be disabled if they introduce a major issue or regression to the app. In Figure 4, above, Map and MyHub are examples of non-core components, which can be disabled without shutting down the app’s basic functionality.

If we were to zoom into a section of our RIBs tree, as in Figure 5, below, we can see how we use Core RIBs with plugins and workers to support the overall functionality of the agenda using a worker/plugin pattern. The Agenda feature exposes two different plugin points, Agenda Worker and Agenda Section. We use the Worker plugin point to facilitate non-UX integrations to the Agenda RIBs, and the Section plugin point to extend the Agenda’s UX.

Using this design pattern, we could unlock development for most areas of the app. For instance while some engineers build the login and signup screens, others can focus on exposing the map framework to the active non core RIBs.

In phase 3, we opened up the Carbon development floodgate by onboarding our feature teams.  Since we created our plugin framework to ensure that every feature built moving forward is independent of one another, feature incorporation was a relatively frictionless process. If necessary, a few RIBs were promoted to core status, but the majority of our code remained wrapped inside plugins, and therefore optional in our architecture. (We plan to discuss some of these exciting new features in future articles).

Architecture in software engineering is most often about prioritizing the values that are most important to your organization and making compromises on others. While our approach allowed us to optimize for reliability, scalability, and modularity, there were other areas where we had to compromise. In our disciplined and rigorous process, we allow very few components in our app to be core. To uphold the quality of core components, we have a group of internal reviewers that review every code submission wishing to change core code. This process requires some engineers to dedicate their time to these core reviews, and it slows down the submission process for other engineers.

Most application developers are familiar with the concept of Model View Presenter or Model View Controller. Compared to them, RIBs seems more verbose. It has more components and requires more upfront planning. A smaller engineering organization may not need to employ a similar process. Having previously gone through a rewrite with our rider app, we had a clearer sense of how we wanted to build Carbon, and we can summarize our learnings as follows:

Interested in developing mobile applications used by millions of people every day? Consider joining our team as an Android or iOS developer!