The intro makes it sound like this could be feasible for translating x86 Mac apps into ARM Mac apps.<p>> So, what if the Mac switched to using ARM chips instead of Intel? Well, as you can see, Apple could use Bitcode to translate every Bitcode-enabled app on the Mac App Store, without consulting developers, so it would be ready to go on day one.<p>But:<p>> Apple doesn't enable Bitcode for submissions to the Mac App Store today<p>Right. The flag to enable bitcode isn't even visible in Xcode for Mac apps. There's no such thing as Mac/x86 bitcode yet, in or out of the MAS. And:<p>> ARC appears to use some inline assembly, which means you'll need to disable ARC for a project for arm64-to-x86 translation to succeed right now.<p>So this approach will only work on Objective-C programs, written in a pre-2011 style -- which I'd bet is a vanishingly small fraction of the apps on the MAS today.<p>It's a neat exercise in what is possible for a simplest-possible-app, but it's hard to imagine Apple would actually use this approach. It'd require them to ship a couple big new features in Xcode, and then for everyone on the MAS to recompile their apps using those features. Easier all around to just add a new architecture in Xcode the normal way, and have developers compile fat binaries.
This is rather "embed intermediate representation, extract, run another target's back end, and link". I was hoping this would be explaining how to go from ARM by uplifting executable to LLVM IR and retargeting for Intel. This is notionally already possible with ELF and PE executables using McSema (<a href="https://github.com/trailofbits/mcsema" rel="nofollow">https://github.com/trailofbits/mcsema</a>).<p>If anyone is working on this please email me (address in profile), it's something we slated for a future research project and I'd love to talk.
I would be <i>very</i> surprised (and impressed!) if Apple managed to pull this off. With the bitcode transition on watchOS Apple had full control over the ABI and architecture that they were going to target: this isn't the case for x86. Sure, this works for the very simple case presented here, but I forsee it quickly breaking down for any non-trivial application. At the very least, it will not work correctly on <i>every</i> application.