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

131–140 of 215 posts

Re: How Uber Deals with Large iOS App Size

#131

Post by deadbunny »

megablast wrote: post #108
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…

Another person who think the internet is available everywhere.

How are all you people without internet access ordering Ubers?

Re: How Uber Deals with Large iOS App Size

#132

Post by smeyer »

908B64B197 wrote: post #66
Scoundreller wrote: post #21

Earlier quoted context omitted.

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…

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

Re: How Uber Deals with Large iOS App Size

#133

Post by ljm »

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

After reading that I feel like coining a law:

Any discussion about software distribution will inevitably result in an argument about dynamic linking vs. static linking.

Re: How Uber Deals with Large iOS App Size

#134

Post by saagarjha »

trevor-e wrote: post #79
rememberlenny wrote: post #70

Earlier quoted context omitted.

"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 quic…

My biggest complaint with iOS development is how confusing Xcode's build system is. Extracting code out to shared frameworks is a confusing process and I can understand how so many of the top apps get it wrong. Also, it's clearly not a priority for Apple because they don't provide easy inspection tools. Best case for them is the user buys a new phone with more storage.

I agree that it's not necessarily the most straightforwards, but I would think that in the hundreds of engineers they have at least some have figured out how it works to the point to which they can do this…

Re: How Uber Deals with Large iOS App Size

#136

Post by ramraj07 »

spoonjim wrote: post #27
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?

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.

Re: How Uber Deals with Large iOS App Size

#137

Post by draw_down »

viktorcode wrote: post #90

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

Unfortunately, "well just do less stuff!" is not really an argument nor necessarily even an option.

I'm seeing a lot of comments in this thread blithely assuming that they're bumping up against limits because they're doing something fundamentally wrong, without considering the cost of arranging things differently. Maybe they're doing a lot and the confluence of things they're doing will be costly in any direction, and they chose this one.

To wit, they probably wouldn't have published this if they were just royally fucking up. I think it's likely that other orgs are starting to bump into these issues and wanted to hear what Uber does about it.

Re: How Uber Deals with Large iOS App Size

#138

Post by depressedpanda »

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.

Web apps can be cached and run entirely offline.

https://en.m.wikipedia.org/wiki/Progressive_web_application#...

Re: How Uber Deals with Large iOS App Size

#139

Post by rrdharan »

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…

Is the name a nod to Gentoo's emerge? (https://wiki.gentoo.org/wiki/Portage#emerge)

Just curious.

Re: How Uber Deals with Large iOS App Size

#140

Post by lgg »

alien_ wrote: post #109

Wouldn't UPX give similar results in deduplicating binary code?

No. UPX won't work on iOS for various reasons, but it is also generally speaking a poor choice to use on macOS. There are several issues here:

* It usually does not reduce the size of the file in transit, as most files are compressed for distribution, and even if they are not most http servers will use transparent gzip compression

* It does not actually reduce the size of files at rest since APFS (and HFS+ before it) support transparent decompression. The layer this is handled at is sufficiently low level most people do not even realize it is happening (stat(2) returns the uncompressed size, you need to look at extended attributes to see the real on disk size). Admittedly this does not handle binaries that are drag installed on macOS. You can find out more details here: https://github.com/RJVB/afsctool

* UPX slows down app launch because you know have to decompress the entire executable before you launch it, which means you need need to read the entire compressed executable from disk before you launch it

* UPX greatly increases the memory overhead of running an application. Because you decompressed it in memory all the executable pages are dirty memory that need to be kept in memory or written to swap. That means you immediately loaded everything into memory instead of just the pages you needed. Normally a binaries pages are brought in from disk as necessary, and because of that they are unmodified clean memory. The built in compression support compresses smaller blocks of the binary and thus can still bring them in individually (technically this reduces the compression, but the trade off of being able to keep page demand loading working is more than worth it).

* UPX makes the system perform worse under memory pressure. The fact that it generates decompresses the pages in userspace means that from the kernels perspective they are dirty. If the kernel needs to evict them due to memory pressure it needs to swap them out. Uncompressed files (or those compressed with the builtin filesystem compression) are clean memory, which means that under memory pressure the kernel can just through them out and then reload them from the file later, no need to write out the pages.

In the past there were legitimate reasons for tools like UPX, and there may still be on other operating systems, but it simply does not make sense on Darwin platforms.

Post reply on HN