Regarding the iPhone

There’s a lot of things I could write about regarding Apple’s iPhone, but there are really three issues that stand out to me right away: the importance of the user interface, the implications of the iPhone for Apple as a company, and the significance (or lack thereof) about the fact that it runs OS X (some people are making a big deal out of this last one, but for all the wrong reasons).

The iPhone’s User Interface

It’s pretty amazing what Apple has been able to cram into such a tiny package … but what’s really intriguing to me isn’t the form factor so much as the user interface they’ve developed. Steve jobs explained it simply: current mobile phones (and, by implication, PDA’s as well) are limited in function based on their fixed, inflexible keypads.

Just like a calculator, their capabilities and limitations are determined by the way we’re forced to interact with them.

Apple has removed that limitation, tossed out the keypad and replaced it with something that can change on the fly, based on the task you want it to perform at any given moment. It makes for a device that’s very cool and seems to have its own reality distortion field just like its creator. People seem spellbound by it.

Actually, the idea behind this type of user interface isn’t new. The characters on the TV show Star Trek TNG, for example, used computer interfaces that worked a lot like the iPhone interface. Sit down at a workstation and the 24th century computer would present to you the display and virtual keypad you’d need to perform the task at hand. Get up and trade seats with a fellow crew member, and they’ll get the interface they need for their job.

Pretty cool stuff. And now, at least in a very early stage, it has become a reality.

Of course there are going to be downsides to this kind of interface. Jason Fried says that the iPhone is not touchy-feely. He writes:

Rich textures have been replaced with androgynous glass […] with a traditional phone or device with buttons you can feel your way around it. You can find the bumps, the humps, the cut lines, the shapes, the sizes. You can find your way around in the dark. Not with the iPhone.

It’s an interesting point. I’m touch-typing this article right now almost as quickly as I can think it, and I’m doing it all without having to look at the screen or the keyboard. In fact, I just took my eyes off the screen and looked down at my cats while I was typing (they’re pacing because it’s close to their dinner time). I never could have done something like that while using an iPhone.

But is that necessarily a bad thing? Is the flexibility of this new type of interface worth giving up muscle memory for? Only time will tell, but I’ll bet the answer is yes.

The iPhone and Apple as a Company

Steve Jobs opened the keynote by saying he wouldn’t be talking about Macs at all during Macworld. That didn’t seem like a big deal at first, in light of what came next. But upon further reflection, I think that there’s a deeper statement being made here: Apple is placing its “consumer devices” (that is, its non-computer products) much higher on the food chain, at least as far as company focus and product emphasis are concerned.

We can actually think of Apple as a company that creates three things: computer hardware, consumer electronics, and the glue that binds them … the software (more on this later).

I think we’ll also see a more clear division of focus from here on out when it comes to Apple’s trade shows. Two shows, two concepts: WWDC is all about Macs and Mac announcements, and Macworld highlights consumer electronics and their entertainment delivery platform (the iTunes Store, iPod, Apple TV, etc.).

The iPhone and OS X

I was just as surprised as anybody when Steve Jobs revealed that the iPhone is running OS X. It’s a great achievement, but people are making a big deal about it for all the wrong reasons.

The fact that the iPhone runs OS X is important because of the possibilities it opens to both Apple as well as (hopefully, maybe?) third-party developers. With OS X, there exists the real potential to leverage an existing platform in a whole new way. This is something that very rarely happens, and it truly is a-game changer.

It’s also very cool that Apple was able to develop such a compact machine that’s still capable of running OS X so smoothly. This is why people should be curious to find out what CPU the iPhone is using.

But that isn’t why they seem to care.

Unfortunately, rather than focusing on the novelty of OS X on such a small and portable device, it seems like most people are astounded by the fact that OS X is running on a new, third CPU.

This isn’t a big deal for the same reason that the switch to Intel – and the parallel existence of an Intel version of Mac OS X existed since the very beginnings of 10.0 – is also not a big deal from the software development standpoint.

Let me explain …

Why the CPU Doesn’t Matter (much)

From the standpoint of most Mac developers, it doesn’t matter much what CPU the machine they’re developing for (Mac, iPhone, or otherwise) is using. It might matter if their application is doing very low-level work (the kinds of things Parallels does, for example). But most modern day programmers don’t have to program against a specific CPU. They program using the framework, Cocoa for example, provided to them by their operating system’s development environment. This framework knows how to interact with the underlying operating system, OS X for example, which handles all of the dirty work.

The developer programs the framework to draw a window, and a window appears. They don’t need to worry about how the window got there or what to do when a user drags the window’s title bar. The framework and operating system handle this type of thing for them.

Of course developing apps for the iPhone requires a different type of user interface design, attention to a new form factor, etc. but the actual type of code, in most cases, won’t vary.

This framework is why developers who’d been using Apple’s Xcode were, in most cases, able to make Universal versions of their applications available so quickly. Often, it was as easy as checking a box in Xcode and recompiling. The framework and operating system would handle the translation of code, as needed, from one CPU to another. So the apps work on PowerPC chips as well as Intel chips.

