Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

openradar.me

Post reply on HN
Print view View original

11–20 of 142 posts

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

#11

Post by anderscarling »

sigjuice wrote: post #9
bdash wrote: 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?

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.

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

#12

Post by bdash »

adomanico wrote: post #4
bdash wrote: 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.

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.

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

#13

Post by Exuma »

bdash wrote: post #12
adomanico wrote: post #4

Earlier quoted context omitted.

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.

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?

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

#14

Post by bdash »

anderscarling wrote: post #7
bdash wrote: 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 t…

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.

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

#15

Post by bdash »

Exuma wrote: post #13
bdash wrote: post #12

Earlier quoted context omitted.

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?

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

#16

Post by Exuma »

bdash wrote: post #15
Exuma wrote: post #13

Earlier quoted context omitted.

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.

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

#17

Post by sneak »

Apple charges $1200 to upgrade the latest touch bar rMBP from 512GB to 2TB of flash.

Let's not forget that they are a hardware vendor.

I don't think it's some grand conspiracy theory, but the interests of the vendor and of the user are not precisely aligned when it comes to efficient usage of storage. (The lack of stripping applications of their alternate language content on install/download also comes to mind.)

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

#18

Post by bdash »

Exuma wrote: post #16
bdash wrote: post #15

Earlier quoted context omitted.

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.

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

#19

Post by qzervaas »

sneak wrote: post #17

Apple charges $1200 to upgrade the latest touch bar rMBP from 512GB to 2TB of flash. Let's not forget that they are a hardware vendor. I don't think it's some grand conspiracy theory, but the interests of the vendor and of the user are not precisely aligned when it comes to efficient usage of storage. (The lack of stripping applications of their alternate language content on install/download also comes to mind.)

This theory is pretty easily debunked when you consider the primary goal of bitcode is to strip assets from apps that aren't relevant to a user's device, hence taking up less space.

(For example, removing @2x images for a plus device that uses @3x images, or vice-versa).

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

#20

Post by adomanico »

DannyBee wrote: post #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 in…

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY

These numbers were all around 60mb on Xcode 8.2.1

Post reply on HN