5 ms·

Does anyone know why this is changing? I thought Bitcode provided some useful flexibility for Apple and that they'd be moving in the direction of more dynamism

Does anyone know why this is changing? I thought Bitcode provided some useful flexibility for Apple and that they'd be moving in the direction of more dynamism in apps in this way, rather than removing it. Is this already gone for iOS, or is it sticking around longer for iOS?

trollied 4y ago
I guess it was an interim measure as part of the x86_64->arm transition. Now that everything targets arm, there's no need for an intermediate representation.
- 0x0 4y ago
  Bitcode wouldn't help with the x86-arm transition because bitcode is still architecture specific. My guess is that maybe they don't want to maintain multiple old toolchains to provide the on-demand bitcode->native build step on the app store servers?
  - pjmlp 4y ago
    That is the case for standard LLVM bitcode, Apple's own version is more finetuned and probably a reason why they are moving away from it, no longer willing to keep maintaining their fork.
  - trollied 4y ago
    >bitcode is still architecture specific Ah, I didn't know that. Thank you
    - 0x0 4y ago
      Even if bitcode was fully architecture independent, you would immediately hit a wall with various framework constants having different #defined integer values. For example, https://developer.apple.com/documentation/apple-silicon/addressing-architectural-differences-in-your-macos-code https://developer.apple.com/documentation/apple-silicon/addr... talks about how the NSTextAlignment enum has diverging definitions between archs. By the way something similar happens on Linux where kernel syscalls have different numbers between archs, for example. (Although on mac/ios, syscalls aren't guaranteed to be stable even across minor macos versions; the only officially supported interface to the kernel is libc)
      - skissane 4y ago
        > talks about how the NSTextAlignment enum has diverging definitions between archs I wonder why: was there some benefit for Apple in doing this?
        plorkyeran 4y ago
        That specific change is possibly just a mistake. They take advantage of architecture transitions to do cleanup which they couldn't do normally because it's an ABI-breaking change. In that specific case, I'd guess they removed the enum values which were no longer actually supported and (accidentally?) renumbered the rest.
      - DaiPlusPlus 4y ago
        > the only officially supported interface to the kernel is libc aka "no fun allowed"
- pdpi 4y ago
  bitcode predates that transition (which is very much still in play). watchOS and tvOS never had (consumer?) x86 versions, the bitcode thing was a workaround to having to build fat (multi-arch) binaries for more space-constrained devices like the Apple Watch and Apple TV.
- plorkyeran 4y ago
  It was an interm measure for the armv7 -> arm64 transition, where they used it to convert armv7 binaries to a wacky 32-bit version of arm64. It was also used for a few misguided things over the years, like force-enabling Swift Concurrency backdeployment for apps submitted to the app store, which mostly just introduced bugs that only happened on app store/test flight installs for zero benefit.
pdpi 4y ago
AIUI the point of bitcode was that you submit one bitcode app, and Apple then compiles that down to per-model native apps. The last Apple Watch without 64-bit support was the gen 3, and that is no longer supported, so the use case for bitcode is gone. I expect they'll be happy to sunset that whole chunk of infra on their end.
- deleted 4y ago
  [deleted]
- danpalmer 4y ago
  Thanks. I had remembered that Bitcode was architecture specific and couldn't remember if that applied down to the 32/64 transition.
  - yoz-y 4y ago
    Afaik Craig said (probably in The Talkshow) that bitcode is not useful to do a 64bit transition as it is still specific to an architecture. It only allows for micro-optimisations.
- 0x0 4y ago
  Even the newer apple watches aren't fully 64bit, instead they run an architecture called "arm64_32" which uses 32bit pointers (which is probably why bitcode worked for this transition, I don't think 32bit bitcode could be used to produce a 64bit native binary)
  - plorkyeran 4y ago
    Xcode 14 introduces real arm64 for watchOS, and it runs on current watches. arm64_32 appears to have been just a transitionary thing (specifically so that existing apps could be recompiled to it via bitcode).
- blackoil 4y ago
  Does that mean someone with gen 3 watch will not be able to download any new app?
