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

61–70 of 215 posts

Re: How Uber Deals with Large iOS App Size

#61

Post by liuliu »

dangwu wrote: post #33
ketralnis wrote: post #19

Earlier quoted context omitted.

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

It must be mostly the dependencies and assets they're pulling in for each screen, and not simply the source code. They could be using a different SDK for each type of payment they take, which is a lot. If the app has 250 features, and each feature includes 4MB of assets (images, icons, sounds, etc.), that's already a gig right there. I also suspect that there's a lot of reinventing the wheel going on, since there's 4…

"Reinventing wheels" are represented by the machine-code outlining :)

These are code. Swift is a safe language with more runtime checks than other "zero-abstraction" languages. It also support "value" semantics and can deploy monomorphization for generics (although no guarantee). All these means you can have functions with slightly different view models duplicated many times throughout the binary.

Not to mention the language itself need to generate a lot of retain / releases for refcounting purpose (the blog post also pointed this out).

All in all, Swift as a language is not particularly optimized for small binary sizes, and there are a lot of trade-offs made to improve the usability rather than binary size. That has been said, there can be more opportunities exploited (and right now not) to reduce the binary size from compiler side.

Re: How Uber Deals with Large iOS App Size

#62

Post by jtsiskin »

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

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.

Re: How Uber Deals with Large iOS App Size

#64

Post by true_religion »

jandrese wrote: post #53
user5994461 wrote: post #43

Earlier quoted context omitted.

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

It's like 5MB and you have to be connected to the Internet to use Uber in the first place.

This is anecdotal but...

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.

Re: How Uber Deals with Large iOS App Size

#65

Post by sond813 »

ketralnis wrote: post #8

Can someone help me understand this? They blame the source of the large bundle size on: > The choice of Swift as our primary programming language, our fast-paced development environment and feature additions, layered software and its dependencies, and statically linked platform libraries result in large app binaries but can somebody familiar with iOS development explain what makes app bundles so big? Actual CPU instr…

Uber's article focuses on binary size, but the App Store 309mb number is app bundle size. 120mb of this is not coming from the binary. I have a breakdown of this here: https://news.ycombinator.com/item?id=25380198

App size can be measured in many ways like download size, install size, binary size, thinned size. I wrote about the most important ones here: https://docs.emergetools.com/docs/what-is-app-size

Re: How Uber Deals with Large iOS App Size

#66

Post by 908B64B197 »

Scoundreller wrote: post #21
jedberg wrote: 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?

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

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

Re: How Uber Deals with Large iOS App Size

#67

Post by NikolaNovak »

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.

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.

Re: How Uber Deals with Large iOS App Size

#68

Post by [deleted] »

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

[deleted]

Re: How Uber Deals with Large iOS App Size

#69

Post by amelius »

doggodaddo78 wrote: post #45
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.

How do you expect to hail a taxi when you don't have internet access in the first place?

Does the app use SMS when the internet connection is lost?

Re: How Uber Deals with Large iOS App Size

#70

Post by rememberlenny »

sond813 wrote: post #48

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

"The Lyft app has hundreds of duplicate files, the largest consumer of space is a single asset catalog copied 73 times in separate bundles. Another asset catalog that is virtually identical except for the timestamp at which it was created is copied 67 times. Each of these contain nothing but 482 colors (colors can be stored in asset catalogs to simplify management of dark mode). With each one taking ~250kb these quickly eat up 35mb."

I read this as: Lyft installed Dark mode for 35mb. I can only imagine what my JavaScript modules are doing behind the scenes.

Post reply on HN