A touch of Cocoa: Inside the original iPhone SDK

original iPhone needs is Web apps!"/>

When 2016 was over, Apple announced that its app store business generated well over $28 billion in sales that year. While that includes sales of software for its desktop operating system, it does not include the vast quantity of applications that are given away for free (many of which enable some sort of transaction when run). By any measure, the app store is big business, and an app-store-like ecosystem has now been part of any mobile OS for years.

One of the striking things about this is that, if you believe Steve Jobs, none of this was ever supposed to be. When the original iPhone was introduced, Jobs announced its development environment: Web apps.

There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern Web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.

Jobs, of course, was famous for dismissing something as irrelevant right until the moment that Apple was ready to enter that market. The tight deadlines for putting something as complicated as iOS together undoubtedly left some of its SDK in a state of flux, and all of it was poorly documented—things were likely good enough for internal app development, but not the developer community. It was easy to see Jobs' promotion of Web apps as a strategic announcement, meant to put off developer demands while the SDK was cleaned up.

But various interviews that have come out since suggested that Jobs really meant it—in this case, his intense desire for control won out. He (correctly, to a degree) figured that Apple would end up being put in a position where it would have to vet all the third-party applications. At the time, he didn't believe his company was in a good position to do so.

Once Jobs changed his mind, the SDK was released. Quickly, it was easy to see some of the arguments that forced this change on him. The similarities between the iPhone SDK and the MacOS were extensive: both relied on Objective-C and had similar programming models. This meant that any iPhone developer would be well equipped to produce desktop applications and, in many cases, the two could share some of their code. And the lessons learned in making the SDK run on mobile processors and in limited memory could be translated to making the MacOS more efficient. The two environments have cross pollinated regularly since.

It's obviously worked out that way. There's a lot of applications available for the Mac desktop that wouldn't have been made if it weren't for experience gained on the iPhone. And it's hard to imagine Apple's Swift seeing much interest and uptake if it weren't for the iPhone developer community.

So with the iPhone turning 10 this week, we wanted to offer a walk down developer memory lane. Below you'll find our original review of the iPhone SDK that ran on October 1, 2008. While it wasn't meant to happen, in retrospect this review captures a lot of the reasons it did.

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.

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:

Accelerate, AccountSettings, AOSNotification, Apple80211, AppleJPEG, AppSupport, ArtworkCache, BluetoothManager, Bom, Calculate, Calendar, CalendarUI, Camera, Celestial, CoreMedia, CoreSurface, CoreTelephony, CoreVideo, CrashReporterSupport, DataAccess, DataAccessExpress, DataMigration, EAP8021X, GMM, GraphicsServices, IAP, ImageIO, IOMobileFramebuffer, ITSync, iTunesStore, iTunesStoreUI, iWorkImport, JavaScriptCore, ManagedConfiguration, MapKit, MBX2D, MBXConnect, MediaToolbox, Message, MessageUI, MessageUtilities, MobileBluetooth, MobileDeviceLink, MobileInstallation, MobileMusicPlayer, MobileSync, MultitouchSupport, MusicLibrary, OfficeImport, PersistentConnection, PhotoLibrary, Preferences, SpringBoardServices, Symbolication, TelephonyUI, URLify, VideoToolbox, VisualVoicemail, WebCore, WebKit, XMPP, YouTube

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).

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.