Why We Decided to Rewrite Uber's Driver App
Article Summary
Uber rewrote their entire driver app with hundreds of engineers over 18 months. Joel Spolsky once called rewrites 'the single worst strategic mistake' a software company can make.
This is the first in a series from Uber's mobile engineering team detailing their decision to completely rebuild the driver app (codenamed Carbon) used by 3+ million driver-partners. The decision came after a rigorous three-month research process involving cross-organizational buy-in.
Key Takeaways
- Technical debt caused real outages; app couldn't maintain 99.99% uptime requirement
- UI designed for UberX couldn't scale to Pool, Eats, and market-specific features
- Past migrations at Uber had high incompletion rates, creating more tech debt
- Rewrite aligned with new RIBs architecture already adopted for rider app
- Decision driven by business needs, not theoretical 'clean code' desires
Uber chose a full rewrite over migration because incomplete past migrations created instability, the product needed fundamental redesign, and standardizing on RIBs architecture would double platform investment value.
About This Article
Uber's driver app had business logic tangled directly into the view layer. Android controllers grew to thousands of lines following the Massive View Controller pattern, which meant any UI redesign required rewriting core business logic.
Nandhini Ramaswamy and Adam Gluck's team switched to RIBs architecture, a VIPER variation that separates business logic from presentation through hierarchical scope structure and careful memory management. They standardized this approach across both the rider and driver apps.
The rewrite let Uber add new services like Uber Pool, Uber Eats, and cash payments while keeping 99.99% uptime. The team open-sourced RIBs in 2017 so other engineers could use it too.