4 ms·

Bitcode[1] would’ve been a good way to handle that, if Apple had ever supported it for Mac apps in addition to their other platforms. 1. https://thenextweb.com

• therockhead 6y ago
  I don’t see how that helps apps not in the App Store, as bitcode need to changed to a platform specific type .... unless this was done on the fly on the host platform.
  • htfu 6y ago
    Apart from a return of the dreaded Win-style endless installer progress bar surely doing it on the host, once, wouldn't be a problem. The "issue" would be squaring the result with notarization and bundle integrity, but that solves itself since it means Apple is already sitting on the (in this case bitcode) app whether it's in store or not. But they'd probably use it as an incentive to drive stuff further towards the app store.
• gsnedders 6y ago
  The bitcode is basically just LLVM IR, is it not? And that encodes plenty of platform-specific behaviours. Though with both being little-endian and both LP64 maybe there's less of an issue there? https://lists.llvm.org/pipermail/llvm-dev/2011-October/043724.html https://lists.llvm.org/pipermail/llvm-dev/2011-October/04372... is still my go-to pointer for the portability of LLVM IR (and bitcode); I don't know how Apple have dealt with the instability between LLVM releases of bitcode, but there's certainly plenty of potentially shortcomings if you want to compile for a different architecture.