[refulgentis]

Apple used to require bitcode (LLVM IR) for App Store submissions.

Rest is interesting, nothing was done on install, it wasn't converted or anything to machine code.

In fact, in practice, it never ended up being used.

Well, that's not particularly relevant: the idea was never to do something on device anyway.

Really excellent post here summarizing that I can vouch for: https://stackoverflow.com/questions/72543728/xcode-14-deprec...

[transpute]

Thanks for the correction and link. Relevant to the comment above about binary blobs:

> The idea to have apps in a CPU neutral form available on the app store is not a bad one; that's why Android chose Java Byte Code (JBC). Yet JBC is a pretty stable representation that is well documented and understood, Bitcode isn't. Also on Android the device itself transforms JBC to CPU code (AOT nowadays).

[kbolino]

The general idea is correct, but a rather significant detail is not.

Android did not choose Java bytecode, it chose Dalvik bytecode [1]. This was done for several reasons, but at a high level, Dalvik bytecode more closely matches how real computers work while Java bytecode targets a more abstract virtual machine. This result is that Dalvik bytecode is easier to transform into machine code, and more optimizations are done in the source code -> bytecode phase rather than the bytecode -> machine code phase, relative to Java bytecode.

[1]: https://source.android.com/docs/core/runtime/dalvik-bytecode

[transpute]

Thanks for the additional detail, https://en.wikipedia.org/wiki/Dalvik_(software)

> Programs for Android are commonly written in Java and compiled to bytecode for the Java Virtual Machine, which is then translated to Dalvik bytecode.. The successor of Dalvik is Android Runtime (ART), which uses the same bytecode and .dex files (but not .odex files), with the succession aiming at performance improvements.