Live data from Hacker News

Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

openradar.me

1–10 of 142 posts

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

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

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#4
post #3

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.

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.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#5
This appears to be bitcode. It probably means they just starting making use of more metadata or something that is now included in the bitcode.

Bitcode also now deliberately trades off size vs speed and includes indexes used for LTO, etc. They could be including those.

You should almost always expect bitcode to get beat by "llvm-dis|xz", because the goal of bitcode is not to be the most compact possible format, but instead, a compact format the compiler can use effectively :)

Now, if actual on-device binary sizes increased, my guesses would be:

1. it now includes bitcode, or another architecture, in the binary (which would be interesting)

2. Something has gone horribly horribly wrong :P Really, speaking as a guy whose org maintains the toolchains for platforms like this, there's a 0% chance we wouldn't notice a 2x-3x size increase.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#7
post #3

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.

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.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#8
post #3

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.

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?

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#9
post #3

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.

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?

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#10
post #9
post #3

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.

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.
Post reply on HN