Apple’s biggest developer news at WWDC that nobody’s talking about: Bitcode

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 into intermediate 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 has pulled 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 chipset in 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.

The problem is that Apple isn’t giving developers enough information yet.

Bitcode, despite its huge impact, was sparingly mentioned at WWDC and even pulled from some sessions. For those using closed-source libraries like CocoaPods, Bitcode can break them entirely until the developer enables support.

We’ll likely learn more as iOS 9 and watchOS 2 are closer to being released, but it’s strange that Apple didn’t detail Bitcode fully at the event that’s designed to communicate such changes.

A processor independent future?

An anonymous writer on Medium under the name of “Inertial Lemon” believes the changes could signal something larger.

Bitcode is compulsory for Apple Watch apps and but only recommended for use in iOS apps — with it enabled by default “for now” signalling a future requirement.

For the Apple Watch, this means the next hardware iteration could drastically change the CPU and developers essentially wouldn’t know the difference, with the App Store quietly adapting their apps for the new device in the background.

Lemon believes Bitcode could signal a larger architecture change for the Mac. Apple’s Bob Mansfield, who was quietly removed from the executive team but stayed on to work on “special projects,” is one candidate to be working on this.

The company is already producing its own processors for the iPhone, so a switch in the Mac isn’t as crazy as it seems and has been rumored repeatedly in the past.

There’s one sticking point: as far as we know, Bitcode isn’t being supported for OS X apps yet — though we shouldn’t disregard that Wendker, the person who announced the technology at WWDC, works on the OS X team.

Such a change would mean Apple could switch the Mac from Intel to ARM processors and have the majority of third party developer’s apps work on day one, divorcing itself from needing to rely on Intel — a company that is struggling to ship improvements on time — for processors.

It isn’t something that’s going to happen overnight and Bitcode doesn’t necessarily signal such a significant change in the near term.

Eventually Bitcode will free the company up to be far more flexible when it wants to make a drastic change, or at least implement a major new feature in one of its processors. It could mean developers get no warning before the next big shift, allowing Apple to keep it under a shroud of secrecy until the new device is already in stores.

It also should result in far less work for developers the next time such a change comes up. In theory, they don’t need to do anything, though many are suspicious that it won’t be that simple at all.

Bitcode needs to reach a critical mass before it’s possible to “just” switch architectures with few hiccups, but Apple is playing the long game by giving keen eyed developers the chance to get ready for when it inevitably happens in the future.

Read next: Adblock Plus Chrome extension now works for entire companies