Why Apple Didn’t Release An iPhone SDK
By Daniel Miessler on June 14th, 2007: Tagged as Apple | Gadgets | Geek | Programming | Technology | iPhone

The short answer is that not all developers are created equal, and Apple is all about risk management; with the desktop, for example, they don’t let just anyone run OS X because they want their OS to work well wherever it runs. If you could cram it onto anything and force drivers into it, the experience would deteriorate significantly.
It’s the same with iPhone — imagine I download the latest SuperApp for my iPhone. It does x and y, and it’s really cool, but 4 hours later my service suddenly stops. I call AT&T and they say my account is suspended because I’ve violated my network agreement. Huh?
As it turns out, the app was WikiCache — a cool little deal that perpetually attempted to mirror a copy of Wikipedia on my iPhone. Brilliant!.
So now I can’t make calls, AT&T is hassling me, and all because I just wanted to run this application that Apple indirectly supported by releasing the SDK. That’s the problem. And don’t forget that Apple and AT&T are in a very new and unorthodox business arrangement, i.e. each banking on the fact that the other guy will deliver.
For Apple to release a tool that allows non-programming mouthbreathers to create a legion of demoniacally stupid network applications onto AT&T’s unprotected, non-3G network would be a major faux pas. And here’s how that would roughly break down, given how easy it would be to create apps in such an SDK:
<
p align=”center”>25% [Serious Danger to Network and/or Device Stability] 50% [Halfway Decent] 25% [Professional Quality]
So am I disappointed that there’s no SDK? Sure. It would have been great. But I see where Apple is coming from and probably would have reluctantly made the same decision myself. Placating developers just isn’t worth sabotaging the entire enterprise before it has a chance to get started.:
