LLVM IR is unstable, way too big in scope, and not as machine-independent as people think. There have been several efforts to use it as a target-independent high-level bytecode, and they either are very platform-specific single-vendor affairs (Apple) or were retired in favour of a simpler new language that doesn't have its problems (SPIR became SPIR-V, PNaCl became WebAssembly).
> it doesn't have to be, as proven by watchOS bitcode, or PNaCL.
Both of those have fixed 32-bit pointer sizes and are little-endian. When you compile for watchOS bitcode or PNaCL you just target a single virtual machine & "system" ABI. LLVM IR or any related techniques won't ever allow you to produce a 32 / 64 bit or ARM / x86 app that is able to leverage the whole feature set of the platform from the same bitcode.
that is what they said in the press release but in practice they migrated from "classical" 32bit ARM to ILP-32 (akin to the x32 ABI on linux) so the size of pointers, etc etc does not change from 32-bit. You get more registers & stuff like that which is nice, but that is not moving to 64 bit, just having nicer 32 bit execution on 64 bit CPUs. If you want proper aarch64 support on WatchOS you have to recompile.
"not designed for that use case" != "isn't used for that use case in practice"
Apple has tight control over the bitcode version and the target platforms supported by Xcode. That's not the same thing as accepting arbitrary LLVM bitcode files.