A touch of Cocoa: inside the iPhone SDK

Ars takes a look at what Apple provides for iPhone developers, and what that …

Prying into the SDK

Over the last few months, those of us who registered with Apple and downloaded the iPhone SDK have been in on a remarkably well-kept secret. Word leaked as each new update of the SDK was released, and some sparse details about Apple's progress slipped out, but only the roughest of outlines of the software that runs the iPhone and enables its applications made it through the nondisclosure agreement that Cupertino required.

Now, Apple has lifted the NDA, and developers are finally able to talk a bit about what we've learned. This won't be a comprehensive overview, but it should give a feel for the capabilities and limits of the iPhone and its OS, and the challenges developers face in working within those limits.

The termination of the NDA actually ends one of the biggest constraints on iPhone development: the inability of developers to talk among themselves. With no way to share tips, techniques, and documentation, and with the SDK itself somewhat buggy and in flux, developers would run into roadblocks where something wasn't working and it was impossible to tell what was at fault—your code, Apple's code, or simply the documentation. It will be very liberating to not have to resort to informal, off-the-record queries with the developers you happen to know, and this will probably produce a second surge of application releases in the near future.

Apple's insistence on an NDA is even more confusing given that the SDK was given out freely to anyone who took the time to register, and open posting of development issues was permitted on an Apple-hosted discussion board. So it's really hard to understand what Apple achieved with a policy that had a primary effect of hurting the developers the company was ostensibly welcoming to the platform.

The simulator brings an iPhone to your desktop

That rant aside, Apple's SDK reveals far more about the device than any of the company's statements, and it provides some insight into what it took to cram OS X onto a mobile device. It also reveals a bit about how Apple, given what amounts to a redo on Cocoa, has aggressively pushed its software design philosophy onto its developers.

Inside OS-X Mobile

The iPhone simulator that's part of the SDK comes with information about what's inside the OS itself. It doesn't appear to host a full version of the OS, but what it does have can be assumed to be present on the actual device, since developers are expected rely on it; this includes the frameworks in /System/Library. Developers have access to all of these, like CoreGraphics and AddressBook, with one exception: IOKit, which is primarily used to create hardware drivers. It's there, and presumably Apple is using it, but developers don't get to do anything with it.

There's also a very extensive collection of private frameworks. There are a lot of things that can be inferred from what's in there, but it's an exercise I'll leave to the readers, who can examine the entire list:

If there are any command-line executables included in the iPhone (and jailbroken apps suggest there are), the SDK doesn't let on about them. But it does indicate OS-level support for just about anything a Unix application could want, as man pages are included for all the software libraries present, and these go well beyond what might be expected.

The ability to manipulate kernel extensions is gone, but applications can track filesystem changes through kqueue/kevent capabilities. The sysctl functions are present, which do allow a degree of manipulation of the basic operating system functions. For something that's not supposed to support background processes, it was surprising to see functions like exec, fork, and daemon. It's clear that Apple has left the pieces in place for enterprising coders to work around this limit, although any such apps seem unlikely to show up in the App Store. Alternately, the company could flip the switch on this capacity should they introduce a device with greater processor and memory resources.

There's also a fair number of oddballs among the routines, like a man page that reads, "These routines emulate the System V menu library. They were not supported on Version 7 or BSD versions." These menus are normally only encountered within a terminal environment, so Apple's decision to include them suggests that the iPhone provides a far more complete Unix environment than they're currently allowing access to. If you jailbreak the first generation iPhone OS, you can run a very functional terminal on it, and this ability doesn't seem to have gone away.

Tools of the trade

Since the NeXT days, Apple has provided developers with the tools they need for building applications: Xcode (formerly Project Builder) and Interface Builder. Instead of creating something new for the iPhone, the folks in Cupertino have modified these tools to work with the new platform. The modifications include a new set of project templates that handle some common classes of applications. Within Xcode, developers have access to a set of template files for some of the more commonly subclassed objects, including views and controllers (more on those below).

New iPhone-specific application templates are available through Xcode when you start a project

Interface Builder allows a drag-and-drop layout of the user interface, and coders can set the behavior of these UI items and hook them to the classes that manage their activity. In the first few releases, support for the iPhone was almost nonexistent, but it has steadily improved and appears to be nearly complete. Developers who jumped in early were left performing most of the work in code, and they'll have to decide whether it's worth going back and ripping out this code in order to base their application on Interface Builder instead.

With 10.5, Apple introduced Instruments, a suite of performance-monitoring tools based on Sun's DTrace software, that can find things like memory leaks and processor-intensive sections of code. Apple has modified them to also operate on the iPhone simulator and on any hardware that's connected to the development box, be it the phone or an iPod touch. This last feature is pretty important, since the simulator runs some code much faster than the actual hardware.