[ketralnis]

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?

[sond813]

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

[bhupy]

I'd say this is the most comprehensive breakdown: https://news.ycombinator.com/item?id=25376346

[ketralnis]

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

[bhupy]

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]

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]

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]

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

[dep_b]

Redoing the same code feature does not lead to exactly the same machine code

[johncolanduoni]

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.

[novok]

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.

[mandelbrotwurst]

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.