Apple opens iPhone to developers

In a news conference Thursday (otherwise known as Feburary 35th), Apple unveiled the long-awaited iPhone native Software Development Kit (SDK). It can be used by any developers to create native applications for the iPhone and iPod Touch. Up to now, developers have been limited to writing Web apps that ran inside the Safari browser (though various "jailbreak" hacks allowed unofficial programming). But now you can write programs using the same APIs that Apple's built-in programs use.

The Apple developer's site was hammered all day yesterday but I finally managed to log in and get access to the SDK software and documentation. Here's an early look, including my thoughts on how the iPhone SDK compares to Google's Android SDK.

The architecture

As expected, the iPhone SDK is largely based on Objective-C, a language that achieved some notoriety when Steve Jobs decided to use it in his NeXT computer in 1988. Objective-C, not coincidentally, is also the main programming language used for Mac OSX. Code is compiled down to native ARM instructions. Compare this to Android, which has a virtual machine that runs portable instructions. The iPhone approach is faster, especially if you're doing a lot of processing in user code (as opposed to system or graphics libraries). However Android's is more flexible because it can support processors other than ARM (like Intel's new Atom CPU) without requiring developers to recompile.

The iPhone's operating system is similar to that found in Mac OSX. The kernel is a variant of the same Mach kernel that is found in the Mac. On top of that are layers of services that are used to implement applications. The Core OS and Core Services layers provide fundamental interfaces such as file access, Bonjour services, a SQLite database, network sockets, etc.. These interfaces are mostly C-based.

The Media layer supports 2D drawing (Quartz and Core Animation), 3D drawing (OpenGL ES), audio (Core Audio and OpenAL), and video (H.264/AVC). Most of these are C-based as well, except for Core Animation which is Objective-C.

The starting point for any new project is the Cocoa Touch layer, which mostly uses Objective-C. This layer includes the Foundation framework (object-oriented support for collections, files, and network), the UIKit framework (windows, views, and controls), and other frameworks for contacts, photos, accelerometers, and other hardware features.

Application life cycle

Each application on the iPhone has the whole machine to itself, aside from the kernel and a few low-level services. When the user navigates to another application, for example they press the Home key or select a web link, your application quits. In other words, any action that would have caused your application to suspend or go to the background in Mac OSX causes your application to quit in iPhone OS. It's up to you to save state regularly as they are made, or when you get the quit notification. As the documentation says, "Under no circumstances should you let the user navigate to a new page of content without saving the data on the previous page."

Compare this with Android, which has a much more sophisticated life cycle. iPhone apps have two states: running and quit (not running). The process lifetime is the same as the application lifetime, which is the same as the screen/UI lifetime. Android apps are more nuanced, as all these lifetimes are decoupled. Android also has a concept of an application "stack" and a "back key", that makes native programs behave more like web pages. The iPhone model will be easier to develop for, but Android can potentially be more efficient and intuitive.

Tools

Apple's SDK really shines when it comes to tools. iPhone development is done on a Mac (sorry, Windows and Linux users) using the award winning Xcode development environment. Xcode is an IDE that provides tools to create and manage iPhone projects, build code into executables, and run and debug code either in an iPhone simulator or a real device.

Xcode contains a number of advanced features. One of them is the Instruments environment. This lets you analyze the performance of your applications while running in the simulator or on a real device. It shows a graphical timeline of your program's execution, with data about memory usage, disk activity, network activity, and graphics performance (frames per second). All the information can be displayed side by side, letting you correlate the overall behavior of your application. Android has a much more limited version of this called Traceview.

The Interface Builder (unfortunately not included in the early beta), lets you assemble your application's user interface visually with drag-n-drop. Once your interface looks the way you want it, you save the contents into a nib file, which is a custom resource file. Nib files are similar to Layout files in Android, except that Android uses human-readable XML, and doesn't come with a GUI builder.

Conclusions

Mac developers will be right at home on the iPhone. The language is the same, the IDE is the same, and most of the API is the same. Initially I expect most iPhone developers to come from the existing Mac OSX developer community. But it will be interesting to see if it flows the other way too. Will people new to both learn on the iPhone and then port their wares to the Mac?

In contrast, Android programming is most like Java desktop programming. There are two big differences though that make it unlike anything else: Android's unique application life cycle, and its custom graphics library. While Apple reused Mac Cocoa and Quartz for the iPhone, Google did not reuse Swing, AWT, SWT, lcdgui, or any existing framework for the Android UI.

Both iPhone and Android support location based services, high resolution vector graphics, integrated Web and network functionality, a built-in SQLite database, OpenGL ES, accelerometers, a camera, and a touch screen. iPhone has Multi-touch, which is missing so far from Android, but Android has support for various form factors and other input methods like keyboards and trackballs.

Because of its long Mac OSX history and availability of real devices, the iPhone SDK is much more mature than Android's. It's also far larger and more comprehensive. But Android has the advantage of being designed for mobile from scratch. Android's system requirements are lower than the iPhone's, and devices will be available from multiple sources, so Android phones should be cheaper. On the other hand, because Apple controls both the hardware and software there are many fewer variations that a developer has to worry about.

If this sounds familiar, it should. PCs have flourished in terms of market share over their often prettier and technologically advanced Mac bretheren because of price and openness. The only non-open thing about the PC was the operating system, controlled by Microsoft. Android phones, because they are based on Linux and open source, won't have that bottleneck. Is there anyone who can challenge Apple's industrial design team to make "sexy" Android phones?