As a longtime participant in the iPhone hacking community, I have often been asked just what I think about the iPhone SDK. I'll take a moment to reward those of you who have purchased this book with an answer. In short, Apple's iPhone SDK adds some very nice high-level functionality to clean up an otherwise hideous mess. Deep underneath the SDK's comfy pillows rests a very disorganized and poorly designed set of frameworks, but some of that ugly was also very functional in areas where the SDK is not. The SDK is certainly good enough to write a high-quality, functional application for the AppStore (if it weren't, I wouldn't be writing about it). The interfaces provided by the SDK are written well enough for most good developers to design good software, but most people are unaware of the functionality that isn't available to them. For those who cut their teeth in the open source world, the iPhone SDK is still a point of contention.

If you're unfamiliar with the politics surrounding the SDK, there are two sets of developer interfaces: those provided by the SDK, and those that Apple uses. While there is some overlap between the two, I wrote about many classes and frameworks you've never heard of in my book iPhone Open Application Development (O'Reilly). You've never heard of them because they are not available in the SDK. Many of us in the early iPhone hacking community discovered them by breaking into the iPhone's operating system directly. Throughout many weeks of dumping symbol tables, classes, and experimenting by trial and error, we mapped out the genome for the iPhone's user interface kit as well as many other frameworks, including many that are now private. It is these low-level APIs that developers use when building iPhone software with the open source tool chain, and the same low-level APIs that we found many of Apple's applications taking advantage of to do things the SDK didn't quite allow for.

These low-level APIs are what give open tool chain developers an edge over SDK developers, and in my opinion, offer a better development framework than Apple's SDK. Many of the frameworks on the device have been quietly privatized, making their functionality unavailable to AppStore developers. Not coincidentally, much of this functionality appears to be what is crucial for building applications that Apple might consider to be competitive with their own preloaded software. Of these, the greatest offenses include restricting the Core Surface framework, which would have given SDK developers the ability to render raw pixels directly to a screen layer and incorporate the use of graphics accelerators. Without this framework available, you'll have a difficult time squeezing performance out of applications that require 2D rendering, such as custom movie players, video recorders, or high performance 2D games like my free Nintendo emulator. This is also a key framework needed in order to write applications such as Flash or Java with any degree of performance. Another set of APIs you'll find missing is the ability to interface with iTunes music. This is why the SDK version of Nate True's Tap Tap Revolution no longer picks songs from your iTunes library, and why you'll only find cool music applications like SynchStep (which plays music to the rhythm of your steps) in a third-party repository. Even simple functionality, such as the ability to run in the background or display status bar icons, exists only when using APIs that are restricted from the AppStore. Needless to say, the open source iPhone compiler lets you do many things that the SDK cannot, which some would speculate is designed to ensure Apple will forever have the competitive edge in the iPhone software market.

On the other side of things, the SDK offers something that open source was never much good at accruing: large wads of cash. Developers seem to be able to swallow their distaste for Apple's policies after considering the obscene amount of money there is to be had from an audience as large as that of iTunes. The AppStore financially rewards innovators who are willing to drink the Kool-Aid. The potential for revenue provided by the AppStore gives developers a significant advantage over the open development community, even if your application does turn out slightly crippled.

From a solely technical perspective, the open source compiler can build applications using either the SDK interfaces or the low-level "private" interfaces, depending on which set of headers you care to use. The same is true of Xcode: the private, undocumented interfaces can be easily imported into your project by simply pointing the SDK at the right headers. This gives you four possible combinations for developing applications.

What it really comes down to is this: if you are looking to deploy applications in the AppStore, you must play by Apple's rules. Apple will not accept an application that uses private interfaces or frameworks. Apple has reportedly even rejected flashlight applications that overstepped their bounds and had the nerve to try to adjust the display's brightness on their own. If you're a commercial developer or designing software to deploy on your enterprise, there really is only one viable path for you, and that's to use the sanctioned APIs documented in this book. If, however, you're reading this book as an open source enthusiast, and consider your code to be more of an art form, you may be more interested in writing software as it was intended to be written—without shackles and sandboxes. In this case, I recommend you consider using not only the APIs you'll find in this book, but to further expand your knowledge into the many undocumented APIs and frameworks available. The open source community was the first to build a public compiler and over-the-air, online community software repository for the iPhone, and it welcomes beautiful, full-featured applications.

The iPhone development world is currently suffering from a split personality. Both camps are growing, but polarizing. Many developers have become disillusioned by the number of restrictions placed on the SDK, and argue that it is incompatible with popular open source licenses (such as the GPL), or frequently rant that there would be no need for hacking the iPhone if Apple only opened up their wonderful device.

My desire is for Apple to truly open up the iPhone's operating system, rather than continuing to impose such suspicious and seemingly monopolistic restrictions on the SDK. While the iPhone is by and large the most revolutionary mobile device in history, Apple runs the risk of letting a strong desire to control the market harm both developers and consumers. The mere fact that I can purchase multiple handguns with less hassle than I can an iPhone speaks volumes to Apple's fascination with control. This same obstinate attitude has troubled many developers trying to design for this amazing platform.

It is my opinion that the creativity and innovation of intelligent developers should not be subject to the whims of device manufacturers. Code is a form of expression for many, and to impose censorship on the freedom of expression only seeks to punish innovation when it does not originate from within Apple's campus.

In spite of this, I continue to be awed by the spectacular nature of Apple's products, and I applaud their innovation. Not only is the SDK very well thought out, but Apple's latest version of Objective-C is one of the most elegant and developer-centric languages I've seen to date. Apple is capable of creating beautiful things, and nearly everything about the iPhone is quite beautiful. My only hope is that Apple continues in its success by being the most creative, and not by squelching innovation out elsewhere.