The iPhone and Public APIs

by Charles Miller on October 4, 2007

Wired: Apple's Not 'Bricking' Hacked IPhones for Revenge:

…Erica Sadun, a technical writer and blogger at TUAW.com who contributed to an iPhone unlocking application, said Apple's update wasn't designed to disable hacked devices. Just the opposite: Sadun thinks Apple worked hard not to brick iPhones -- even hacked ones.

"It wasn't intentional at all," she said. "If they wanted to brick hacked iPhones, they could have done a much better job of it."

...The new iPhone software appears to be a ground-up rewrite, unrecognizable under the hood to the older version, which Sadun said was "very unfinished" and, in some places, "a complete hack."

Later in the article, they refer to an Adrian Cockroft post from January (emphasis mine):

…Developer support falls outside the minimum marketable features required for initial launch into the consumer marketplace. By taking full control of the product, Apple can make sure that very high quality standards are in place, and that applications integrate with the iPhone experience. The reality of product development also makes it hard to build a stable developer API until the product is finished, so I fully expect a phased developer program.

Most developers never have to deal with maintaining public APIs. Even in the open source world there are very few projects who give it more thought than providing a list of the things that will break when you try to compile against the new version. (Linus Torvalds, quite famously, didn't want to assure binary compatibility for kernel modules between Linux kernel releases because that would have made life too easy for closed-source device drivers)

Third party apps are for life, not just for Christmas.

Maintaining public APIs is hard, especially in a first-generation product where you're expecting to release frequent, significant updates. Once you commit to a public API and binary compatibility across versions, every single change you make to the system has to take into account the possible effect on third-party applications. A simple change becomes a mess of deprecated APIs, and that mistake you made early in the development cycle becomes a wart your system is stuck with for the forseeable future.

The reason Apple gave for delaying the next version of OS X was that they'd had to divert resources to finishing the iPhone. Third party apps on the iPhone would be a really cool thing, but for now, I'm reasonably content to give Apple time to sort their shit out.

Previously: Yes I Know...

Next: Otter!