from Hacker News

How Uber Deals with Large iOS App Size

by rakingleaves on 2/26/21, 5:42 PM with 202 comments

• by bhupy on 2/26/21, 5:56 PM

  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

• by sond813 on 2/26/21, 6:56 PM

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

• by danpalmer on 2/26/21, 6:38 PM

  I'd like to see Apple expose more control over their app thinning technologies.

  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.

• by ketralnis on 2/26/21, 5:59 PM

  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 instructions or config can't contribute this significantly. The entire Bible is about 4.5mb. If you're writing an app by yourself you almost certainly didn't write that much text in the source code. A sibling comment links to https://news.ycombinator.com/item?id=25376346 which says that they have a lot of screens but even something like "PayTM (15+ screens)" is still just textual source code and config that I don't follow how it gets beyond kilobytes. The App Store places them at 309mb, so ~68 bibles.

  I understand when games are large because they typically ship with images and videos included in the binary for game assets. But for a normal application where does the size come from?

  Is it dependencies? (And how did _they_ get so big?) That weird intro video they have on the loading screen? Are they shipping bitmaps of the cities they have markets in?

• by viktorcode on 2/26/21, 9:16 PM

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

• by dmitriid on 2/26/21, 5:54 PM

  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.

• by saagarjha on 2/26/21, 10:29 PM

  This is certainly an great read, and working on it must have very interesting. That being said, in my experience things like these are invariably technical band-aids over social problems. Whenever I see things like this, often paired with statements like “there’s so many screens and feature flags”, usually the problem is not there but actually in many other processes: for example, the design team adds assets in a way that is not enforced by the usual tooling that checks binary size, or the build process adds duplicate files into the bundle that nobody notices. Sometimes the underlying issue is hard to fix, like if it’s code size explosion due to a custom templating engine, but they really should get addressed at some point. Changes like these don’t actually solve the underlying issues, which can be a benefit for a while, but eventually they become so complex that it is hard to maintain them and they start impacting productivity in harder to measure ways by doing things like increasing build times and reducing the quality of debugging information.

• by whoisburbansky on 2/26/21, 6:16 PM

  > While power law and fractal patterns have revealed themselves in several physical, biological, and man-made phenomena, to our knowledge we are the first to identify their presence in machine-code sequences in computer executable code. Presumably, machine code is a human expression of instructions to a computer and it is well established that all human languages show a power-law in the frequency of the words.

  Made me chuckle. Maybe the authors should look at getting an ACM subscription.

  [https://dl.acm.org/doi/pdf/10.1145/1391984.1391986]

• by etaioinshrdlu on 2/26/21, 9:41 PM

  Machine-code outlining sounds kind of like the opposite of function inlining. Right down to the name! I am amazed I've never heard of this optimization technique being used in compilers before -- it sounds like it could improve performance in many cases by making code smaller (or hurt performance for the same reason that inlining can help performance)...

• by thegeomaster on 2/26/21, 5:56 PM

  It has... a few million... lines of code?

  What?

  Linux has 30 million of C!

  I'm speechless. I cannot fathom how & why.

• by abductee_hg on 2/26/21, 8:52 PM

  ...as a demoscener who has released multiple 64k/4k intros I hereby formally say: LOL.

• by speedgoose on 2/26/21, 5:55 PM

  It's maybe a naive question, but from my point of view I don't understand why it's even a problem. Why is the Uber app so big ?

• by dj_mc_merlin on 2/26/21, 11:04 PM

  I would love to work on something like this. Optimizing assembler instructions for size, speed.. just writing some. How do you get a job in this? Is embedded land like this?

• by mshockwave on 2/27/21, 2:09 AM

  Why not do machine outlining in LTO/ThinLTO? `opt` doesn't really scale with huge module in terms of memory consumption and multi-threading, that's the reason ThinLTO was invented in the first place.

  I think adding machine outlining into LLVM Pass pipeline is still doable with LLVM plugin (with new PassManager)...worst case just come up with a custom LLVM/Clang

• by londons_explore on 2/27/21, 11:25 AM

  So Uber has about 5000 engineers. If all of them write/click/draw 10,000 keystrokes per day, and it's all new code, and Uber has been around 10 years, thats 182 gigabytes of 'human input'.

  Compiling that down to 200 MB isnt too shabby!

• by lgats on 2/27/21, 5:40 AM

  On a smaller note, adding lossless compression to the image assets in the Uber app can save more than 14% of 2.4MB

  If your app has larger images, don't waste user bandwidth and optimize your assets!

• by elpakal on 2/26/21, 9:04 PM

  I was quite surprised by the increase in build times:

  > Overall, 5 rounds of outlining builds in 66 minutes — a 45-minutes addition to the baseline.

• by rockmeamedee on 2/26/21, 9:49 PM

  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

• by alien_ on 2/26/21, 10:17 PM

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

• by pid_0 on 2/27/21, 12:00 AM

  Is part of the strategy using private iOS APIs, tracking everyone outside of ToS, lying about it, getting caught, and then being too large for Apple to actually punish them?

• by tomaskafka on 2/26/21, 7:33 PM

  This seems like a case of sloppy product management saved (or rather having its consequences delayed) by person-years of ingenious engineering.

  Build times in tens of minutes seem terrible.

• by ketamine__ on 2/27/21, 12:11 AM

  Wouldn't native apps be much smaller? I wish more companies did this. Uber on Android handles quite poorly.

• by Triv888 on 2/27/21, 10:30 AM

  Theare essentially compressing their app... ?

• by pgp001 on 2/26/21, 10:26 PM

  wow, all that code and it's still absolutely terrible to use. Imagine

• by BigBalli on 2/26/21, 6:04 PM

  328.9 MB I'm sure it could easily be 1/10 of that while keeping all features important to the user.

• by StreamBright on 2/26/21, 8:40 PM

  It is still amazing to me how Uber cannot narrow down the use cases enough. To me it was a done product in 2014, no need to additional features. I think the software industry as a whole does not have the concept of 1.0. We are trying to ship one more thing all the time.

• by ohiovr on 2/26/21, 5:44 PM

  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.

• by superkuh on 2/26/21, 6:31 PM

  Uber is just a scam to launder saudi blood money through softbank. There is zero chance that human driven cars will go away. And self-driving cars cannot drive on roads with human drivers. Uber is in the later stages of the scam now and have "sold" (actually, they gave 400 million USD to the company they "sold" the division too) their self driving setup. They've admitted the only business model that would make them profitable is impossible. It's over. They're just trying to take the money and run now.

  That their "app" is large is irrelevant to the scam.