The One Last Thread Holding Apple and Google Together

Four years have passed since Google kingpin Eric Schmidt resigned from the Apple board of directors, signaling the start of what you might call a cold war between the two tech giants.

Or perhaps cold is the wrong word.

Six months after Schmidt left Apple's board, Steve Jobs laid into Google during an Apple town hall meeting, crying foul over Android's challenge to the iPhone and recasting the search giant's "Don't Be Evil" motto as "bullshit." Throughout 2010 and into 2011, the two companies publicly sparred over whose smartphone technology was the most "open" and whose would ultimately make life easier for humankind. Then, in 2012, Apple summarily removed Google Maps and YouTube from the iPhone, determined to reduce its dependance on the company that so quickly usurped its command of the mobile market.

Schmidt now says there's detente between the two, but even if that's true, it didn't come soon enough to avoid a very real divorce of technologies. Until recently, the two companies shared one of the world's most important open source software projects -- WebKit, the basis for Apple's Safari browser and Google's Chrome -- but then, in April, that marriage ended too. Once so close, Apple and Google are now as far apart as anyone in the high-stakes tech game.

And yet, there's one thing they still have in common, one last piece of technological brilliance they freely share with each another.

Chances are, you've never heard of it. But nowadays, it's an integral part every new Apple iPhone -- and every new Android phone. It's not an app or a web service or some sort of hardware contraption. It's more important than that. It's a tool that's changing the way we build and run computer software -- any computer software.

This tool is known as LLVM, short for low level virtual machine. But don't let that throw you. The acronym isn't even an accurate description of what the thing does. It's just a name. The thing to realize is that LLVM underpins so much of the work at both Apple and Google, helping create not only smartphone software, but operating systems and browsers and web services.

"At first, it was this crazy experiment," says Chandler Carruth, one of the Google software engineers charged with building the software development tools used by every engineer at Google. But about a year into that experiment, LLVM was there to stay. "The teams that were on it started to be able to change and evolve and develop at a much more rapid pace."

Created by a team of researchers at the University of Illinois at Urbana-Champaign, LLVM is a way of building software compilers -- those contraptions that receive raw code from the world's programmers and convert it into real, live software applications. But it's more than that. It's also a better way of executing software applications on PCs and smartphones and tablets and other hardware. It lets you run programs on machines and microprocessors they weren't explicitly written for.

Today, Apple uses LLVM to build its desktop and notebook operating system, Mac OS X, as well as its iOS operating system, used by smartphones and tablets. The tool is at the heart of the Apple Xcode software that outside developers use to build applications for all these machines. Likewise, it helps build and run applications for Google Android phones, but inside Google, it also helps create the software that underpins the company's online empire, the software that runs services like Google Search, Gmail, and Google Docs.

In June, LLVM received the prestigious ACM Software Award, following in the footsteps of the operating system that gave rise to modern computing, the protocols that drive the internet, and the browser that took the web mainstream. But it's only just getting started. The hope is that LLVM will usher in a new era of software development where applications can freely move from machine to machine and even from processor to processor.

With a fledgling technology it calls Portable Native Client, Google already is moving down this path on desktops and notebooks, and at the University of Illinois at Urbana-Champaign, one of LLVM's creators, computer science professor Vikram Adve, is leading a team that aims to take the idea even further on smartphones and tablets.

"There should be an industry standard for how code is shipped and executed, so that it would just work on different combinations of hardware," Adve says. "LLVM is already being used by both the major players -- Apple and Google -- so it’s the natural foundation to build on."

Write Once, Run Anywhere. Please

The software nirvana that Vikram Adve describes is hardly a new idea. In the late 1990s, this was the goal of Java, the open source programming platform created at Sun Microsystems. For years, the Java mantra was "write once, run anywhere."

Sun's creation never quite reached that promised land, but we did see the rise of a completely separate programming language called JavaScript -- no, there's no relation to Java -- and this became a standard means of building applications that run inside our web browsers. When you build an application with JavaScript, it can run on any machine equipped with a modern browser, and for many, this is the future of software, both on the desktop and on mobile devices.

The rub is that JavaScript is a relatively simple language. It can't do everything other languages can do, including Java and those venerable creations, C and C++. What we need is a way of running any application, written in any language, on any machine, without a whole lot of compromise -- and that's where LLVM is headed, at least in the eyes of some.

LLVM was born in late 2000, when Chris Lattner, a graduate student working under Vikram Adve at the University of Illinois, flew for home for Christmas. At one point, he and Adve had discussed the idea of building a new kind of Java that would solve many of the platform's inherent problems, and over his holiday break, Lattner turned the idea into a prototype. This was the seed of LLVM, and it was remarkably similar to what the tool would later become.

One of the strengths of Java is what's called "just-in-time" compilation. If you're a developer and you write a Java program, you don't compile it into a finished application on your own machine before shipping it off to the rest of the world. You compile it into something called "bytecode" and ship that off to its ultimate destination. Sitting atop something called a virtual machine, this bytecode is then compiled as it executes. In other words, your program compiles on the hardware that runs it, as it runs.

This is a bit like having your clothes stitched together as you put them on. A Java program gets tailored to the particular hardware where it's running -- at least to a certain extent.

What Chris Lattner and Vikram Adve wanted to do was take this idea significantly further. Java lets you move applications from hardware device to hardware device, but you can't tailor a program to the hardware the way you can with machine code -- the language spoken by the machine itself. Lattner and Adve wanted something that behaved like Java -- but also like machine code.

