Filed under: Developer, Features, Apple, Mobile Minute, iPhone
Mobile Minute: iPhone APIs are like life - they're full of compromises
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.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:
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.