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

31–40 of 142 posts

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

#31

Post by jevinskie »

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

App thinning is orthogonal to ENABLE_BITCODE. The App Store could have been thinning app binaries years ago (literally just `lipo -thin`). Apple likely wanted ENABLE_BITCODE for better app store verification and perhaps architecture re-targeting in the future. I very much doubt the latter because Apple seems to have no compunctions about forcing developers to use newer SDKs, rebuilding apps for WatchOS or tvOS, or aggressively deprecating 32-bit only apps in the App Store.

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

#32

Post by jevinskie »

LeoNatan25 wrote: post #29
sneak wrote: post #23

Earlier quoted context omitted.

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.

I would imagine that with enough engineering effort, a cross-architecture "porting" of IR would be feasible. I doubt Apple will bother to do that when they can just force developers to rebuild and republish lest they get left out of the App Store.

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

#33

Post by LeoNatan25 »

jevinskie wrote: post #32
LeoNatan25 wrote: post #29

Earlier quoted context omitted.

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.

I would imagine that with enough engineering effort, a cross-architecture "porting" of IR would be feasible. I doubt Apple will bother to do that when they can just force developers to rebuild and republish lest they get left out of the App Store.

Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation. You cannot use what is not there. When compiling a C language, macros are used to determine architecture and platform, and extra code is simply not compiled. The most simplest of examples is endianness handling, which would be totally broken if Intel-compiled code is automagically made to run on arm.

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

#34

Post by saghm »

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

Since you said that the "m" is obvious from context, I'll compromise from now on and use "mB" exclusively

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

#36

Post by paulddraper »

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

Huh, and I thought mb was "make bucket", like aws s3 mb.

http://docs.aws.amazon.com/cli/latest/reference/s3/mb.html

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

#37

Post by HappyTypist »

alien3d wrote: post #35

The same codebase compiled with Xcode 8.3 produces a binary about three times larger at 158MB, including 70MB for bitcode alone. Apple limit 100 mb per download.. So this big issue for all developer.We need apple to remove the limitation over 100 mb or atleast 1GB.

Bitcode size =/= binary size. Your binary sizes will remain similar.

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

#38

Post by astrange »

LeoNatan25 wrote: post #33
jevinskie wrote: post #32

Earlier quoted context omitted.

I would imagine that with enough engineering effort, a cross-architecture "porting" of IR would be feasible. I doubt Apple will bother to do that when they can just force developers to rebuild and republish lest they get left out of the App Store.

Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation. You cannot use what is not there. When compiling a C language, macros are used to determine architecture and platform, and extra code is simply not compiled. The most simplest of examples is endianness handling, which would be totally broken if Intel-compiled code is automagically made to run on arm.

iOS and macOS are both little-endian, but there are many other differences between platforms (like pointer alignment, SIMD size, ObjC ABI) and bitcode makes no effort at all to accommodate them.

Bitcode can used to recompile for minor ARM updates, compiler bugs, new optimizations etc without having to get developers to submit new binaries.

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

#39

Post by caf »

LeoNatan25 wrote: post #29
sneak wrote: post #23

Earlier quoted context omitted.

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.

This is potentially a problem, as better optimisers can bring to life previously dormant bugs in the code.

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

#40

Post by alien3d »

HappyTypist wrote: post #37
alien3d wrote: post #35

The same codebase compiled with Xcode 8.3 produces a binary about three times larger at 158MB, including 70MB for bitcode alone. Apple limit 100 mb per download.. So this big issue for all developer.We need apple to remove the limitation over 100 mb or atleast 1GB.

Bitcode size =/= binary size. Your binary sizes will remain similar.

if so okay, but still i do confuse with the limitation of 100mb.Sometimes facebook apps can update more then 100 mb and some apps cannot update over 100 mb.
Post reply on HN