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 soft-
ware 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, undocu-
mented 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 dis-
play’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.
xvi | Foreword