lstamour 4y ago
Seems it’s being deprecated as the relevant platforms are unifying on arm64: https://www.runway.team/blog/wwdc-2022-highlights https://www.runway.team/blog/wwdc-2022-highlights

trollied 4y ago

I guess it was an interim measure as part of the x86_64->arm transition. Now that everything targets arm, there's no need for an intermediate representation.

0x0 4y ago
Bitcode wouldn't help with the x86-arm transition because bitcode is still architecture specific. My guess is that maybe they don't want to maintain multiple old toolchains to provide the on-demand bitcode->native build step on the app store servers?
- pjmlp 4y ago
  That is the case for standard LLVM bitcode, Apple's own version is more finetuned and probably a reason why they are moving away from it, no longer willing to keep maintaining their fork.
- trollied 4y ago
  >bitcode is still architecture specific Ah, I didn't know that. Thank you
  - 0x0 4y ago
    Even if bitcode was fully architecture independent, you would immediately hit a wall with various framework constants having different #defined integer values. For example, https://developer.apple.com/documentation/apple-silicon/addressing-architectural-differences-in-your-macos-code https://developer.apple.com/documentation/apple-silicon/addr... talks about how the NSTextAlignment enum has diverging definitions between archs. By the way something similar happens on Linux where kernel syscalls have different numbers between archs, for example. (Although on mac/ios, syscalls aren't guaranteed to be stable even across minor macos versions; the only officially supported interface to the kernel is libc)
    - skissane 4y ago
      > talks about how the NSTextAlignment enum has diverging definitions between archs I wonder why: was there some benefit for Apple in doing this?
      - plorkyeran 4y ago
        That specific change is possibly just a mistake. They take advantage of architecture transitions to do cleanup which they couldn't do normally because it's an ABI-breaking change. In that specific case, I'd guess they removed the enum values which were no longer actually supported and (accidentally?) renumbered the rest.
    - DaiPlusPlus 4y ago
      > the only officially supported interface to the kernel is libc aka "no fun allowed"
pdpi 4y ago
bitcode predates that transition (which is very much still in play). watchOS and tvOS never had (consumer?) x86 versions, the bitcode thing was a workaround to having to build fat (multi-arch) binaries for more space-constrained devices like the Apple Watch and Apple TV.
plorkyeran 4y ago
It was an interm measure for the armv7 -> arm64 transition, where they used it to convert armv7 binaries to a wacky 32-bit version of arm64. It was also used for a few misguided things over the years, like force-enabling Swift Concurrency backdeployment for apps submitted to the app store, which mostly just introduced bugs that only happened on app store/test flight installs for zero benefit.

pdpi 4y ago

AIUI the point of bitcode was that you submit one bitcode app, and Apple then compiles that down to per-model native apps. The last Apple Watch without 64-bit support was the gen 3, and that is no longer supported, so the use case for bitcode is gone. I expect they'll be happy to sunset that whole chunk of infra on their end.

deleted 4y ago
[deleted]
danpalmer 4y ago
Thanks. I had remembered that Bitcode was architecture specific and couldn't remember if that applied down to the 32/64 transition.
- yoz-y 4y ago
  Afaik Craig said (probably in The Talkshow) that bitcode is not useful to do a 64bit transition as it is still specific to an architecture. It only allows for micro-optimisations.
0x0 4y ago
Even the newer apple watches aren't fully 64bit, instead they run an architecture called "arm64_32" which uses 32bit pointers (which is probably why bitcode worked for this transition, I don't think 32bit bitcode could be used to produce a 64bit native binary)
- plorkyeran 4y ago
  Xcode 14 introduces real arm64 for watchOS, and it runs on current watches. arm64_32 appears to have been just a transitionary thing (specifically so that existing apps could be recompiled to it via bitcode).
blackoil 4y ago
Does that mean someone with gen 3 watch will not be able to download any new app?

lstamour 4y ago

Seems it’s being deprecated as the relevant platforms are unifying on arm64: https://www.runway.team/blog/wwdc-2022-highlights https://www.runway.team/blog/wwdc-2022-highlights