Apple’s Worldwide Developer Conference was so jam-packed with interesting news that many developers have missed one of the biggest changes the company unveiled: Bitcode.
Missing the news could be excused, because Apple didn’t really talk about it much at all. The documentation on the developer center doesn’t provide much information and even the sessions themselves didn’t contain all that much information.
The most information we got on Bitcode was during Apple’s ‘platform state of the union’ session at WWDC. Andreas Wendker, VP of OS X platform experience, said that Bitcode “allows the App Store to re-optimize apps for each kind of device before they’re delivered to the user.”
This means that apps can automatically “take advantage of new processor capabilities we might be adding in the future, without you re-submitting to the store.”
What does that actually mean in practice? Based on what we know, the new process means that app developers will need to make no changes to their app if Apple suddenly changed processor architecture.
From day one, apps will work on the new processor type regardless of if developers knew it was coming or not, because the App Store will recompile them automatically.
So uh, what is Bitcode?
That’s a big question. First, you need to know what a Low Level Virtual Machine (LLVM) is. LLVM is a library that’s used to compile code down intointermediate or machine code. LLVM is used to build many compilers and languages you’re probably familiar with.
There are two parts to LLVM. First, you have a “front end” language that you use to build your app, like Objective-C, Swift, Python or Ruby and a “back end” which compiles that app down to machine code.
An “intermediate” language like Bitcode is an abstract encoding of an app that can be used to re-compile it in different ways, given a set of instructions.
Bitcode uses the LLVM to take your app’s code, converts it into Bitcode and knows how to turn that into an executable app, based on the instruction set it’s given.
To simplify, this architecture means Apple can simply add support for new CPUs to the “back end” on the App Store, which will show Bitcode how to compile down to new architecture.
You can read detailed descriptions about LLVM here if you’re interested in the technical bits.
Apple isn’t scared of architecture changes
History has shown Apple isn’t shy about switching processor architecture. It’s one of the only companies to survive such a large shift — both Commodore and Atari struggled after a similar change — yet Apple haspulled it off twice in Mac history.
The biggest change was in 2005, when Apple successfully moved from the PowerPC processor to Intel’s by supporting developers with a transition kit and providing advance notice about the new hardware.
The most recent shift in processor architecture by the company happened was just two years ago. Apple announced it was switching to a 64-bit chipsetin the iPhone 5s in 2013 which required app developers to make changes to code and re-compile their apps.
With Bitcode, developers probably won’t need to do much for future changes, even drastic ones.
If Apple suddenly switched processor architecture in say, a rumored larger iPad, developers utilizing Bitcode allow them to make their apps available for the new device upon release, even with no prior knowledge of its existence.
This new technology will have a huge impact, because it gives developers a leg-up when new devices are suddenly announced.
Caleb Davenport, an iOS engineer, told me that his initial reaction was mixed because it has both “good and bad sides.” He says that “the clear win is that Apple does not have to wait for app developers to submit new binaries in order to support new devices.”
“The thing that scares me is that my app could potentially be compiled in configurations that I cannot test which may lead to bugs that I am unable to reproduce.”
He says that when the first 64-bit devices came out in 2013, he waited to enable 64-bit slices in his app until he had hardware to test on — with Bitcode automatically compiling apps, it could be a lead time of weeks before developers are able to test their apps that are actively being used by others in the real world.
Another developer, Sjoerd Janssen, told me that he’s “really excited” about the change, because it impacts the amount of work he has to do to support new devices.
He believes that if Apple suddenly switched to an Intel chip in the next iPhone, for example, it would require no work on his end to have his apps running on day one.
iMore’s Debug podcast also discussed the feature, saying “in theory I love it” but it’s “very, very freaky” and that they wouldn’t do it if they couldn’t test it in some way, because the opportunity for things to go wrong will increase.
I talked to a number of other developers who echoed the same sentiment — the technology sounds amazing, but they’re hesitant to trust Apple to get it right.