Uber's Carbon: Dual Binary Mobile App
Original post Carbon: Dual Binary Mobile App
Article Summary
Uber rewrote their entire driver app serving 3 million drivers. How do you ship that without breaking your business?
Uber's mobile engineering team faced a high-stakes challenge: rolling out a complete rewrite of their driver app (codenamed Carbon) without disrupting service for millions of driver-partners worldwide. Their solution was unconventional but brilliant.
Key Takeaways
- Shipped two complete apps in one package to control rollout granularly
- Built AppDelegate pattern to switch between old and new apps seamlessly
- Implemented crash recovery system that auto-reverts after three failed launches
- Used client-side bucketing for gradual rollout without requiring second session
- Caught regional payment flow bug early, paused that market while continuing elsewhere
The dual binary approach let Uber safely migrate 3 million drivers to a rewritten app with fine-grained control, automatic fallbacks, and zero business disruption.
Continue reading
What This Article Covers
Uber's driver app needed rollout control that Google Play Store couldn't provide. The standard percentage-based approach didn't work because different cities had different policy requirements, and updates could interrupt trips mid-navigation, breaking fare calculations.
James Barr and Zeyu Li's team built a springboard activity pattern that checked which AppDelegate was loaded and routed intents to the right app version. They paired this with server-driven feature flags stored in SharedPreferences, which let them control when and where the rollout happened.
When engineers found a payment bug in a new regional version, they paused the rollout in that market immediately while continuing elsewhere. Without the Dual Binary architecture, they would have needed to halt the entire build train for weeks or months.
This page summarizes “Carbon: Dual Binary Mobile App” by Uber, published Jul 14, 2021. All credit for the original work goes to the authors.