The prototype was called LLVM, which stood for "low-level virtual machine." It would be "low-level" like machine code -- running very close to the hardware -- but it would also allow for portable applications, much like the Java virtual machine. But the acronym was quickly eclipsed, as LLVM took on a much greater role, expanding beyond that original idea.

You Can Build ... Whatever You Want

By the middle of the decade, Lattner and Adve and other engineers had turned LLVM into what you can think of as a developer toolkit for building developer toolkits. It was a collection of software "libraries" -- software building blocks -- that anyone could use to build their very own custom compiler. "It's a modular compiler infrastructure," says Michael Larabel, a developer who has worked with LLVM for years. "You can have all these different front-ends."

It wasn't limited to Java. You could build a compiler that handled practically any language, and you could arrange for compilation at practically any point in the lifecycle of a program, including Java-like just-in-time compilation. "The key technical innovation was the ability to compile virtually any language to a bytecode form that could be optimized at any point you choose," Adve says.

What's more, the project was shared with the world at large under what's called a permissive open source license. This means that anyone could change these libraries and incorporate them into their own software -- without returning those changes and that software to the open source community.

In short, LLVM let you do whatever you wanted in building a compiler -- and that's why Apple hired Chris Lattner in 2005.

With LLVM, Apple had the technical means to build a compiler that suited all of its needs, and it could merge this compiler with the rest of Xcode -- truly merge it -- without open sourcing Xcode and sharing its proprietary software with the rest of the world.

Lattner declined to be interviewed for this story, saying that Apple frowns on employees talking to the press without approval. But it's no secret that LLVM is now at the heart of Apple's development philosophy, largely replacing the old GCC compiler, which isn't as flexible or as powerful as LLVM -- and lacks a permissive license.

Thanks to Lattner's online resume and other sources, we know that LLVM is "deeply integrated" with Xcode, and that it was used to build the latest versions of Mac OS X and iOS. What's more, it's used to compile graphics code, in real-time, on iPhones and iPads, perhaps hinting at where the company will take it in the future.

The Biggest Supercomputer of Them All

But Apple isn't the only one. LLVM remains an open source project -- headed by Lattner. Sony now uses LLVM to compile code for its PlayStation gaming console. Cray taps the tool in building software for its supercomputers. And Google uses it to fashion software for the biggest supercomputer of them all: the Googlenet, that worldwide network of machines that runs all the company's web services.

Using LLVM, Google has built all sorts tools that seek to streamline development of the company's internal software. This includes small stuff, like, say, a tool that automatically checks for coding errors and another that automatically formats your code so it's easier to read with the human eye. But it also includes some rather big stuff.

Google is unusual in that all software code that underpins its many applications and services is available to every developer at the company. What this means is that anyone can reuse anyone else's code inside their own application or service. That's powerful thing, but not long after moving to this model, Google had problem.

"Imagine you’ve built a library, a pretty low-level library, some core piece of Google’s infrastructure. You’re got thousands and thousands of servers being built using it," says Google engineer Chandler Carruth. "Now, what if when you want to change that library? How do you do that? How do you improve it? Everyone is depending on you. Everyone is impacted. They’ve all written code that pins down exactly how your library works. How do you change it?"

For a while, it was an nightmare. But then, using LLVM and the sweeping infrastructure that runs the Google Search engine, Carruth and his team built a system that could, yes, automate the process. This system indexes all Google code, in much the same way Google indexes the web, and then, when an engineer rewrites a library, the system instantly searches the index, locates any software that uses the library, and makes the necessary adjustments. A change made in one place becomes a change made everywhere.

The setup, Carruth says, has turned Google into an operation where code is truly universal. "We had kind of this pendulum swing. People got real excited about the unified codebase, being about to share all of our libraries, but then it swung the other way and people were afraid, because the most important libraries got to the point where we couldn’t change them anymore, they were too shared," he explains. "But now the pendulum has swung back again."

Apple and Google Together Again?

Considering the size of Google's operation, this is a wonderfully impressive hack. But like Vikram Adve back at the University of Illinois, the company wants more out of LLVM. It wants to achieve something akin to that "write once, run anywhere" nirvana.

The search giant is also using LLVM to create a tool that can safely run any code inside a browser on practically any machine. Still under development, this tool is known as Portable Native Client, and you can think of it as a kind of uber browser plug-in. In many ways, it echoes the original goal laid down by Lattner and Adve: a programming paradigm somewhere between Java and machine code.

Adve questions whether Portable Native Client will find success -- browsers already have JavaScript -- but believes that LLVM may achieve a similar success on mobile phones. He envisions a world where you can use LLVM not only to create applications that can move from machine to machine, but that can move from across different types of processors on the same machine -- from, say, CPU to graphics processor.

"If you look at the way Android apps work today, they can only use the main processor on each of the Android devices. But Android devices use a bunch of other hardware, like the graphics processor, the digital signal processor, and other more-optimized computing hardware," he says. "One major problem is how you can allow these applications to take advantage of this rich set of hardware that comes with every cellphone."

LLVM, he says, is in just the right position not only to solve this problem, but to solve it in a standard way -- in a way that unites the smartphone, freeing applications from the phones of any one company. After all, LLVM is already use by the world's two biggest smartphone players: Apple and Google.

But then he has a second thought. "Maybe Google and Apple will come up with different methods," he says, "which is actually quite likely, given their history."