ARM, x86, or Apple? That question may make a lot more sense in a few months.

In amongst all the many things that Apple rolled out at its latest Worldwide Developers’ Conference (WWDC) in San Francisco was an almost-offhand mention of something called Bitcode. The company didn’t provide a lot of detail and, in fact, seemed to curtail some of its planned discussions just days before the event, but, from outward appearances, Bitcode lays the groundwork for a future filled with CPU-neutral Apple devices.

In other words, Apple may be getting ready to swap out ARM for x86, or vice versa.

Here’s what we know. Bitcode is a software-distribution format – a way to encode applications in a way that’s not entirely CPU-specific. That is, it’s an intermediate form of software, not quite binary but certainly not source code. It’s a bit like the intermediate object code that compilers spit out before all the pieces are linked together into an executable, but more generic than that. Specifically, Bitcode is neither ARM- nor x86-specific. A single Bitcode app could theoretically run on either processor.

So is this just another virtual machine? Like a different take on Java, but without the hype and the disappointment? Not really. While Java and other JVMs do store their apps in an intermediate format (“bytecode” in the Java vernacular), those apps then run on an imaginary processor architecture that’s simulated by the virtual machine. So Java apps never really ever get converted to “real” binary programs. They’re interpreted by the JVM, usually on the fly at runtime, sort of like BASIC and other interpreted languages.

Apple’s Bitcode retains the intermediate, CPU-neutral storage format, but only until you download the app from Apple’s App Store. At that point, the program gets converted to native binaries for your device. The iDevice to which the app is downloaded still runs native binary code. There’s no on-the-fly translation and no virtual machine. Thus, apps should run at native speed, not the obscenely retarded pace of interpreted Java bytecode. There’s also no JVM emulation to worry about. Bitcode – in theory, at least – is compiled for a real machine, such as an iPad, an iPhone, or a Mac. So Bitcode abstracts away only the distribution format, not the entire machine.

Bitcode isn’t quite the same as binary translation, where programs are converted from one CPU’s instruction set to another’s. That’s a whole different can of worms, and it is very rarely successful. Although – it must be said, Apple is one of the few companies to successfully pull this off – twice – when it switched from Motorola 68K processors to PowerPC, and again when switching from PowerPC to x86. Digital Equipment Corporation (DEC; RIP) and IBM have both deployed workable binary-translation schemes, too. But the number of oh-so-close failures far outnumbers the few successes. Binary translation always seems like such a good idea at the beginning, but all the evidence indicates that it’s fiendishly difficult in practice.

So… if it’s not a virtual machine and it’s not binary translation, what is Bitcode and why would Apple spend the time to create it?

For starters, it would allow the company to play fast and loose with its CPU architectures. Today, all iDevices run the ARM processor and all Macs use x86 chips. Relatively few apps are intended for both platforms, but, when they are, they have to be compiled separately – once for the x86 architecture running MacOS, and again for iOS running on ARM. Bitcode could make that distinction moot. Compile your app once, upload it to Apple’s servers, and let the App Store make the last-minute adjustments to CPU and/or operating system. Suddenly any app can run on any Apple system, regardless of the hardware or software inside. (It’s far from a slam-dunk, since you’d still want to make sure you app actually worked on both platforms, but Bitcode is the enabling technology.)

That allows Apple to change its hardware without disrupting the third-party software base. And – let’s face it – it’s the third-party apps and accessories that make Apple devices attractive. Apple needs to leverage that advantage while also giving itself the leeway to create new hardware. If every Mac has to use an x86 chip and every iDevice has to use an ARM chip, the company is doomed to maintain a two-headed product line forever. How much simpler things would be if Macs could run ARM chips and iDevices could use x86 chips – or if either product family could use custom Apple processors.

What’s that? A third CPU family? Why not – Bitcode lays the groundwork for exactly that.

Apple is one of the few ARM licensees to hold the valuable “architectural license” to the ARM architecture. That expensive contract allows Apple to design its own ARM processors from scratch, not just plunk down the premade Cortex A-99 designs handed over from Cambridge. And Apple employs quite a few accomplished CPU designers. And the company didn’t take out that rare architectural license by accident. And the development of Bitcode is not a coincidence. Apple is clearly embarking on a path of CPU and/or OS independence.

Of course, Bitcode could also serve less ambitious goals. It would facilitate the switch from 32-bit ARM chips to 64-bit chips, for example. Again, you’d compile and sell one app, but the App Store would tweak it at download-time for the appropriate target hardware. Bitcode could also abstract away coprocessors and other hardware accelerators. Just as with floating-point coprocessors in the 1990s, an app could be compiled assuming that a certain hardware resource was always present, but the App Store could replace hardware-dependent functions with their software equivalents.

Finally, Bitcode allows Apple to strip out functions that aren’t supported by the target device. For example, a single app compiled for iPad, iPod, and iPhone will necessarily include code that two out of three of those devices won’t support. Rather than download useless code (which takes up space on the user’s device), why not strip out the bits that won’t be used? Just as OS calls and shared libraries allow apps to avoid unnecessary duplication, Bitcode could streamline apps of redundant functions.

Bitcode also allows Apple to make fairly drastic changes to its devices, while still allowing apps (some of them, anyway) to function. The Apple Watch, for instance, is so new and untried that both developers and users (and Apple itself, one suspects) are trying to figure out what it’s good for. That creates some hesitation in the market – never a good thing. By offering a sort of bridge between Watch apps, iPad apps, and other apps, Apple makes coding for the Watch (and whatever comes next) a bit less scary and risky. If the next-generation Watch has radically different hardware and software resources, Bitcode can help last year’s apps get over the hump.

More cynically, Bitcode may also allow Apple to insert its own software into third-party apps. Certain OS calls could be replaced with functional equivalents that include tracking data, ad banners, malware, anti-malware, or anything else you care to imagine. Not likely, but possible.

In the end, Bitcode enables all sorts of hardware and software changes, both large and small, trivial and massive. It’s safe to assume that the first instances of Bitcode in the wild will be minor and unimpressive, and totally invisible to the end user. That’s Apple’s way: it’s all about the user experience, and developers will just have to keep up. Bitcode makes keeping up with Apple a bit easier, while also giving the Cupertino company some added flexibility in its hardware designs, processor choices, operating system APIs, and software distribution. Regardless of the initial implementations, Apple is playing a long game.