31–40 of 215 posts
Earlier quoted context omitted.
> This is why some global apps have different apps for different countries Do you have some examples? Genuinely curious. To my knowledge, most of the major FAANG apps are single-binary.
Dedicated apps for fast food chains are one example. A quick search gave me "Burger King India", "PizzaHut Egypt" and "KFC UAE". Why? I have no idea.
It has... a few million ... lines of code? What? Linux has 30 million of C! I'm speechless. I cannot fathom how & why.
It's a variant of the "I didn't have time to write you a short ____ so I wrote a long one instead" adage.
I would guess (but only guess) that this article erred on the side overstating size.
Earlier quoted context omitted.
I'd say this is the most comprehensive breakdown: https://news.ycombinator.com/item?id=25376346
Let's say there are a hundred screens in the app and the app is 300mb. Does it really take 3mb of source code, about 3/4 of a bible, to render one screen? (I do understand that source code isn't what ships in the binary, but for the sake argument let's say they're 1:1 in size.)
Earlier quoted context omitted.
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.
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.
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
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.
Currently they only deliver the binary for the device's CPU, and only the assets for the device's asset class. There's then some tech targeted at game devs for on-demand assets for things like game levels that you don't need all of on device at one time.
I suspect the limitations of this are around the binary not being subject to this, but maybe it could be. I can see a couple of options, one is some way of extending the asset classes to code features, so that the App Store doesn't have to download iPad screens for iPhones, etc. Perhaps this could be extended with either App Store account region or locale so that, Uber in this example could not include the Venmo SDK outside of the US where no one has heard of Venmo.
Or perhaps Apple could extend the on-demand assets to allow for some sort of plugin system, perhaps backed by Swift Packages, such that apps can on-demand decide they need the Venmo SDK because they're in the US, and download just that. I don't think we want a generalised package manager here, I don't envision that SDK coming from Venmo directly, but allowing an app author to upload all their separate packages if they want to.
With feature heavy, international apps such as Uber I'd expect this to dramatically improve things. I'm not sure whether this benefit would translate to that much demand across the whole App Store though as I think this matters more to a very few big apps. Apple is at that optimisation point in the iOS lifecycle though so perhaps it's worth it to them.
Earlier quoted context omitted.
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.
This is such a non-feature for 99% of users. 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'd take a sledge hammer to it. The app doesn't have to be an app at all. It could simply be a stream with an os interactive overlay that intercepts touches. Like a thin client for phones.
That could trigger the App Store review block. But this is Uber, so I'm guessing there's special treatment :)
Complementary: This thread on Uber's transition to Swift that almost broke them https://twitter.com/StanTwinB/status/1336890442768547845 Includes, among other things: forcing Apple to increase cellular download limits, 45 seconds for letters to appear in XCode, 12 seconds to call main, rewriting the linker and so on.
I'd take a sledge hammer to it. The app doesn't have to be an app at all. It could simply be a stream with an os interactive overlay that intercepts touches. Like a thin client for phones.
A stream may also make it harder for the app to work in areas with poor connection. Which, given Uber's use case, is probably a likely scenario and one that could lose a lot of customers to competitors.