Hacker News Reader

Comment by bdash | Hacker News Reader

Note that the size increase is in the _bitcode_ portion of the binary. This slice is stripped from the binary before it makes it to the user's device. This means the size increase is merely an inconvenience during the development process, and has no impact on the size of apps as users see them.

View on HN

As [1] points out above, while the largest increase is in the bitcode, it's still a 2.2x increase in the non-bitcode portions of the binary.

[1] - https://news.ycombinator.com/item?id=13993961

And the 2.2x non-bitcode increase seems consistent with adomanico's report of a 2~3x increase of "App Store File Sizes" as reported by iTunes Connect: https://news.ycombinator.com/item?id=13992107

Would be interesting to see numbers for the compiled, stripped and thinned binary the end user will download from the App Store (they are in the details view for the app build on iTunes Connect). My guess is that at least most of the change should go away there.

With bitcode, app thinning and what not in the mix the Xcode build artifact is so much different from what's actually being downloaded it's hard to tell if this radar has real world implications for anyone but the developer uploading the build to apple. Still interesting, and potentially annoying though.

The Apple bug report was filed by my colleague, JP, after we noticed that the built size of Realm's frameworks dramatically increased after updating to Xcode 8.3. We pay attention to the built size of our frameworks as we distribute precompiled versions of them (https://github.com/realm/realm-cocoa/releases), and a signifiant size increase inconveniences our users. We've not tested the impact of the size on an app installed via the App Store, but since the increase is limited to the bitcode portion of the binary we have no reason to think it will be affected.

I'm not well versed in the details of iOS development. Why is this inconvenient during development? Is the bitcode portion copied to your device and is a slow process?

Some people like to check in precompiled versions of their dependencies. Others like to distribute precompiled versions of their frameworks or libraries. Larger binaries aren't great for either of those cases.

Larger files to store and upload to iTunes Connect mostly. I don't think bitcode is ever transferred to development devices.

I guess there is also a risk that the compilation process generating 3x larger files could also be slower as more work are being done - but that's just speculation.

Unfortunately this doesn't seem to be the case.

Binary sizes in iTunes connect (from our Xcode 8.3 build) all were 2x-3x larger depending on device.

That's troubling. :( Same for both swift and objC?

I think the size iTune Connect reports includes bitcode, and isn't representative of the size of the app once it makes it to a user's device. The information in the original bug report you linked to clearly shows the size increase is limited to the bitcode portion of the binary.

Why would they do that, visually in the store?

I'm not sure what you're asking here. Why would who do what?

Why would they show the full size including bitcode when you go to download it, when it doesn't get sent to the device anyway.

The size I'm referring to is shown in iTunes Connect, which is the administrative side of the App Store that the developer uses to manage their app releases. As far as I'm aware the size shown in the App Store's user-facing UI does reflect the size that will be downloaded by the device. I think it's possible to see this size in iTunes Connect, but since I don't myself have any apps in the App Store I can't easily verify this.

You can see the per-device estimated App Store file sizes in iTunes Connect:

(navigate to your app) > Activity > All Builds > (select the version) > (select the build) > App Store File Sizes

You need to look at the download size on the end user device, not the binary size in iTunesConnect.

Is this also true to user downloads from a website? The majority of your clients get our apps via Enterprise certificates not through the Apple store process.

When you create an archive, Xcode includes the full version of your app but allows you to export variants from the archive. I think most enterprise users disable bitcode for simplicity but it's possible to slice the variants and deliver the correct one to your users based on their device if you want to.

Reply on news.ycombinator.com