Live data from Hacker News

How Uber Deals with Large iOS App Size

eng.uber.com

101–110 of 215 posts

Re: How Uber Deals with Large iOS App Size

#101

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.

> every car I got in India had a seatbelt That sounds so weird to me... What do you mean cars don't have seat belts?!

> 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.

Re: How Uber Deals with Large iOS App Size

#102
There's apparently a bananas crunch/backstory to this, where they committed to Swift before realizing they would hit its limits, and had to come up with a bunch of this optimization madness on the fly. I guess this is the cleaned up version and the more final, stable optimizations for the company blog:

https://twitter.com/StanTwinB/status/1336890442768547845

Re: How Uber Deals with Large iOS App Size

#103

> The app has a couple of millions of lines of code I wonder if Uber is planning to do anything about that? The technique described in the article (whole program instructions outlining optimisation) is a band aid style solution, merely delaying the inevitable: the code produced by numerous teams independent of each other will inevitably cross first the download size limit threshold, and later maintainability threshol…

I also find it unbelievable to have so much code for a single app, this is approaching the level of magnitude of OS code bases: if you think that the entire Linux kernel is around 28M lines so roughly 15x the Uber app.

The binary size is also from the same ballpark as the entire Windows 98 needed for installation.

I'm glad Uber is doing something about this, but in my opinion Apple should tackle this across their entire ecosystem at the toolchain level, devices with less than 64GB of storage can quickly run out of space with just a handful of applications installed.

Unfortunately it's in Apple's interest that people buy devices with more storage, so I don't expect them to invest much effort in this.

Re: How Uber Deals with Large iOS App Size

#104

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.

> every car I got in India had a seatbelt That sounds so weird to me... What do you mean cars don't have seat belts?!

People have even chuckled when I reached to put a seatbelt on in India. :)

Re: How Uber Deals with Large iOS App Size

#105
post #22

Earlier quoted context omitted.

If you click the link OP posted and read the previous thread you will see they can "easily" do ass . They already spent millions in engineering time to cut the app size as the company existence literally depended on it when Apple's bundle size limit was 150 MB. If your app is serving hundreds of cities with specific per-city customizations and all code and assets are in a single binary, life gets tough.

If you open up the IPA, you'll see that basically they've recreated some anroid-xml compatible rendering engine. The localization files (50MB) -> All the strings files are double the size (unpacked), because of useless comments. There's 25MB already. In the assets catalog -> half an MB for an upscaled (!) visa card. Other images where jpgs of heif are a better choice. probably in total 10-20 mb. Strip all ICC/Gamma f…

I would like Apple to be doing some of these against all the apps.

Few app developers have the time/bandwidth to do these things and it would be a very inefficient use of resources to have everyone do it over and over again.

Re: How Uber Deals with Large iOS App Size

#106
post #17

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?

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.

Which sucks. I arrive in a new country, and need to find internet access???

Re: How Uber Deals with Large iOS App Size

#107
post #103

> The app has a couple of millions of lines of code I wonder if Uber is planning to do anything about that? The technique described in the article (whole program instructions outlining optimisation) is a band aid style solution, merely delaying the inevitable: the code produced by numerous teams independent of each other will inevitably cross first the download size limit threshold, and later maintainability threshol…

I also find it unbelievable to have so much code for a single app, this is approaching the level of magnitude of OS code bases: if you think that the entire Linux kernel is around 28M lines so roughly 15x the Uber app. The binary size is also from the same ballpark as the entire Windows 98 needed for installation. I'm glad Uber is doing something about this, but in my opinion Apple should tackle this across their ent…

For both technical and UX reasons it's in Apple's interest to make app updates lightweight, and those likely far outweigh any driving force they might have to encourage people to move to higher storage sizes.

(1) if it takes a long time for people to update their apps, that's a crap experience that people are having on Apple devices, which goes directly against the grain of Apple's whole value proposition ("use our stuff and your life will be great!")

(2) For technical reasons, it's in Apple's interest to reduce app image sizes; less strain on infrastructure, easier to scale, etc. (300MB * 1.2M (# of app store reviews) = 360 terabytes transiting their networks whenever Uber pushes an update. All that has to be load balanced, CDN'd, etc.)

Re: How Uber Deals with Large iOS App Size

#108
post #7

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

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. Unfo…

Another person who think the internet is available everywhere.

Re: How Uber Deals with Large iOS App Size

#110

Earlier quoted context omitted.

> This is such a non-feature for 99% of users. I would imagine that travellers are an outsized percentage of high spenders, even if they are a small portion of users.

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.…

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.

Post reply on HN