4 ms·
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
by colejohnson66 5y ago
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?
- lanza 5y agoThis 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.
- inkyoto 5y agoArchitecture 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.
- saagarjha 5y agoBitcode does not do this, unfortunately.
- plorkyeran 5y agoThere 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.