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

[qzervaas]

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

[jevinskie]

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.

[LeoNatan25]

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

[sneak]

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

[LeoNatan25]

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.

[pjmlp]

Standard bitcode does not, but there are people at LLVM and Apple working on a portable version of it, if you check LLVM talks.

[caf]

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

[jevinskie]

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.

[LeoNatan25]

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.

[astrange]

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.

[pjmlp]

> Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation.

Kind of.

On IBM i, C compiles to TIMI bytecode just like everything else. For producing actual native code directly from the compiler you need the Metal C compiler, or the POSIX compatibility environment (PASE).

The TenDRA C and C++ compilers also used bytecode (TenDRA Distribution Format).

http://www.tendra.org/tdf-guide

[sneak]

Ahh, good to know.

[eridius]

No, Apple is not intentionally wasting your storage. That's frankly a very offensive accusation to make.

As for alternate language content, honestly that stuff doesn't take up very much space, and stripping it would break the code signature. The only way Apple could strip that is if they perform the equivalent of App Thinning based on a list of languages you specify when downloading the binary from the App Store (and even that wouldn't apply to downloading non-MAS apps).

[yAnonymous]

>That's frankly a very offensive accusation to make

Yeah. It's not like Apple had to settle lawsuits about batteries that seemed to be designed to break after a while. Oh, wait...

[eridius]

Oh wait what? I can't find any evidence of such a lawsuit. The closest I can find is a lawsuit over the fact that batteries are not user-replaceable.