The iPhone SDK: The day after

Twenty-four hours after Apple revealed its procedure for getting third-party applications on the iPhone, developers have a few questions about the software development kit, but seem mostly satisfied.

In the immediate aftermath of Thursday's presentation at Apple's headquarters in Cupertino, Calif., reaction was almost universally positive to Apple's SDK plans. Some developers had feared worse outcomes, such as having to submit their source code to Apple, and seemed willing to let Apple take a piece of their revenue and be the exclusive distributor for iPhone applications in exchange for getting a crack at the technology.

Now that everyone has moved a good mile or so away from the famed "reality-distortion field," a few tidbits regarding the SDK are coming to light. Thursday, I noted that the devil would be in the details of the SDK, namely in what types of applications Apple chose to allow on the iPhone. A day later, we're getting a better picture of that.

For example, you're not going to be able to use anything other than Apple's official APIs (application programming interfaces), notes Ken Aspeslagh (via Daring Fireball). This isn't much of a shock, but it means that a lot of techniques learned developing unofficial iPhone apps will probably not work with the official SDK.

Also, Aspelagh notes that a third-party application can't write data to another application, which is known as "sand-boxing." This is a security-influenced rule, presumably. The downer is that "the possibility of cool mashups is basically eliminated," notes Wired's Scott Gilbertson.

The SDK item drawing the most attention Friday, however, is that third-party applications will not be allowed to run in the background. TechCrunch's Mike Arrington wrote, "Instant-messaging applications (we saw a demo of an AIM version at the event today), can't run in the background and collect messages while you are doing something else. Leave the application to take a phone call, and it shows you offline."

Apple's SDK documentation (embedded in the TechCrunch post) points out that the iPhone can only display a single application screen at a time, and urges prospective developers to spend a lot of time designing an application that can handle quick stops and starts. "In other words, users should not feel that leaving your iPhone application and returning to it later is any more difficult than switching among applications on a computer."

There could be a number of reasons behind this stance, perhaps chief among them that the iPhone might not be able to support the processing demands required by multitasking, but plenty of other phones seem to be able to juggle more than one application at a time. I wonder whether future Apple-developed iPhone applications--like, say an iPhone version of iChat--will be subject to the same restrictions.

One interesting passage in the iPhone SDK documentation should give Intel something to think about. "If you have an existing computer application, don't port it to iPhone OS. People use iPhone OS-based devices very differently than they use desktop and laptop computers, and they have very different expectations for the user experience."

Intel has been pitching its upcoming lineup of x86-based Silverthorne and Moorestown processors as ideal for the next generation of mobile devices, because they can run any type of software that you can currently run on a PC. The chipmaker has a point in that if you're already familiar with x86 development process, you might find a Silverthorne chip an easier target than an ARM-based chip. But all those Mac and PC software developers will have to bring a totally different mindset to mobile development anyway. Those developers who have been doing this type of development already could have a substantial edge.