Anything else seems like an even bigger mess:

What happens when a user who travels unexpectedly discovers they need to download a new version of the app for where they are now? And what if they're on a low-bandwidth or capped cell plan and can't download a 100MB app easily, where 3/4 of the data is duplicates of stuff in their other 5 copies of the app?

What happens when a user tries to book an Uber from one area with a special app version to another area with a different special app version? This could easily generate tens of thousands of permutations.

What happens if the user is physically in one country right now, but is a national of another country and wants to pay for their Uber in their usual currency and payment method?

If the user ends up needing to have 20 copies of the app for various locations, how well will they sync ride history, changes in payment methods, and other such info?

I don't even work for Uber, and I thought of all of these complications in 10 minutes. The real Uber probably has 100x more complications that would arise from splitting location-specific functionality into location-specific apps.

Initial install bundle should be minimal and only have code that is required everywhere and or for downloading/installing more stuff.

It's not about creating 10,000 different permutations of an app, but downloading/installing content on demand.

If we are afraid that there might be problem that user later on has not enough bandwidth or issues like that, we'll start immediately downloading/installing after initial bundle in order we think this user might need them.

This means much faster initial usage, much less bandwidth used in total.

Same with developing experience. You shouldn't have to compile code that is not important for your development exp. This way compiling wouldn't take much time, dev productivity would be increased tremendously.

You're not always allowed to do that. E.g. Apple requires all code to either be in the bundle or run in a webview (and even then you risk removal if you introduce "significant" features): https://developer.apple.com/app-store/review/guidelines/#2.5...

For Android purposes: maybe it's allowed in the Play store? I'm not sure tbh. There are certainly other stores with other rules (and Uber is in many of them too), or they could distribute it themselves (but we can see how well that has worked for e.g. Fortnite), but you still need to handle any scenarios where it's required.

Sounds like base things, common for everything should be done using native app code and everything that varies that much should be made as PWA in WebView. You can download this PWA in the background too once app has installed if you are afraid you might not be able to do this on demand. I don't see why not use PWA? The performance implications in this case are minimal imo. And you have all the other fully fledged native features since your app is combination of both. Main arguments against PWA is that iOS doesn't support that well, but hell in this case you skip ALL problems with PWA since you have full capabilities already thanks to being generally native and you are downloading it from AppStore anyway.

In this case it could easily be reused within both Android and iOS without having to create duplicate business logic which I think already is a nightmare.

Airports logic I think should still be something that is defined using JSON/XML or w/e and algorithms should handle parsing that.

Or come on, there must be a way to get airports logic in an easier way. Does user have to update the app every-time when there's some minor airport update?

PWA won't give you access to random device APIs that you didn't open up for a specific use before needing them, which e.g. cameras, payment systems, etc often need. All that still needs to be native, and that can be substantial in some cases.

If it does, say you made a generic shim, you're effectively downloading and executing dynamic code. Maybe not by a technical definition, but that's not the point of Apple's rule, nor will they care about technical arguments when they reject it. There are plenty of examples of this happening in practice, I'm not talking hypothetically - it's why they have a carve-out explicitly for education apps. Even if you don't do stuff like that, and stay entirely in the webview, PWAs (unless it's actually being run in the browser, of course) are not allowed to make significant changes without going back through review.

edit: you can absolutely shrink your binary size with a PWA or similar though, yeah. There will definitely be other tradeoffs you have to make though, I'm not deeply familiar with those. Performance and integration with native libraries at the very least (e.g. map rendering).

There's also something to be said about supporting 60+ versions of a client...

Not following that thoughtline?

By downloading dynamic code, in effect you're running N (or some combinatorial number of) different apps.

Granted, you can/should strongly isolate them so it's infeasible for one module to interfere with another. But as always, YMMV in practice. And good luck testing them all either way.

No, that's why it's beautiful product design. They know something about me. I am at location A and I have a problem: I want to be at B. They then solve that problem smoothly with reasonable defaults. They know this is the prime problem I have and that I have some top few variants on this.

Speaking of the defaults, the auto-suggests these guys have are fucking ridiculous too. Both Lyft and Uber. It's 4 AM in the morning and I've opened the app at home: offers me a ride to SFO. It's 11 PM in the evening on a Friday/Saturday and it offers me a ride to my friend's place. It's midnight and I'm at that friend's? They offer me a ride to my favourite club. I am one-click touching everywhere. These guys are good.

Superb user functionality.

If anyone has a good reason to bundle every location’s use case into one app it’s Uber. A common Uber user scenario is someone who takes an Uber to the airport in one country, arrives in another and has poor internet capability for one of several reasons (roaming, poor mobile service, must connect to airport wifi, etc).

What solution do you imagine that isn't a worse user experience? I can think of lots of obvious ways to simplify the client, but they all seem likely to make things worse for me as a user in pretty predictable ways.