An old (but fantastic) comment from the previous discussion about Uber's app size that addresses why the Uber app is so big: https://news.ycombinator.com/item?id=25376346
This is why some global apps have different apps for different countries. It's a trade off. Would you rather have a single fat Uber app, or have to download Uber India when you arrive there?
Do you have some examples? Genuinely curious. To my knowledge, most of the major FAANG apps are single-binary.
Why? I have no idea.
Google Pay is another one. They have a dedicate app in Singapore.
It seems like a lot of them went to single apps when they realized they could download data packs within the app. Stuff like Rick Steves guided tour apps used to be separate per city, but now it's a single app where you download the data for a certain city.
But I think you're right that all the major FAANG apps are single-binary.
Worked on iOS app size at a FAANG for a couple of years -- this is untrue. At the very least there are different binaries for watch vs iPhone architectures.
If I have to deal with the airport’s wifi... I don’t want to depend on downloading a 100mb binary over it.
Maybe they could have a local and global version available, but that’s already making it more complicated.
That pretty much doomed all these "local Uber competitors". Nobody would start looking for a local competitor, set up an account, get 2FA, register their payment method and then have the privilege of getting a "starting up" screen telling them how and where they can get a ride. Instead they just open Uber and get where they want.
Did it? How much of Uber's usage in a random big city is from travelers based elsewhere vs locals? And it seems like others have succeeded in some narrower regions (Grab, Didi, etc.).
Uber lost in pretty much every market where they had local competition. Are there any counterexamples?
We use this for devices which don't have NFC. If the device doesn't support it, then there is no reason to download the module for identification via passport NFC scans.
It still boggles my mind that there could be ~100M meaningful instructions in a program.
The fact that Uber devotes engineering resources to serving the tiny 1% slice of users who care about having an app that works seamlessly across dozens of countries, at the expense of the much larger number of users with limited space on their outdated devices, is really emblematic of the Valley's out-of-whack priorities.
I would imagine that travellers are an outsized percentage of high spenders, even if they are a small portion of users.
Not all customers are equal. And if you build your app or site without knowing that you may well chase the wrong features.
For a significant majority of users, if it doesn't work well out of the gate, it's broken.
For some, Taxi works well enough and is (perceived as) licensed/trusted/reliable so they don't have a need to use Uber. Others are bit of Luddites, or mistrustful. But I guess friction of Taxi / benefits of Uber just aren't high enough :-/
(Personally, I've only ever used Uber on specific travels; for 99% of my transactions, Taxi has been easier/more reliable. Don't get me wrong, I think Taxi licensing/medalion model is outdated, the drivers have worked incentives, and cars aren't as maintained as well as they could be. But I still normally don't find a benefit in Ubering).
Finally, FWIW, even traveling within country, I've noticed significantly different screens/features/options in, say, Ottawa or Toronto airports and vicinity. So I think overall a lot more people benefit from this monolithic model than may be immediately apparent.
An app for travel should absolutely prioritize UX and ease of use as you travel, however far away your destination is.
Map apps let you look at any city in the world without needing all of that data inside the core app, and if you have enough data to use the Uber app wouldn't you almost certainly also be fine to have it download in the background the required info (coordinates of where pickup is or isn't allowed, specific instructions message to display, etc.) the same as it receives information about local pricing, location of available cars nearby and so on?
You need to think about the larger picture.
A quick summary like "extra fee for airport pickup: X, pickup location restricted to: Y, etc." should be pretty comparable.
Thinking of my experience with Uber at airports, it's generally stuff like "pickups from this terminal are only available at the west exit" (show on map - so needs coordinates and message text), or "There is a £10 airport pickup fee for all private hire vehicles here which will be added to your bill", or whatever along those lines.
But perhaps your point still stands even if it's KBs rather than MBs.
And for the specific UX, sure but isn't that just a single feature for airports in general, and the app can pull the up to date airlines/terminals data for the specific airport when needed?
As long as the airport rules can be stored as data, not code, then iOS would be fine with pulling them.. but at that point you have a data blob saying effectively "in country X, you can use payment Y", and you still need code that knows "payment Y means enable this section of the app and use this library"... and you can't download that library at runtime on iOS.
So my guess is that the code implementing regional rules have to be bundled with the app due to apple's restrictions, and the associated data that could be dynamically downloaded is to small to not just bundle it too.
Then there are 100 guys with outdated devices who use UberX once or twice a month to get back home from the pub, probably splitting the ride with their friends.
I bring in more money than the latter group of people.
Uber Pool is no longer available due to covid; but hopefully it will come back as vaccination rates go up.
Unless India? [1]
[1] https://www.theguardian.com/technology/2017/jun/08/uber-exec...
That sounds so weird to me... What do you mean cars don't have seat belts?!
I can confirm the OP's experience albeit in a different country (Mexico). In some regions, I haven't been in a single street taxi with working seat belts. Indeed, I've been in some private cars without them as well, or with more physical space for passengers than there were seat belts available.
Uber vehicles, though, have always provided those safety features. Some drivers work as both street taxi and Uber drivers (as they frequently cross into or live in regions without Uber but drive people to places that have it), so that quality assurance can trickle down in some cases. It honestly goes beyond seat belts though; a Uber car is more likely to have AC, electric windows, etc. than your average taxi, even in ridiculously hot parts of the country.
Maybe because it was in Chennai, a southern state and not in Mumbai or Delhi.
You said any.
As an engineer? The first option too.
When I traveled to India (pre-COVID), it was great that I could just open the app & get where I needed -- even if I wanted to travel via tuk tuk.
It was more annoying when I got to Ireland, had to figure out the app to use was MyTaxi and get it all working (including payments), particularly as a foreigner.
Unfortunately the way Apple and Google set up their walled gardens makes this impossible. I guess Apple would prefer if the Uber app dropped all of that and just made everybody use ApplePay instead.
When I'm opening Uber at 1am in the cold to get a ride home, this is not the time to download a payment SDK update.
I recently was traveling. I landed at a new destination and checked the internet speed. Mobile via my tablet just outside the airport was theoretically as 50KB/second via Google speed check. However actually downloading a file from US servers was 5-15KB/second because of the latency (3000ms+) being so high that packets were constantly being dropped.
That's at best, 75 seconds waiting for a download. At worst it's 16 minutes.
On the other hand, I was able to get Uber on my phone and though it was painfully slow, it found a driver in under 30 seconds.
The way this should work is when you set up payment option X, it downloads the relevant payment info & then you're set from then on without any other modules unless you add a new payment option. Likely pre-bundle the generally "global" options (Apple Pay/Android Pay since those are platform-native & credit cards since those are likely small implementations).
The real reason is that you will always have drop-off because the download phase is split in two (on the other hand you'll have increase in installs because the app size is smaller). That would need App Store integration with the loadable modules so that you could say "Install these payment features of the app". This may not be a win because again, it requires the user to do more work. Simple for everyday users will often win the day even if inefficient vs more optimal options that achieve that optimality by pushing complication to the user.
I'd like to see them open up this possibility in a controlled way one day. Something like a review process for feature modules that could be updated in a similar process to full apps.
WRT to Apple enabling this: I imagine developers could get into a bit of a versioning hell-scape there if they were decouple updates of different modules in their app (do you know if your app is working with FeatureA v1, v2, v3, or not at all? How about FeatureB?) If Apple were to do this it would look something like app extensions do today (separate binary stored within the IPA - that's possibly thinned out and rehydrated on device); probably with very little control over what's loaded (similar to how they did rollouts: this percent on this date and nothing else)
https://mobile.twitter.com/stantwinb/status/1336890442768547...
I can’t seem to find the old link, but I’m pretty sure it was on hacker news and somebody posted a nice collation of the posts.
Any discussion about software distribution will inevitably result in an argument about dynamic linking vs. static linking.
Hopefully, swift ABI stability will reduce that. The new bytecode stuff will help to reduce bloat, as well, but he notes that a lot of SDKs are used. In my experience, SDKs and dependencies often won’t work, compiled with bytecode. Hopefully, that’s changing.
That code repetition thing also happens when a lot of dependencies are used; which often reinvent the wheel. That just comes with the territory. It can be addressed by using highly granular dependencies, but that sort of flies in the face of why we use dependencies. One advantage that Uber has, is they are an 800-lb gorilla. They could contract for specific configurations of dependencies.
I’m not a big Uber user (but I’ve used it a few times). I think it’s a fairly well-done app, as a user.
This post is next level though, deeep optimization. All of it is just increasing the ceiling though, there is some limit on number of features Uber can offer in one app.. and eventually that limit will be reached, doesn’t sound like they are willing to accept being over the limit either. Wonder what space saving techniques are left in the box?