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

21–30 of 142 posts

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

#21

Post by jhammer »

bdash wrote: post #18
Exuma wrote: post #16

Earlier quoted context omitted.

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 ver…

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

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

#22

Post by notyourwork »

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…

This is the type of comment I come to hackernews for. Great summary of the possible situation.

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

#23

Post by sneak »

qzervaas wrote: post #19
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).

I said explicitly in my comment that I don't think this is some grand conspiracy. I don't think Xcode makes big files to use up disk space. I think Apple just has little incentive across the entire ecosystem to use less storage or use storage more efficiently.

Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interaction. It should come in major handy in the OSX app store when ARM64 Macbooks ship in a year or two. A full app store of working apps on hardware launch day will make the bitcode requirement worth it when it's the smoothest architecture transition they've ever done (out of 680x0->ppc and ppc->x86).

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

#24

Post by natch »

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.

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

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

#25

Post by [deleted] »

sneak wrote: post #23
qzervaas wrote: post #19

Earlier quoted context omitted.

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

I said explicitly in my comment that I don't think this is some grand conspiracy. I don't think Xcode makes big files to use up disk space. I think Apple just has little incentive across the entire ecosystem to use less storage or use storage more efficiently. Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interac…

[deleted]

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

#27

Post by DavidSJ »

adomanico wrote: post #20
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

60 millibits is pretty small.

(Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)

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

#28

Post by jsmthrowaway »

DavidSJ wrote: post #27
adomanico wrote: post #20

Earlier quoted context omitted.

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

60 millibits is pretty small. (Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)

And I really wish people wouldn't start this argument when it's clear what was meant from context. We can't all get our wishes. :)

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

#29

Post by LeoNatan25 »

sneak wrote: post #23
qzervaas wrote: post #19

Earlier quoted context omitted.

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

I said explicitly in my comment that I don't think this is some grand conspiracy. I don't think Xcode makes big files to use up disk space. I think Apple just has little incentive across the entire ecosystem to use less storage or use storage more efficiently. Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interac…

Bitcode does not allow cross-architectural builds. This is a common misconception. IR (& bitcode) includes architecture and platform-specific ABI. What it does allow is for better optimizations as the LLVM backend optimizer improves.

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

#30

Post by LeoNatan25 »

qzervaas wrote: post #19
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).

Bitcode is unrelated to app slicing and app thinning. These can be performed regardless of bitcode submission.
Post reply on HN