iPhone SDK Restrictions and Ways Around Them March 7th, 2008
So the iPhone SDK was released yesterday to much excitement. I’m downloading the SDK right now and have a couple of apps in mind. Michael Arrington on TechCrunch collects some of the limitations on third-party apps, stating that “for now, whole classes of applications are useless, or are significantly less useful than they otherwise would be.”
The major restriction that seems to be getting attention is:
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)
There are only two types of interactions that this limits that I can think of:
- The iPhone needs to do some processing in the background, for example, triangulating coordinates to see where you are and storing that information for later.
- The iPhone needs to check the internet in the background for periodically updating information, possibly notifying the user. Examples include an IM client notifying the iPhone owner of an incoming message.
While annoying, I think some common applications can still be implemented but what will have to happen is the paradigm will have to change slightly. In the case of an IM client, rather than having a constant signal represent “being online”, someone will have to create an iPhone-Online mode where messages sent to the user are queued up on a server somewhere until the iPhone user opens the application and pulls down the most recent messages. This could be done as a layer that sits between the iPhone and AIM or the IM clients themselves could implement this functionality.
In the case of a lot of applications, the actual processing can take place on the server or only while the application is open. When the user opens the application, processing can take place on the iPhone and the state can be saved in a local sqlite database or on a remote server. When the application is reopened, any additional processing done server-side can be downloaded.
For example, for a time logging application, the user can open the iPhone application and “punch the timecard” so to speak. The application can store the punch time on the phone and the user can then turn the phone off. Whenever the user is connected to the internet and the application is opened, the time log can be synced with a server.
This limitation isn’t a deal-breaker, but it will force developers to rethink the concept of “always on” that we’ve gotten used to with normal applications and web applications alike. The solution will end up being something similar to Google Gears.