And now they might just work on the CPU the iPhone is using as well. All thanks to the Cocoa framework and OS X.

OS X is UNIX

To really understand why OS X on Intel (and now on the iPhone’s CPU) isn’t such a big deal, we need to consider that at the core, OS X is UNIX. It’s based on FreeBSD, a great UNIX system built (primarily) for Intel CPUs and known for rock-solid stability. This is a big part of why Macs crash so rarely these days.

You’ll notice that I mentioned (above) that FreeBSD was developed for Intel. Later, it was “ported” to work with other CPU’s as well, but its primary focus has always been Intel. I believe that this focus played a big role in why Apple selected it as the basis for OS X. I think that Apple had been planning a switch to Intel all along, biding their time. The fact that the Apple had a complete version of OS X on Intel since day one is proof of this. So is the existence of Darwin (Apple’s open source version of the OS X core operating system) for Intel.

In fact, Apple had to port FreeBSD to PowerPC before they could really get started working on OS X. It’s even possible that Mac OS X 10.0 was an Intel operating system before it ran on the existing Mac hardware of the time.

OS X on Lots of CPUs: No Big Deal

UNIX has been running on many, many different CPUs since the beginning. This was one of its biggest selling points for ages: write your software for your UNIX of choice, and it should compile on any machine which can run that version of UNIX. Linux, a UNIX-like operating system, works just the same way. Sure, there are always issues when you’re doing low level work (as mentioned above), or developing graphical tools that are based on a specific graphic card or architecture, but in general, things just work.

In fact, what works on one UNIX often “just works” on another UNIX. Most open source software, like MySQL and Apache for example, will often compile with few or no operating-system specific tweaks … and usually with no hardware specific tweaks whatsoever.

Again, this was one of the main reasons Apple wanted Mac OS X to be FreeBSD-based in the first place. As Steve Jobs explained at WWDC a year ago when he announced the switch to Intel, they’ve always had a version of Mac OS X running on Intel.

What’s an OS, Anyway?

In a recent article, John Gruber writes:

Mac OS X and OS X are not the same thing, although they are most certainly siblings. The days of lazily referring to “Mac OS X” as “OS X” are now over.

To understand this statement, which is only a footnote in his article, I think we need to break down what we really mean when we’re talking about an operating system.

Wikipedia defines an operating system like this (emphasis is mine):

An operating system (OS) is a computer program that manages the hardware and software resources of a computer. At the foundation of all system software, the OS performs basic tasks such as controlling and allocating memory, prioritizing system requests, controlling input and output devices, facilitating networking, and managing files. It also may provide a graphical user interface for higher level functions.

In many circles, the OS is thought of as being limited to only the lower level functions, such as the kernel, device drivers, the things that sit below the parts of the software that we, as users, ever have contact with – and not including the parts we actually touch (so to speak) when we’re sitting in front of a computer.

Today, most people, especially non-programmers, use the term operating system to mean “the software I use to interact with my computer.” They mean both the underlying tasks like writing files to hard drives as well as the visual presentation and interaction layer between user and machine … something traditionally called the graphical user interface.

In UNIX, the kernel and device drivers (the software moving data around behind the scenes) and the GUI (what we interact with when we use the computer) are separate pieces of software. This is one of the reasons why Apple was comfortable releasing Darwin, the open source version of OS X. Darwin is basically OS X without the Mac OS X GUI.

This follows the UNIX style of thinking perfectly. Anybody who has used UNIX systems like Solaris, AIX, FreeBSD, or Linux know well that the operating system (like FreeBSD) is not the GUI (usually the X Windows System).

And it gets even more complicated. In many (even more geeky) circles, the operating system is actually defined as being only the kernel and device drivers, but not the tools that are often bundled along with them.

So to clarify: We should probably think of OS X as the kernel and device drivers, as well as a bunch of other underlying software that makes the computer (be it a Mac, an Apple TV, or an iPhone) run. The rest of the software, the stuff that controls how we interact with the system, varies based on the device’s purpose and function (desktop computer, set-top box, phone, etc.).

From Here to There

Still here? Good! The last bit then, is to consider how Apple would actually take OS X from one CPU to another … so that Cocoa developers (Apple’s or otherwise) can start writing code.

It’s no small feat, that’s for sure, but it doesn’t mean staring over from scratch.

Let me present an overview of the steps an operating system and framework developer, like Apple, might take to port a UNIX-based system from one platform to another.

1. Hack the kernel to work on the new CPU
2. Hack (or create) the device drivers for the new CPU
3. Compile a version of the development tools
4. Use the development tools to recompile the rest of the OS
5. Ship it

Of course it’s not quite that simple, but that’s the gist of it. And as I’ve mentioned, this exact thing has been going on for years in the UNIX world.

So in the end, we don’t have to care what CPU the iPhone is running after all.

That is, unless we’re curious about how hot it’ll get in our hand when Core Image running full steam …

More articles in the Archive →