Yesterday's announcement from Apple that they would be allowing third parties to develop for the iPhone after all was good news for developers. But it's only a first step. A small step.
Apple has decided to let developers write apps within the built-in Safari browser. I had expected that this might be the direction Apple was going to go, given that Apple initially wasn't thinking of providing any third-party developer support. It was their quickest way to get something out there.
The choice, however, is rather limiting--both in terms of capabilities and sleekness of integration. My concern is that third party iPhone apps are going to look sub par.
As a developer, ideally, you want a development platform that gives you the capability to create an app that looks like it could have shipped with the iPhone out of the box. You want it to be quickly accessible via an icon. You want it to have the iPhone look and feel. You want it to load quickly. You want it to be responsive. You want it to integrate seamlessly with other services on the device. You want it to leverage as much of the small display as possible. You want it to be easy to deploy. You want it to work well. You want it to be easy to use. You may also need performance and always-available access--even when there's no network. Some of these are doable within a browser. Some are not.
Actually, there are still many unknowns. We're yet to see what's going to be supported within the browser. In the keynote, Steve Jobs kept emphasizing that this was the same Safari engine as in Windows and OS X--which made me wonder if he was meaning that the engine will be the same, but in terms of plugin support and the like there will be differences. For instance, I'm questioning whether there will be Flash support. Or Silverlight support. Or even Java support. It would be great if any of these made the cut. We'll have to see.
Steve Jobs also made the assertion that this development strategy is "innovative", but I don't buy it. It's not. It's an incremental step. He may also assert that there's no "SDK," but I don't buy that either. There will be. Yeah, there's no SDK or API in the traditional C++ sense, but there will be documentation and calling conventions for accessing the phone services, there will be standards and conventions for "deploying" apps onto the iPhone (such as maybe automatically adding bookmarks or something to the browser, or maybe even an icon), there will be standards and conventions for storing cookies--which may impact offline mode, if such a mode is supported. Point is, there, will be things developers will need to know in order to write a good Safari app for the iPhone. Saying there's no "SDK" doesn't help. There will be a "Software Development Kit." Maybe no C++ functions for now. But there will be a "kit" for developers. There will be steps to follow, suggested guidelines, and on and on.

Anyway, Matt Croydon has the best first-thoughts on how a Safari iPhone app might work. There's still lots of missing details. I'm guessing that these missing links are being outlined at WWDC and we'll be reading about them in days to come.


Incremental Blogger