Mobile Minute: iPhone APIs are like life - they're full of compromises

Filed under: Developer, Features, Apple, Mobile Minute, iPhone

Mobile Minute: iPhone APIs are like life - they're full of compromises

by Alex Hung Aug 13th 2007

Two weeks ago we saw the first wave of third party applications for the iPhone. But because Apple has yet to open up the device and provides an API (Application Programming Interface) for software developers, making third party applications right now is not for the faint hearted or even regular developers. A couple of weeks ago in MacBreak Weekly, Leo Laporte called for Apple to open up the iPhone immediately and he could not see any reasons preventing that happening. What Mr. Laporte, and most pundits, seems to imply is that providing an API is a straightforward process. Publish the API online and let the developers use it, right? If only it were that simple.

An API is a contract between the provider (Apple) and the consumer, who in this case is the software developers. As with any contract, once it is published, a level of trust is established between the provider and the consumer. This means the provider describes the functionality accessible by outsiders in the API, and that functionality will work as advertised. The consumer has to depend on the provider to keep their word so the consumer can develop applications base on that functionality.

But establishing an API also means restricting internal development freedom for the device. It is no longer simple to rework a particular function to provide better capability or performance without substantial testings to ensure the existing APIs are not broken. There are a few ways to deal with this situation.

One is to continue to support existing APIs while adding new functionality on top, i.e. backward compatibility. This is what Microsoft has been doing with Windows since version 3.0 and is partly why Vista was delayed for so long, and yet provided few groundbreaking features. Another way is to remove (or deprecate, as we call it in software world) old APIs and replace them with new ones that do more. This is how Apple has been handling the problem with OS X. But the problem with this solution is that every major OS X update brings issues for software developers. New features and functionality come with each OS update, but utilizing them means some applications will no longer work in previous OS version. Should the developers support multiple versions of their software, or develop for the latest API/OS and force customers to upgrade their OS in order to get new features?

For the iPhone development team, publishing an API would mean putting a stake in the ground and telling the world what can (and can't) be done with the iPhone. For a mature device/system, this is all fine and every one will be happy. But for a such a new, unique and evolving device such as the iPhone, publishing an API earlier than later will mean restricting development freedom for the device itself.

The other big hurdle with publishing an API is providing the tools to developers so they can actually use it. Providing tools also means testings, documentation, and support for the developers, all of which require time, money and resources to setup and maintain.

My guess is that Apple will open up iPhone development in October by providing an SDK (Software Development Kit) along with the next version of Xcode that comes with Mac OS X 10.5 Leopard. By syncing up with the Leopard release, Apple will give the iPhone development team more time to stabilize the code base and get ready for it being used by outsiders via APIs. And by incorporating iPhone development support into Xcode, there would be no need to provide separate tools and documentation like they did with Dashcode (whatever happened to that, Apple?).

That all said, here is my wish list of killer apps when the iPhone SDK finally arrives:

Delicious Library with ISBN scanning using iPhone camera
iGTD with desktop sync via .mac
Password vault app with desktop sync via .Mac (1Passwd, please?)
Text editor (TextMate for iPhone?)
Twitter

Of course, only time will tell. It has more or less become common knowledge (or at least an expectation) that Apple will open iPhone development to 3rd parties, and all signs point to Leopard's release in October as being the prime time to do it. We'll just have to wait and see if our crystal balls are worth the price we paid.

Tags: .mac, 1passwd, api, dashcode, delicious library, DeliciousLibrary, development, igtd, iPhone, leo laporte, LeoLaporte, leopard, macbreak weekly, MacbreakWeekly, os x, OsX, sdk, textmate, twitter, xcode

Reader Comments (Page 1 of 1)

John Faughnan said 9:22PM on 8-14-2007

Nicely done. Personally, the product I want on the iPhone is FileMaker Mobile. That would help with a lot of the concerns I currently have with the iPhone.

Featured Time Waster

Civiballs is a beautiful, soothing physics puzzle Time Waster

I have an absolute weakness for physics games, and while Civiballs isn't the strongest physics-based game, what it lacks in the physics department it makes up for a few times over in style and fun.

In Civiballs, you are presented with a few colored balls, and your goal is to get those balls into the same-colored urn on the level. The "civi" part of Civiballs is that there are 3 sets of levels to play, each representing a different civilization. While the civilization doesn't affect gameplay, the artwork for each level is beautifully themed to it's appropriate era.

To play the game, you are given only one tool - a sword with which to cut the chains that are holding the balls. The puzzle part of the game is in figuring out what order, and with what timing to cut each chain. Do it right, and all the right balls end up in the right urns, with no stray balls entering an urn (a no-no). Do it wrong, and you get to start over again.

Civiballs is not terribly deep on gameplay; the entire game can be completed in about 15 minutes. But if you enjoy this type of game, it will be a very enjoyable 15 minutes.

View more Time Wasters