Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Uber Deals with Large iOS App Size

eng.uber.com

Post reply on HN
Print view View original

41–50 of 215 posts

Re: How Uber Deals with Large iOS App Size

#41

Post by jdminhbg »

mkipper wrote: post #28
bhupy wrote: post #18

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.

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.

Re: How Uber Deals with Large iOS App Size

#42

Post by MattGaiser »

ForHackernews wrote: post #34
spoonjim wrote: post #27

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.

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

Re: How Uber Deals with Large iOS App Size

#43

Post by user5994461 »

jandrese wrote: post #35
bhupy wrote: 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…

>>> The Uber app could download the payment module you need on the first use

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.

Re: How Uber Deals with Large iOS App Size

#44

Post by novok »

jandrese wrote: post #35
bhupy wrote: 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…

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.

Re: How Uber Deals with Large iOS App Size

#45

Post by doggodaddo78 »

ohiovr wrote: post #2

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's called a web browser and a web app.

And then there wouldn't be anything to hog-up 1/3 of a GiB on every customer's phone, and it would always be up-to-date. Just don't ever lose internet access.

Re: How Uber Deals with Large iOS App Size

#46

Post by fractionalhare »

jedberg wrote: post #17
bhupy wrote: 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

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?

No, it's also substantially different between certain cities and regions in the CONUS. Otherwise that might be viable.

Re: How Uber Deals with Large iOS App Size

#47

Post by bhupy »

ketralnis wrote: post #19
bhupy wrote: post #10

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

Considering that Uber's binary size (330MB) is comparable to similar apps such as Google Maps (224MB), Lyft (435MB), and Didi (332MB), it might just be par for the course for iOS apps.

Yelp, for example, is what you might call a "straightforward CRUD app" (to Yelp engineers, I know it's probably legit complicated and hard), and that is 292MB on the App Store.

It's probably to do with how the framework handles lifecycle management and combining static assets like text and image with business logic that lives in Controllers.

Re: How Uber Deals with Large iOS App Size

#48

Post by sond813 »

I’m the founder of a YC company in the current batch focused on solving this exact problem! https://www.emergetools.com

We parse Obj-C and Swift runtime metadata to determine size contributions of individual types and functions in your app. We use this analysis to post PR comments with granular size diffs to help devs write smaller, better code.

I tried it out on the Uber app and immediately noticed a disproportionate impact from their code-gen dependency injection framework, Needle. The codegen is responsible for over 30k classes in the app binary, and contributes over 10mb! In general codegen is a common problem with Swift binary sizes, and the fewer reference types generated the better, it even helps with startup time!

We’ve written a blog post with case studies about how 7 of the most popular iOS apps could reduce their size: https://medium.com/swlh/how-7-ios-apps-could-save-you-500mb-...

Re: How Uber Deals with Large iOS App Size

#49

Post by gregoriol »

user5994461 wrote: post #43
jandrese wrote: post #35

Earlier quoted context omitted.

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…

>>> The Uber app could download the payment module you need on the first use 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.

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

Re: How Uber Deals with Large iOS App Size

#50

Post by jbverschoor »

jakub_g wrote: post #22
jbverschoor wrote: post #15

Earlier quoted context omitted.

328 mb more than a complete OS. No doubt they can EASILY trim 30-60%. Asset optimization, stripping SDK libraries and you're done. It's like graffiti.. the app is so big already, that the devs don't give a damn about optimizing.. why bother if they are just A/B-feature tests? 30mb for some unoptimized screens for example

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 from the PNGS -> another 10mb.

pngcrush the images -> about 40%

And then of course the binary itself which is probably full of unused information.

Post reply on HN