Today is a good day to code

What Happened at Apple To Make Them Release The iPhone SDK

Posted: December 31st, 1969 | Author: | Filed under: iPhone, Uncategorized | Tags: | No Comments »

What Happened at Apple To Make Them Release The iPhone SDK

Picture of IrvinI have been thinking about this whole iPhone SDK mess for a couple weeks now, especially since I have had some time to step back and look at things logically. Then I came across a blog in ars technica called Small plans: NVIDIA and the future of smartphones. While not being directly about the iPhone and its SDK, it was loosely about how the mobile market is set up, and how they really view these portable devices.

I am certain that when Apple came up with the design, using OS X on the iPhone probably was chosen as a time-to-market feature, meaning that instead of trying to write their own OS, use Symbian, or any other existing OS, they could leverage a modified version of OS X to run, especially since BSD could easily be ported from PPC to ARM.

So when Steve Jobs said at WWDC that the iPhone ran OS X. That was the beginning of this mess. The thing is, I am sure that Apple never considered the iPhone to be a palm-top computer. They thought it was going to be the best iPod ever made. In order to have the “i” it needed easy internet access in a less, or non-crippled way. Obviously the solution was WebKit, since it is basically a number of C libraries that are very platform and framework agnostic. Naturally the best way, in the executives' thinking, to code for an internet Phone would be with AJAX, since it was the hot technology at the time.

In hindsight, it was the wrong choice, they clearly underestimated the desire in the public to have a fully-featured micro-computer with a good size screen, capable CPU, and decent storage options. The fact that it has Wi-Fi, Bluetooth, and EDGE make it an even better computer. I don't think the marketing machine at Apple every considered that the public was thinking along these lines, that Apple was really releasing a palm-top mac. They really thought it would remain contained in their 3 core competencies. Web, iPod, and, now, Phone.

This explains the consternation on Apple's part when everyone started screaming for a native SDK.

Now we understand what happened at Apple, and why developers, and technology early adopters misunderstood each other, now lets look at the problem with the cell phone market.

As referred to in the article, the cell phone market is all about features tied to hardware. While there is a ton of Brew / Java / Symbian applications out there, they aren't thought of as applications to be installed or removed, instead they are thought of as features that can be added or taken away. The difference is well explained by Jon Stokes at ars, but simply, a feature is a discreet bit of functionality encapsulated in a widget of a sort, while an application is a complicated bundle of solutions to solve some sort of problem. According to Apple, as evinced by their iPhone developer guidelines, and the cell market, the mobile phone, smartphone, or really micro-portable is not the appropriate place for applications, it is better suited to features, or widgets.

The logic of limiting mobiles to widgets is debatable, ultimately it ends up coming down to the UI and the interface, which is the other reason no mobile developer really wants to give up complete control of the device to developers.

Imagine a totally open iPhone, if you will, some applications would follow Apple's UI paradigm, while others would completely rewrite their UI. What you would end up with is a device with a bunch of vastly different interface paradigms. Sort of like Linux as compares to Mac OS X. For geek hackers like myself, this is excellent, and what we want. However for most users, if they installed some application and it looked like Gnome, while another application looked like Beryl, and yet another application had the Mac look and feel, it would be just too jarring and different. They would at best remove the applications, that changed the paradigm, and at worst complain to Apple.

So, what I think the SDK will look like is that Apple will not open up the iPhone to the general developer public, but to placate them, they will allow widgets to be developed against the iPhone using JavaScript, XHTML, CSS, and their custom JavaScript mods to access libraries to allow access to local storage, etc… I doubt seriously that Apple will let the public have access to the iPhone at a C / Objective-C / C++ level.

These widgets will probably have to be signed, like the rest of the applications in Leopard, and truthfully, depending on the level of access, through JavaScript, we have to the underlying system, may be OK with me.

The second level, or Pro-SDK will be for companies like EA, which will have to sign some kind of agreement with Apple not to screw with their implementation of the UI. Apple will probably then allow them to have unfettered access to the innards of the iPhone at a C level.

Mostly this should be OK, except a bunch of hard-core C developers will be frustrated with still having to deal with JavaScript, and limited access to the system, and there will probably be another hue-and-cry, I suspect this 5/8ths solution will probably satisfy most, because it deals with the EDGE issue, and gives controlled access to the hardware. Probably, in Apple's mind that is the compromise they are looking for, and that they think the developer community is looking for. Maybe it will be OK.

So, what happened to make them release an SDK. I suspect Guy Kawasaki, or someone that Steve Jobs respects, let him know that his customers wanted to use the iPhone in a way that was different than they wanted them to use it, and that ultimately it can only make Apple stronger. I also think my blog had something to do with it too :-)