Channels ▼


The iPhone Isn't Easy

With more than 20 years of software development under his belt, Ray Floyd was ready to tackle the next great platform, Apple's iPhone. He'd developed for the Macintosh, although not recently. He was familiar with Objective-C, and he had developed software for other mobile platforms. With a software development kit in hand and up to 75 million potential customers, Floyd couldn't wait to roll out his first iPhone app.

Two months later, he was still waiting, and his enthusiasm had largely changed to exasperation. Why? Because writing native applications for the iPhone platform can an intimidating process.

For one thing, as Floyd quickly discovered, there is a huge amount of information to digest before you can start coding. The iPhone/iPod Touch/iPad is a new platform in its own right. These are sophisticated general-purpose, handheld computers. And as a platform, it has its own operating systems, and a host of APIs (some new, some recycled) for programming. Not surprisingly, the documentation on operating systems and APIs spans hundreds of pages.

Even knowing the Mac isn't a free pass. The iPhone operating system is a variant of Mac OS X, but slimmed down to function on a mobile device. As such, a lot of familiar OS X APIs, such as those that manage a keyboard and mouse, are absent. This means that even experienced Mac developers, which Floyd didn't consider himself to be, may not have the features and facilities they're used to having.

The APIs are based on Cocoa, an object-oriented application framework used to write Mac OS X apps. Like the operating system, the Cocoa frameworks have been stripped to the bare essentials for the iPhone OS, and lightweight touch interface APIs added. This minimalist version of Cocoa, termed "Cocoa Touch," provides another hurdle.

To use the APIs, you need to learn Objective-C. Objective-C is an object-oriented superset of C, and while it has many valuable features, its idiosyncratic syntax means it'll take a lot more than a cursory study to make sense of code. you won't make makes a cursory study of an example program's source code unfathomable. The language's syntax is quite different from C++, and until you have a grasp the syntax, example code will appear almost unreadable.

Like Floyd, I was initially lulled into thinking iPhone development was probably simple for experienced developers. How else could you explain the many thousands of iPhone apps available on Apple's App Store? In fact, many of these apps — and games written in C and C++, in particular — have been ported to the iPhone, where an Objective-C based wrapper interfaces to the Cocoa Touch frameworks, while the game engine remains written in C and C++. In other words, since the Apple Objective-C compiler accepts C and C++ code, you don't have to start entirely from scratch.

But as I began researching iPhone apps, I grimly realized even my background in writing INITs and FKEYs for the classic Mac OS and J2ME programming for various mobile phones was of little use. The iPhone platform, its OS and APIs, and the peculiarities of Objective-C were radically different. I decided to break the task up to reduce the steepness of the learning curve, hoping to find a magic bullet along the way that would streamline development.

First, what should my first app do? I wanted a specific project so I could focus on a subset of APIs, and not become overwhelmed by the big picture. I settled on porting the SpaceActivity app I had written for the Android platform some time ago (see The Android Mobile Phone Platform).

The app displayed a spaceship you steered with handset buttons. That iPhone APIs would be utterly different from Android's was a given. I'd have to learn how to draw the ship on the iPhone's screen, then figure out how to implement controls for it. I hoped that SpaceActivity's "core code" — the physics routine that calculated the ship's velocity in response to rocket thrusts, plotted its position, and kept the image on-screen — could be reused. This code was debugged and tested and had the virtue of using a minimum of API calls. It also had ready-to-use images of the spaceship with a transparent background, so I didn't have to design any new graphics. Finally, it would also be an interesting test of porting Android code. The complete source code for SpaceActivity is available here.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

