[HN Gopher] How Uber Deals with Large iOS App Size
___________________________________________________________________
How Uber Deals with Large iOS App Size
Author : rakingleaves
Score : 133 points
Date : 2021-02-26 17:42 UTC (5 hours ago)
(HTM) web link (eng.uber.com)
(TXT) w3m dump (eng.uber.com)
| danpalmer wrote:
| 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.
| novok wrote:
| Well since on demand resources were made for games (lua is
| specifically called out as 'ok'), I could imagine many games
| also making their initial size far smaller if they used binary
| code to make new levels or regions. Games are very large chunk
| of the app store and it's revenue.
| dmitriid wrote:
| 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.
| satya71 wrote:
| Good read. Good to know that Uber engineering culture was as
| much of a dumpster fire (despite the brilliant moves) as their
| product.
| whoisburbansky wrote:
| > _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]
| speedgoose wrote:
| 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 ?
| donarb wrote:
| This article is bogus. They spend a whole bunch of time
| benchmarking build sizes, nothing about why they need so much
| code in an iOS app to begin with.
|
| Apple has dropped limits for large app downloads on cellular.
| They now put up a dialog to tell the user how big the download
| is and if they wish to defer to a WiFi download.
|
| I checked the size of the Uber app and it's about 300MB. Uber
| Driver is 232MB and Uber Eats is 228MB.
| thegeomaster wrote:
| It has... _a few million_... lines of code?
|
| What?
|
| Linux has 30 million of C!
|
| I'm speechless. I cannot fathom how & why.
| edoceo wrote:
| Cannot fathom why LOC is a metric? Me neither. Lots of stuff
| has millions of lines of code in various languages with wide
| ranging feature-sets and functionality. LOC has near zero
| meaning across the language/project boundary.
| [deleted]
| dntrkv wrote:
| How? 1000 engineers x 1000 LoC/each = 1M LoC
|
| Why? If you have 100+ engineers at any given time, shipping
| features over a period of a few years, you'll hit 1M in no
| time.
|
| It sounds like a lot, but it really isn't when you consider the
| amount of people working on it.
|
| Now whether or not you can build the same thing with less LoC,
| probably. But it's not like it was built from the ground up
| with every piece of functionality planned out from day 1, so
| there will be inefficiencies.
|
| Comparing it to Linux is pointless. Platforms should be
| relatively stable, products are ever changing and the shelf-
| life of the code is sometimes measured in weeks/months.
| travisgriggs wrote:
| I've observed that lines of code are measured differently based
| on whether the writer is trying to convince the audience that
| the subject matter is big and complicated and the reader should
| respect the magnitude of dealing with this particular piece of
| software OR whether the author wants you to appreciate the
| brevity/simplicity/approachability of the software in question.
| The first decision made in this decision tree is whether you
| just use wc _, or whether you filter out empty lines. Next goes
| the comments. Next goes syntactically less significant lines
| (just a closing brace that_ could* go on the previous line).
| Wash rinse repeat.
|
| It's a variant of the "I didn't have time to write you a short
| ____ so I wrote a long one instead" adage.
|
| I would guess (but only guess) that this article erred on the
| side overstating size.
| bhupy wrote:
| 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
| jedberg wrote:
| 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?
| bhupy wrote:
| > 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.
| sond813 wrote:
| Starbucks has a separate China app. I suspect a part of
| this is due to app size because there are regions specific
| SDKs. Another is likely security. Regulations in some
| countries require data to be shared with the government and
| they don't want SDKs that collect this data to be included
| in more privacy focused regions.
| mkipper wrote:
| 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.
| owenversteeg wrote:
| Totally different requirements. Some countries' fast food
| apps are for mobile ordering and delivery, some are a
| giant collection of coupons, and some are only for
| nutritional information. And some are just for
| promotional activities (only used for various promotional
| calendars.) After seeing all the different APKs I tried
| out a few for different countries out of curiosity and at
| least for Burger King they were entirely different
| applications with completely different use cases. To cram
| them all into one global app would be an enormous mess.
| jdminhbg wrote:
| 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.
| jedberg wrote:
| Probably payment APIs, just like Uber. Or they are
| developed by different local app shops.
| jedberg wrote:
| eBay is one that comes to mind right away (unless they
| changed it recently).
|
| Google Pay is another one. They have a dedicate app in
| Singapore.
|
| It seems like a lot of them went to single apps when they
| realized they could download data packs within the app.
| Stuff like Rick Steves guided tour apps used to be separate
| per city, but now it's a single app where you download the
| data for a certain city.
|
| But I think you're right that all the major FAANG apps are
| single-binary.
| paulvorobyev wrote:
| >Do you have some examples? Genuinely curious. To my
| knowledge, most of the major FAANG apps are single-binary.
|
| Worked on iOS app size at a FAANG for a couple of years --
| this is untrue. At the very least there are different
| binaries for watch vs iPhone architectures.
| Scoundreller wrote:
| 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 complicated.
| 908B64B197 wrote:
| > 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.
| dangwu wrote:
| The downside is trying to download Uber for the first time
| when arriving at an airport. However, I think Uber is so
| ubiquitous now that it's the likely to already be
| installed.
| Farbklex wrote:
| 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.
| megablast wrote:
| Which sucks. I arrive in a new country, and need to find
| internet access???
| PudgePacket wrote:
| Mate.. how are you going to get your uber anyway without
| internet?
| viraptor wrote:
| If you want to use Uber afterwards... yes, you already
| established you'll rely on internet access.
| deadbunny wrote:
| How are you ordering an Uber without internet access?
| piannucci wrote:
| Interesting. I have had bad cell connectivity in unfamiliar
| airports, though, where I could barely keep a connection to
| e.g. the Lyft servers. What if I can't download the module
| when I need it? I don't think requiring the user to
| download it in advance of their flight is viable, either.
| If we lived in a world of universal, homogeneous,
| inexpensive connectivity, I'd be satisfied with the
| solution you mention. I guess if they had location/policy
| micro-modules small enough to fit in a single MTU, then
| anybody who could connect to Uber at all could be served.
|
| It still boggles my mind that there could be ~100M
| meaningful instructions in a program.
| fractionalhare wrote:
| No, it's also substantially different between certain cities
| and regions in the CONUS. Otherwise that might be viable.
| spoonjim wrote:
| 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.
| Borlands wrote:
| Exactly same experience, from San Fran to Singapore and in
| between. Never really realised how good we have it, such a
| good point
| gcbirzan wrote:
| > 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?!
| jscholes wrote:
| > 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.
| onemiketwelve wrote:
| 75% of Ubers in Egypt didn't have seat belts. It's just
| tucked away and not culturally the norm
| pradn wrote:
| People have even chuckled when I reached to put a
| seatbelt on in India. :)
| ameen wrote:
| Not sure what to make of this. I'm Indian and the last
| time I was in India, there was strict execution of the
| seatbelt law and offenders were made to wait and fined
| heavily. Most drivers were wearing seatbelts.
|
| Maybe because it was in Chennai, a southern state and not
| in Mumbai or Delhi.
| dliff wrote:
| While I had a positive experience with the Uber app
| software-wise (app functioned seamlessly landing in Mumbai
| from U.S.A.), Uber as a service was not really comparable
| to what it is like in the U.S. and developed W. European
| countries. I got the sense that it was more of a strictly
| ride hailing / request service, not much accountability
| required from the driver. Often had > 3 drivers cancel
| after 10-15 minutes waiting before actually getting a ride.
| That being said, it was still a hugely valuable service to
| have in India as a foreigner.
| ForHackernews wrote:
| 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.
| spoonjim wrote:
| That 1% of users represents a lot more than 1% of profit,
| and engineering an application that is that robust across
| scenarios has benefits to the stationary users transiting
| through multiple scenarios as well (surge pricing to
| normal, credit card to Apple Pay, car ride to scooter
| ride, etc).
| Cederfjard wrote:
| Why are you assuming that splitting it into multiple apps
| would require less engineering resources than keeping
| just one?
| ssdspoimdsjvv wrote:
| I don't have any numbers, but I would guess that a good
| part of Uber's user base consists of people that travel
| often. Not having to download a new app or update every
| time you go to a different country is a huge advantage.
| manigandham wrote:
| It's much more complicated than just countries. If you
| read the linked comment then you'll learn that it's
| includes many regional customizations, even down to
| specific cities and airports.
|
| An app for travel should absolutely prioritize UX and
| ease of use _as you travel_ , however far away your
| destination is.
| minhazm wrote:
| It's not even just per country. If you fly to certain
| airports in certain states they have different rules that
| affect what the Uber app can do. Do they maintain a
| separate app for Washington and for New York? It gets
| pretty messy pretty quickly. Not only do you have to
| maintain these different edge cases, but you also need to
| maintain separate applications and all of the problems
| associated with that like keeping libraries and API's in
| sync between them.
| corin_ wrote:
| I'm probably missing something obvious as I'm tired, but
| why does the Uber app need stuff like specific airport
| rules stored in it rather than pulled from their servers
| when needed?
|
| Map apps let you look at any city in the world without
| needing all of that data inside the core app, and if you
| have enough data to use the Uber app wouldn't you almost
| certainly also be fine to have it download in the
| background the required info (coordinates of where pickup
| is or isn't allowed, specific instructions message to
| display, etc.) the same as it receives information about
| local pricing, location of available cars nearby and so
| on?
| ameen wrote:
| Connectivity at airports is not the best - if you're on
| an expensive data plan those extra MBs cost a pretty
| penny which might put off the customer.
|
| You need to think about the larger picture.
| viraptor wrote:
| Give the streaming of location data for cars in the area,
| I don't think they care much about those extra MBs. If
| they did, you'd get a "N cars within X km of you", not a
| live-ish map.
|
| A quick summary like "extra fee for airport pickup: X,
| pickup location restricted to: Y, etc." should be pretty
| comparable.
| corin_ wrote:
| Wouldn't it be significantly less than a MB for all the
| info about "how does Uber work at this airport" info to
| come in json or whatever? It could surely survive without
| downloading special airport-specific media like logos, do
| the airport rules require complicated heavy code on the
| phone?
|
| Thinking of my experience with Uber at airports, it's
| generally stuff like "pickups from this terminal are only
| available at the west exit" (show on map - so needs
| coordinates and message text), or "There is a PS10
| airport pickup fee for all private hire vehicles here
| which will be added to your bill", or whatever along
| those lines.
|
| But perhaps your point still stands even if it's KBs
| rather than MBs.
| MattGaiser wrote:
| > 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.
| ljf wrote:
| Totally this. It isn't uncommon for a whales (usually 1
| to 2 percent of an apps users) to account for 30 to 50
| percent of their profit. So it is very worth thinking of
| those customers first.
|
| Not all customers are equal. And if you build your app or
| site without knowing that you may well chase the wrong
| features.
| StreamBright wrote:
| 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. For Uber it would be a win
| too, reducing the size of the app significantly. Maybe it
| is only me.
| bobbylarrybobby wrote:
| Don't app updates only push deltas anyway? It's only the
| initial install that's large.
| Bjartr wrote:
| 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.
| MattGaiser wrote:
| Even as an avid Hacker News user, I wouldn't tailor an
| app download to save bandwidth/space. Both of those are
| abundant.
| ChrisKingWebDev wrote:
| I would agree with this. At home I walk, ride my bike,
| get on transit, rent a carshare etc. When I'm travelling,
| I'm walking or calling an Uber/Lyft. I'll take a train or
| bus only if it's super easy to navigate.
| MattGaiser wrote:
| I spent a lot of 2018/2019 travelling around North
| America. It was wonderful to never have to consider a
| taxi.
| rsj_hn wrote:
| Same here. In my local area I understand the transit. I
| have a transit card. But when I am in a foreign city that
| speaks a different language these are not realistic
| options unless I spend effort on figuring that out and
| deal with local municipal transit authorities, which is
| not the vacation experience I am looking for.
| NikolaNovak wrote:
| 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.
| ghaff wrote:
| I'm in the same boat. To a first approximation, I never
| use Uber in my local metro area. To a second
| approximation, I don't use it much traveling either. I'll
| often grab a cab if it's convenient rather than waiting
| for an Uber/Lyft to show up. Or if there's a good public
| transit option to my hotel I'll use that. In spite of
| (normally) 100+ days of travel per year I maybe use Uber
| a dozen times a year. (I do use a private car service to
| take me to the airport, but again Uber wouldn't be very
| good for that purpose.)
| wdb wrote:
| Personally, I would download whatever the dominating
| hailing app is in the country. Most of the time its cheaper
| than Uber like Grab in parts of Asia
| reader_mode wrote:
| If you're landing in Asia from the US you're probably not
| going to care about the price (there are exceptions), and
| Uber has been reliable for me travelling, if that costs a
| few % more than the local version I'd be happy to pay for
| convenience.
| ProAm wrote:
| > Uber has been reliable for me travelling
|
| Unless India? [1]
|
| [1]
| https://www.theguardian.com/technology/2017/jun/08/uber-
| exec...
| tobmlt wrote:
| Also, this was an entertaining retrospective recently posted:
|
| https://mobile.twitter.com/stantwinb/status/1336890442768547...
|
| I can't seem to find the old link, but I'm pretty sure it was
| on hacker news and somebody posted a nice collation of the
| posts.
| jtsiskin wrote:
| 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.
| jandrese wrote:
| 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.
|
| Unfortunately the way Apple and Google set up their walled
| gardens makes this impossible. I guess Apple would prefer if
| the Uber app dropped all of that and just made everybody use
| ApplePay instead.
| megablast wrote:
| Another person who think the internet is available
| everywhere.
| deadbunny wrote:
| How are all you people without internet access ordering
| Ubers?
| user5994461 wrote:
| >>> 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.
| jandrese wrote:
| It's like 5MB and you have to be connected to the Internet
| to use Uber in the first place.
| true_religion wrote:
| 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.
| vlovich123 wrote:
| This keeps getting repeated in this thread & I keep not
| understanding it. If I downloaded Uber & set it up with the
| payment method that I need, why would that payment method
| suddenly change at 1am in India?
|
| The way this should work is when you set up payment option
| X, it downloads the relevant payment info & then you're set
| from then on without any other modules unless you add a new
| payment option. Likely pre-bundle the generally "global"
| options (Apple Pay/Android Pay since those are platform-
| native & credit cards since those are likely small
| implementations).
|
| The real reason is that you will always have drop-off
| because the download phase is split in two (on the other
| hand you'll have increase in installs because the app size
| is smaller). That would need App Store integration with the
| loadable modules so that you could say "Install these
| payment features of the app". This may not be a win because
| again, it requires the user to do more work. Simple for
| everyday users will often win the day even if inefficient
| vs more optimal options that achieve that optimality by
| pushing complication to the user.
| gregoriol wrote:
| 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
| colinmhayes wrote:
| Uber doesn't work without decent internet access though.
| Maybe you can make he argument for $$/Mb, but there's no
| point in uber creating the app so that you can get to the
| pay screen without internet when you need the internet to
| use uber.
| novok wrote:
| 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.
| sond813 wrote:
| Google encourages this with feature modules and app bundles.
| Apple doesn't allow it because they've always been against
| downloading executable code that doesn't go through app
| review. Same reason they don't like game streaming or
| downloading react native at runtime.
|
| I'd like to see them open up this possibility in a controlled
| way one day. Something like a review process for feature
| modules that could be updated in a similar process to full
| apps.
| abductee_hg wrote:
| ...as a demoscener who has released multiple 64k/4k intros I
| hereby formally say: LOL.
| rockmeamedee wrote:
| 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
| alien_ wrote:
| Wouldn't UPX give similar results in deduplicating binary code?
| ketralnis wrote:
| 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?
| novok wrote:
| The same equivalent code in objective-c is significantly
| smaller than the same code with swift. Swift has a lot of
| implicit specializing templates which really bloats code size,
| like it would in C++. If you compare binary sizes of apps from
| the pre-swift era, you'll notice many are far smaller. Like I
| remember tweetbot being 4.5mb in the pre ios 6 days.
| bhupy wrote:
| I'd say this is the most comprehensive breakdown:
| https://news.ycombinator.com/item?id=25376346
| ketralnis wrote:
| 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.)
| johncolanduoni wrote:
| The argument you'll have by saying that for its sake will
| be pretty useless, because source code and machine code are
| nowhere near 1:1 in size.
| bhupy wrote:
| 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.
| saagarjha wrote:
| This is par for the course for large companies with many
| engineers working on writing code without spending enough
| time on keeping app sizes low.
| dangwu wrote:
| 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 40+ feature teams all working on
| the app at the same time.
| liuliu wrote:
| "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.
| [deleted]
| mandelbrotwurst wrote:
| I'm not very familiar with iOS dev, but I'd suspect a lot of
| dependencies, yes.
|
| Also, the Uber app has a LOT more features than you would
| expect at a glance, due to extensive customization of the
| experience (i.e. feature flagging) along many vectors, and so
| it wouldn't surprise me at all if this ends up adding to a lot
| of code.
|
| Edit: Linked post from sibling commenter bhupy outlines this in
| detail.
| sond813 wrote:
| 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
| BigBalli wrote:
| 328.9 MB I'm sure it could easily be 1/10 of that while keeping
| all features important to the user.
| jamestenglish wrote:
| Important to a user in 1 region/country.
|
| https://news.ycombinator.com/item?id=25376346
|
| Uber is a global app, so the other 9/10s of the code is for all
| the features and functionality you'll never see outside your
| region since there is currently no way to split up binaries by
| region.
| jbverschoor wrote:
| 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
| jakub_g wrote:
| 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.
| jbverschoor wrote:
| 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.
| alien_ wrote:
| 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.
| jakub_g wrote:
| Nice check. I guess they relaxed a bit since Apple raised
| the app size limits :) (sorry for the snark in the
| previous post)
| ohiovr wrote:
| 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.
| km3r wrote:
| A stream may also make it harder for the app to work in areas
| with poor connection. Which, given Uber's use case, is probably
| a likely scenario and one that could lose a lot of customers to
| competitors.
| ohiovr wrote:
| From some simple experiences with recording my desktop to a
| mp4 file I've found the delta compression to be extremely
| efficient when there is only a little motion. Perhaps still a
| deal killer, true.
| adrr wrote:
| Pull it on first run and cache it. If you're in place with a
| poor internet connection, you aren't going to be able to
| download the app from app store any way. I am going to assume
| 80% of the code packaged in the app in the app is never used
| by a majority of their customer base. Like all the business
| features where a company give their employees allowances.
| doggodaddo78 wrote:
| 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.
| ohiovr wrote:
| Especially getting lost in a cell dead zone.
|
| Its not exactly a web app but it could be made that way with
| WebRTC.
| amelius wrote:
| 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?
| lxe wrote:
| That could trigger the App Store review block. But this is
| Uber, so I'm guessing there's special treatment :)
| ohiovr wrote:
| Interesting. I've not looked at the long rule list in a
| while.
| pgp001 wrote:
| wow, all that code and it's still absolutely terrible to use.
| Imagine
| elpakal wrote:
| 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.
| saagarjha wrote:
| 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.
| draw_down wrote:
| > usually the problem is
|
| Usually, sure. But sometimes there is a lot to do, and if I
| may, Uber is not your usual app. At the point where you're
| being very choosy about the access modifiers on your classes,
| you probably thought about icon assets already.
|
| Someone elsewhere in thread linked to a partial list of
| concerns the app needs to cover, many of which are location-
| specific. You might say "well split the app by geography", but
| that just trades one set of problems for another, and that new
| set of problems could well be worse for the business overall.
| Paying a team of people to do this junk may be a whole lot
| cheaper than suffering a reduction in customer engagement when
| they fly to a new country and don't have the right app anymore.
| superkuh wrote:
| 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.
| viscanti wrote:
| According to their public investor reports, they've been EBIDTA
| profitable on Rides for years. They're also profitable in more
| rationalized Eats markets (markets where there aren't other VC
| funded companies burning hundreds of millions of dollars on
| subsidies). What do they need self driving for?
| superkuh wrote:
| To still be profitable after they stop breaking local laws
| and regulation catches up with them.
| https://horanaviation.com/publications-uber
| tomaskafka wrote:
| 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.
| Spivak wrote:
| Oh I would kill for a sub half hour build time at $dayjob.
| StreamBright wrote:
| 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.
| sond813 wrote:
| 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-...
| dang wrote:
| Discussed here:
|
| _Launch HN: Emerge (YC W21) - Monitor and reduce iOS app size_
| - https://news.ycombinator.com/item?id=26014180 - Feb 2021 (44
| comments)
| rememberlenny wrote:
| "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.
| trevor-e wrote:
| 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.
| rememberlenny wrote:
| I'm curious - does React Native/Expo do any better job at
| this, with tree-shaking and package building?
| sond813 wrote:
| Yep this is exactly the problem I'm trying to solve! A lot
| of large app companies have switched from Xcode to third
| party build systems like Buck or Bazel. This can make
| things faster but even more confusing. I've found analyzing
| the actual build products to be the best solution to make
| sure nothing unintended is happening.
| [deleted]
| etaioinshrdlu wrote:
| 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)...
| viktorcode wrote:
| > 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.
| layoutIfNeeded wrote:
| They are already waaaay beyond the maintainability threshold.
| alien_ wrote:
| 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.
| tenacious_tuna wrote:
| 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.)
___________________________________________________________________
(page generated 2021-02-26 23:00 UTC)