Seeking Alpha
Profile| Send Message|
( followers)  

Obviously Steve Jobs and team didn’t go through all the details today when they announced the availability of the iPhone SDK. It was more of a high level pass. But details are what third party developers need to think about before jumping into the iPhone with both feet.

Last year when Facebook announced Facebook Platform, developers had to decide to ignore it, build for it along with a standard web site, or build exclusively for Facebook. Venture capitalist Josh Kopelman layed out an argument that some developers should immediately build on Facebook v. developing for MySpace, despite the fact that it was (and is) proprietary.

Facebook Platform has its own venture funds to support new startups. As of today, so does the iPhone.

The decision to build an iPhone application is very similar. Some developers will add one to their existing products. Others will go iPhone only.

Should we expect Kopelman to write a new post, urging developers to build an iPhone application as soon as possible? Maybe. But a number of bloggers and developers did some digging today into the fine print, and there are some troubling details.

Some of the limitations were announced at the event today. VOIP services, for example, are basically out of luck. They can access the Internet only via wifi, not the cell networks. That’s a signal of a larger issue, though - that Apple isn’t going to allow applications to threaten any of their revenue streams from the iPhone. Likewise, SIM unlocking is forbidden. But what about other, less black and white applications? John Gruber asks if Amazon would be able to launch an iPhone application that allowed users to buy songs from the Amazon MP3 store. That’s a great question, currently without an answer.

Other limitations can be found in the developer agreement. Developers can only use the published APIs and only in the way Apple says they can use them. Ok, that helps with stability. Applications also cannot write data anywhere except in their designated area, meaning developers can’t modify data from any other applications.

But the single biggest issue we’ve found is in the 100 page iPhone Human Interface Guidelines. It’s a public document, but you must be a registered iPhone developer to see it. We’ve embedded it below via docstoc.

Users can only run one application at a time, and if they leave an application it quits. That doesn’t seem like a big deal, but it means that you can’t switch away from an application and have it continue to do things. That’s a big issue with the current support for websites on the iPhone - as soon as you leave the browser the connection is broken. With the iPhone, the hope was that an installed application could continue to run in the background and, most usefully, gather and send information from and to the web.

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)

This will be a serious problem for some developers. For example, say a developer wanted to take location information from the iPhone (created via the iPhones cellular triangulation feature) and dump it into FireEagle to keep track of where you’ve been. Well, that won’t work unless you keep the application open at all times, and don’t use the iPhone for anything other than that. Another example: 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. The bottom line is - any application that wants to periodically interact with the web to do stuff, won’t be able to on a continual basis.

Perhaps future versions of the iPhone, with additional CPU and memory resources, won’t have this limitation. But for now, whole classes of applications are useless, or are significantly less useful than they otherwise would be.


iPhones Human Interface Guidelines - Get more free documents

Source: iPhone SDK and Restrictions: Some of the Details Aren’t Great