Hacker News Reader

Comment by colejohnson66 | Hacker News Reader

Isn’t that the idea with “bit code”? Basically, Apple keeps the LLVM IR (of sorts) and optimizes it on their end (and removes unneeded image assets (such as @2x on an @3x device)). So the build your device downloads is highly optimized specifically for your device model.

Or do you mean something else?

View on HN

There isn't much evidence that Apple has ever used bitcode for anything other than making existing watchOS apps run on the new arm64_32 architecture. It's required for app thinning (where they only install the architecture needed for the actual device rather than all of them), but if that's not just an arbitrary requirement to get people to enable bitcode it's unclear what it's being used for.

I don't know if bitcode could be used to recompile your app with a higher deployment target and have useful effects, but it isn't being done in practice.

This would only support optimizing for different architectures. Your code is already compiled from Swift -> IR and thus these features would not be part of the IR.

Architecture specific («post-compile» time pass) and chained fixups (link time pass) optimisations are orthogonal, and both can take place. Since a) Bitcode IR is, essentially, an object file; b) the destination platform version is known at the post-processing (i.e. download) time, it is possible to also optimise the executable binary format to make us of whatever enhacements are available, too.

Bitcode does not do this, unfortunately.

Reply on news.ycombinator.com