The summary of that comment is "we have to include a ton of stuff that will never be relevant to most users like payments APIs that only work in India."
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?
I love that it’s one app. I remember landing in Delhi from San Francisco and the Uber app worked perfectly and I was so astonished. Effectively nothing else translates seamlessly like that. Combined with the incredible quality control on the vehicles side (every car I got in India had a seatbelt, where close to 0 taxis you’d get on the street would), I knew it was a very high functioning company to execute like this.
You should have come pre covid then. Ubers ecosystem in India has kinda collapsed, driver quality and availability has gone way down as more and more realize how bad a deal it is. Almost every driver I've spoken to here confirms that they are in terrible debt and have not made any money at all driving uber.
While I had a positive experience with the Uber app software-wise (app functioned seamlessly landing in Mumbai from U.S.A.), Uber as a service was not really comparable to what it is like in the U.S. and developed W. European countries. I got the sense that it was more of a strictly ride hailing / request service, not much accountability required from the driver. Often had > 3 drivers cancel after 10-15 minutes waiting before actually getting a ride. That being said, it was still a hugely valuable service to have in India as a foreigner.
Uber India isn’t like Uber New York but it’s a million times more reliable and predictable than almost any other commercial service you can get in India.
Really? Seems like it’d be more reliable and a lot faster to just hop in one of the hundred rickshaws on every street. Besides the fact that they’ll overcharge you if you’re a tourist.
Yeah my experience was that it could be a bit of a pain with cancellations but there were enough cars on the road that I would always eventually get a ride.
> 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.
Not sure what to make of this. I’m Indian and the last time I was in India, there was strict execution of the seatbelt law and offenders were made to wait and fined heavily. Most drivers were wearing seatbelts.
Maybe because it was in Chennai, a southern state and not in Mumbai or Delhi.
Sounds plausible. I was in Delhi a couple of years ago, using mostly Ola (Uber didn't seem to like my non-Indian card, strangely enough) and most of them did not have seat belts at all.
If you're landing in Asia from the US you're probably not going to care about the price (there are exceptions), and Uber has been reliable for me travelling, if that costs a few % more than the local version I'd be happy to pay for convenience.
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.
It's much more complicated than just countries. If you read the linked comment then you'll learn that it's includes many regional customizations, even down to specific cities and airports.
An app for travel should absolutely prioritize UX and ease of use as you travel, however far away your destination is.
Interesting assumption/perspective - The only people in my circle of friends and co-workers who use Uber, are travelers. And nobody I know has a clue of their phone storage or has hit it due to apps (as opposed to videos/photos).
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.
I'm in the same boat. To a first approximation, I never use Uber in my local metro area. To a second approximation, I don't use it much traveling either. I'll often grab a cab if it's convenient rather than waiting for an Uber/Lyft to show up. Or if there's a good public transit option to my hotel I'll use that. In spite of (normally) 100+ days of travel per year I maybe use Uber a dozen times a year. (I do use a private car service to take me to the airport, but again Uber wouldn't be very good for that purpose.)
Totally this. It isn't uncommon for a whales (usually 1 to 2 percent of an apps users) to account for 30 to 50 percent of their profit. So it is very worth thinking of those customers first.
Not all customers are equal. And if you build your app or site without knowing that you may well chase the wrong features.
I would agree with this. At home I walk, ride my bike, get on transit, rent a carshare etc. When I'm travelling, I'm walking or calling an Uber/Lyft. I'll take a train or bus only if it's super easy to navigate.
Same here. In my local area I understand the transit. I have a transit card. But when I am in a foreign city that speaks a different language these are not realistic options unless I spend effort on figuring that out and deal with local municipal transit authorities, which is not the vacation experience I am looking for.
As a frequent traveller, I would be much more inclined to either pick the airports that are going to be relevant to me ever or pick the destination airport when I am at the source airport which Uber can easily detect. I am visiting ~10-15 airports most of the time. I would be happy to spend some time to set this up on my phone so i not need to waste a huge amount of space and bandwidth every time that I update Uber. For Uber it would be a win too, reducing the size of the app significantly. Maybe it is only me.
A willingness to put in some time up front to tailor a technology experience to yourself is one thing that separates the average HN user from the population at large.
For a significant majority of users, if it doesn't work well out of the gate, it's broken.
It's not even just per country. If you fly to certain airports in certain states they have different rules that affect what the Uber app can do. Do they maintain a separate app for Washington and for New York? It gets pretty messy pretty quickly. Not only do you have to maintain these different edge cases, but you also need to maintain separate applications and all of the problems associated with that like keeping libraries and API's in sync between them.
I'm probably missing something obvious as I'm tired, but why does the Uber app need stuff like specific airport rules stored in it rather than pulled from their servers when needed?
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?
The iOS app store prohibits downloading code at runtime, excluding some very specific circumstances.
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.
I don't have any numbers, but I would guess that a good part of Uber's user base consists of people that travel often. Not having to download a new app or update every time you go to a different country is a huge advantage.
There’s me, a frequent traveller who uses UberLUX 4+ times a day, spending more than 5000GBP/mo.
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.
I’m a bit surprised you have the time for UberLUX. When I find myself with an expense account for Uber I always go for the lowest ETA, which is rarely Uber Premium. You must be hanging out in richer places than me.
That 1% of users represents a lot more than 1% of profit, and engineering an application that is that robust across scenarios has benefits to the stationary users transiting through multiple scenarios as well (surge pricing to normal, credit card to Apple Pay, car ride to scooter ride, etc).
Au contraire, people with outdated phones are less likely to be able to afford to Ubers. Much of Uber's profit comes from people booking Ubers from airports, I've used Uber all over the world and it's absolutely amazing.
Personally? A single fat app. Less fumbling around when I land somewhere to get their localized app, which will presumably only be available from that country’s App Store that’s inaccessible before I land there.
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.
> If I have to deal with the airport’s wifi... I don’t want to depend on downloading a 100mb binary over it.
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.
>That pretty much doomed all these "local Uber competitors"
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.).
A whole lot of Ubers big spenders. On a individual basis, but I know many consultants/sales people traveling all over the world that spend hundreds or thousands on ubers a month and want the ease of use. Those are Ubers profitable customers buying lux/black cars etc. in addition to many wealth families that use Uber all over the world in vacation. They should be solving for those customers over a customer worried about an extra 50 or 100mb even on their phone
Not that it affects your overall point, but countries’ app stores are gated based on region you’ve configured your phone to, not where the phone’s physical location is.
The downside is trying to download Uber for the first time when arriving at an airport. However, I think Uber is so ubiquitous now that it's the likely to already be installed.
The Google Play Store solved this problem with dynamic feature modules. Either at install time or later on, you can let users download only certain parts of the app. All with a single app store entry and app bundle.
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.
Interesting. I have had bad cell connectivity in unfamiliar airports, though, where I could barely keep a connection to e.g. the Lyft servers. What if I can’t download the module when I need it? I don’t think requiring the user to download it in advance of their flight is viable, either. If we lived in a world of universal, homogeneous, inexpensive connectivity, I’d be satisfied with the solution you mention. I guess if they had location/policy micro-modules small enough to fit in a single MTU, then anybody who could connect to Uber at all could be served.
It still boggles my mind that there could be ~100M meaningful instructions in a program.
Consider that many travelers are using global roaming data rates on their sim card when arriving at their destination. They should be able to just open the app and it 'just works'. Your proposal isn't something a good product manager would even consider as an option for more than a few seconds
It's not exactly a case of downloading an India version when you arrive there. In order to do so first you have to register an India App Store account. And in order to do that, you might need an India cell phone number and credit card.
Not necessarily. They could have all the Uber apps in all the app stores. It would be a huge pain for their engineers and their users which is probably why they don’t do it.
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.
That's a false trade off. You can load partial content. That's the big advance of html. UI as markup and you can stream the small required portions of a large app.
Totally different requirements. Some countries' fast food apps are for mobile ordering and delivery, some are a giant collection of coupons, and some are only for nutritional information. And some are just for promotional activities (only used for various promotional calendars.) After seeing all the different APKs I tried out a few for different countries out of curiosity and at least for Burger King they were entirely different applications with completely different use cases. To cram them all into one global app would be an enormous mess.
I think fast food chains are generally not actually owned by the same parent company. A company in India is licensing the Burger King branding and presumably some of the recipes from Burger King USA, rather than being a subsidiary thereof.
This is the real reason. For instance, McDonald's in India is itself run by two companies, one for North and West India, and another for South and East India.
Starbucks has a separate China app. I suspect a part of this is due to app size because there are regions specific SDKs. Another is likely security. Regulations in some countries require data to be shared with the government and they don't want SDKs that collect this data to be included in more privacy focused regions.
eBay is one that comes to mind right away (unless they changed it recently).
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.
>Do you have some examples? Genuinely curious. To my knowledge, most of 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.
It strikes me that this would be the perfect use case for loadable modules. The Uber app could download the payment module you need on the first use and leave the dozens of other APIs off your device. This could also significantly cut down on the number of updates (300MB downloads each time!) that the app needs, since NA or European users won't have to re-download the app because some Indian payment API changed.
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.
Or when you just landed on the other side of the planet and don't have a good internet access (or it costs $$/Mb): the app is still expected to work, because you need your ride right now
Uber doesn't work without decent internet access though. Maybe you can make he argument for $$/Mb, but there's no point in uber creating the app so that you can get to the pay screen without internet when you need the internet to use uber.
Decent can still be pretty bad and still work. And of course it's worth it because a phone can find/lose it's connection all the time for a bunch of reasons even if the network is high quality and high bandwidth.
The whole point is the seamless transition. Would you want to sit there twiddling your thumbs in a potentially unfamiliar area, while the region's version of the app loads? Or would you rather just have it work?
This keeps getting repeated in this thread & I keep not understanding it. If I downloaded Uber & set it up with the payment method that I need, why would that payment method suddenly change at 1am in India?
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 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.
Google encourages this with feature modules and app bundles. Apple doesn't allow it because they've always been against downloading executable code that doesn't go through app review. Same reason they don't like game streaming or downloading react native at runtime.
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.
Google is also serving a different market (average of lower-end phones on lower-end networks); however, I worry that every day Google's stance on apps and app review starts to look more and more like Apple's.
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)
Interesting idea, I assume Apple would solve the versioning problem the same way Google is currently handling it. Apple is doing something like this already but there isn't too much detail other than the mention of update packages here: https://developer.apple.com/documentation/xcode/reducing_you...
Actually google has recently added that feature with android app bundles. Apple has something similar with on demand resources, but specifically prohibits binary code in them. Hopefully with android having the feature, it would induce apple to allow binary dynamic libraries in on demand resources too.
> And then you have the binary size bloat with Swift that OP takes about.
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.
Yeah that’s a great read, super interesting detail. You wonder what would have happened if Apple didn’t up the limit.
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?
And it applies to not only Uber, but tons of other apps.
Unfortunately incentives are not aligned to make rarely used features load on-demand.
I wonder what the average user percent of application binary actually executed is.
Why should a user care about an extra MB’s on their phone for a frequently? If we were talking about 10 year ago storage prices/capacity or much larger apps sure this would be a discussion but it shouldn’t be nowadays. I get it programmers like to focus on efficiency, but I promise you 99% of users don’t care about the extra MBs with the price of storage and value of Uber nowadays.
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?