iPhone SDK

“Phones will only run apps signed by Apple. It also applies FairPlay to the package.”

Deric Horn, Apple Inc.

The SDK does look impressive. Hopefully CoreData will get added at some point.

Update: I knew it was too good to be true. From the iPhone HIG:

Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits. (p. 16)

So much for showing off AIM at the launch event as an example of what you can do with the SDK. Unless you’re someone like AOL, you’re not going to be writing any useful social clients for the iPhone. Oh, and this makes the Kleiner Perkins iFund look even more of a joke than their Java fund a decade ago.

5 thoughts on “iPhone SDK

  1. Ken Sykora

    The only thing that really bothers me about the SDK is that there’s not an official way to deploy an application to the phone without using the Application Store. What if I want to write an enterprise application to be used by those in my company but I don’t want to make it publicly available through the Application Store?

  2. Adam

    While the lack of background app support is indeed somewhat annoying (and prevents many types of mobile apps from being practical), the recent Stevenote has demonstrated that an AIM-type application doesn’t particularly need to be running in the background.

    The solution is to move all management to the server-side, and use the push notification system to re-launch the app when something of note happens. For example, you run the app to log in and view your contact list. Presumably, the most recent state of the app can be saved. Re-launching the app would only require a quick update from the server to update the most recent known state of your contact list and conversations. Any activity, such as new messages, can be received by the server and pushed out to the iPhone even though the app is not running. The app can then be re-launched, using the previously stored state and updating with the latest info. To the user, the experience should be remarkably similar to a true background app.

    Of course, this is all a huge kludge. A lot of extra work needs to be put in to handle all this state and session management, and now you need to invest significant additional server-side resources for your app.

Comments are closed.