Sysadmin Field Notes

October 8, 2007

That the primary iPhone development mechanism will remain web based is something I've been saying for a while now. I feel very strongly that future software updates will include incremental improvements to the capabilities of WebKit as an SDK. It makes tons and tons of sense, and fits with the facts that we already have. First let's look at the reasons why Apple wouldn't want to open up the platform.

Engineering flexibility. The iPhone is a pretty damn amazing piece of hardware, with a lot of stuff crammed in there. They can do what they want to the internals (such as switch to intel), with very little notice or warning, something they can't do with a thousand 3rd parties to bring along with them. Apple gets to set the pace for iPhone hardware innovation, because they are the only developers impacted by those changes.

Security. The iPhone is clearly not designed with a native sandbox in mind. Everything runs as root, and the hardware doesn't do a ton of policing. While Apple's stance on 3rd party apps is neutral, their opinion on unsupported programs that hack the firmware in ways they never could have anticipated: they are against it.

Since everything runs as root, it seems very hard to have 3rd party apps while ensuring that the firmware stays unmolested, at least as currently designed. Bricking phones, altered or not, is bad press and a pain for Apple to deal with, so they don't want people messing in there. There's also the issue of a revenue stream from ATT, although I think that's not the end of the world. It seems more likely that unlock paranoia comes from a contract with ATT that demands Apple do what they can to prevent it (ala iTunes and DRM provisions with the labels).

Those are the two big reasons I can think of why Apple would not want to open the phone. Really it can be summed up in saying that there's no way that Apple is going to freely offer native development to everyone; there has to be some sort of limited, sandboxed environment if there is to be free and open development. Otherwise the risks of broken phones, bad user experiences, and threats to their partnership agreement are too great. So what sort of sandbox could they have used?

Java? Memory, space, and CPU constraints seem too high. Maybe the iPhone has an on board chip that helps this, but that doesn't alleviate all the software engineering required to produce the software that would integrate with the chip, and then more importantly, all the compatibility code to try and map the iPhone's user paradigm to Java apps. It would be a big effort, and the resulting apps would likely not be compatible with other Java phones. That would probably cause licensing trouble. I don't think we'll Java on the iPhone any time soon.

Custom? Could Apple build their own safe sandbox to play in? Not easily. We'd definitely be waiting for launch if this was the case. Most importantly, why build for scratch what you already have....

Which brings me around to the idea of a WebKit/Safari/Web 2.0/Javascript sandbox. It can run user code, it can display content, it can access the internet, and it can play rich media. Sounds like they are 75% of the way there already. Think Apple's not serious about Ajax as a development environment? Notice their website loses progressively more flash everyday. Check out the .Mac web gallery, that's a lot of javascript, and almost no flash.

I don't think it's just lip service when Apple says they want to advance the state of pure web/javascript/quicktime to something close to that provided by flash or a full-blown environment. I think this dovetails nicely with a broader response to things like Adobe Integrated Runtime and Silverlight. If the web goes that way, Apple loses a lot of control, and I don't see an answer from them in the works, aside from just keeping web pages web pages. If they can use the iPhone to expand the spread of that idea, I think they consider that a win.

Now, clearly they are missing some pieces. Local storage, javascript API's for more interesting phone features, etc.. But it's alot easier to expose them via javascript API's than it is write a sandbox on your own. If could write my own javascript apps, easily sync them, have some local file storage, and have them work without internet access, I think that is enough of an SDK to do some really cool stuff with.

As for native apps, I don't think they'll never happen. I just think they will be very locked down, akin to the iPod model where only a select few development companies are allowed into the party, mostly for things like games where you need the full hardware of the device (I think with it's sensors, graphics and sound capability , and interface that it could get some of the most interesting games we've seen in a while).

If the missing pieces to create a total development story are filled in, and some developers are granted full access, I think you'll see 75%-80% of the benefit of a native, supported SDK, with only a small fraction of the risk exposure that would come with it. That certainly makes sense as the way to start for Apple. If it doesn't work out as they have planned, they can always take it on later and add an SDK.

(Not that I wouldn't love a native SDK, just think the reality is that we won't be seeing one for a long time, if ever).