Well, the google results when I initially posted it didn't even bring up the choice I would probably use (again). Which is C++ and either a custom hand rolled platform abstraction layer, or maybe something like QT if the application were UI heavy. Which from what I can see of the uber app isn't.
That is because its very well supported on both platforms, and one of the few language ecosystems that can actually create native looking/acting applications on both.
Yes, the initial development may be a bit slower, but that is common with C++ because what the smart people are doing is usually creating an application specific "language" out of C++. Then once that core bit is done the actual development would probably outpace many of the other choices. I've done this a couple times with native development toolkits, the "customer" in one case was really questioning how much work was actually going on when 1/2 way through the contract it barely had a single "screen" in a data collection/reporting application working. But, then another few weeks went by, and literally in the space of about 2 days the application went from looking like it had just been started, to being basically feature complete. That is because the C++ engine was complete and it took ~12 hours to fill out the few 10s of thousands lines of boilerplate ui descriptions that actually formed the UI (in that case it was a custom textish/declaritive application description language, most of the c++ code was parsing it and doing layout/drawing in response. Super happy customer too, once they understood that their inhouse "IT" people could update/change the app with little more than a text editor against some fairly simple to understand rules).
And many of the functions the GP was asking about are the kinds of things one could contract out. Aka, why not just use google maps API for the routing/etc.
Frankly, given what I saw a couple years ago when I went poking around in the iphone app store, it seems just about every region taxi company had reimplemented large parts of the uber interface in their own apps. Maybe not always as slick, but the core parts were in many of them, and I doubt random regional taxi companies can afford the engineering effort uber apparently is spending on.
- iOS rider app
- android rider app
- iOS driver app
- android driver app
- ride/driver matching
- routing/supply
- security/compliance
- fraud detection/prevention
- backend rides services
- backend user services
^ 10 teams of at least 10 people off the top of my head. Amazing how underestimated engineering resourcing needs are.