Where are the Widgets?

When Steve Jobs announced that the iPhone would only be supporting 3rd party development in the form of Web applications, opinion was quite divided.

Desktop application developers felt insulted that Apple should try to "fob them off" by claiming that Safari was a good substitute for an SDK. Understandable seeing as Apple themselves had already pointed out that the iPhone's built-in technology allowed them to develop applications that could not be achieved with Web technology alone.

Web developers were more amenable to the idea however. People who design for the Web anyway are well-versed in browser limitations and how best to work around them, and Safari, with its superior CSS3 support provides a single, standards compliant platform to target, making development for the iPhone much easier and more flexible than normal Web-based development because all the cross-platform issues go away.

As someone who develops both Web and desktop apps, I found myself caught between the two camps. I love Apple technology - I think its desktop UI elements and APIs are the best in the world. But as much as I'd enjoy tinkering with the iPhone at the OS level, I have to ask myself if the world really needs yet another proprietary API for developing software?

Web apps, for all their limitations, are relatively open. They are open source by nature (at least on the client side), and they are pretty much platform agnostic once you get away from the niggling browser incompatibilities. So designing a Web app for the iPhone means that potentially you are building an application that can be run anywhere, on any system with minimal tweaking. Not just future iPhones, but any portable or non-portable Internet device should be able to use it.

And in this context, Apple's decision to shun proprietary technology such as Flash or WMP in the iPhone makes perfect sense. The iPhone isn't just the World's best mobile Web browser, it's a harbinger of doom for the use of proprietary technology on the Web. If everyone gets an iPhone (and going on sales it seems pretty likely to be the next iPod in terms of widespread consumer adoption) then companies that deliver Web services are going to have little choice but to make those services available in iPhone-friendly form, and that means ditching dependence on flash, Java and all the other crud.

It's ironic that by creating a closed platform, Apple can strike a blow for open standards - if Apple allowed 3rd party software then Adobe would release a Flash plug-in and that would be that. But there will always be hardware platforms and operating systems too small for Adobe to bother with - without open standards these platforms would miss out. But all it takes is for one big player to insist on using only open standards and those little guys are back in the game.

I'm not saying the iPhone will kill Web plug-ins for good - they will probably always have a place in the desktop market. But if people want to cash in on the iPhone bandwagon then they are going to have to ensure that their Web services scale down to meet its requirements, and that benefits everyone.

And then there's the flip side - the iPhone can do things with CSS and DHTML that no other browser can pull off yet. Unless Microsoft wants people to notice that sites start looking better on a handheld phone than they do on a $2000 PC running Vista then they are going to have to keep working away at IE until they get it right. Firefox put the pressure on, but now Safari and the iPhone have just turned it up another notch.

So if Web technology is the right way to go, why are people so pissed at Apple for not building in an API? Whilst the decision to focus on Web tech for 3rd party iPhone apps was a smart move, Apple could have put a lot more effort in to show that they were serious about it.

Safari is not an operating system, or an API, or a virtual machine or a boot loader - it's not a platform for running applications. It's a Web browser, plain and simple. Safari is good for one thing, and that's browsing and navigating Web sites. Applications are not Web sites.

Applications do not need an address bar. Applications do not need a back, forward or add-to-favourites button. If they do require navigation tools, they need more control over how those tools function - the controls need to be defined by the application itself. And most importantly, a typical application does not necessarily require an Internet connection - a calculator, or a game of Space Invaders should be able to run without having to download resources each and every time.

So whilst HTML and JavaScript can provide a decent platform for implementing many types of application, hampering those applications by requiring a user to locate them online, download them every time they want to use them, and then lose half their screen real estate to an address bar and navigation buttons that may or may not be needed is unhelpful in the least. It spoils the user experience by adding unnecessary clunkiness, and it annoys the developer by making their product appear less polished. Developers may be content to use Web technology to make their apps, but they don't want the user to be constantly reminded that it's not a "real" application.

What the iPhone needs is a way to treat Web apps as distinct entities from Web pages. In effect it needs to be able to:

• Cache Web apps locally, so they needn't be downloaded each time they are used. An update system should allow the user to control when the app is updated to a new version by re-downloading, just as they can with normal applications. Just because the developer thinks the new version is ready for prime time doesn't mean the user is ready to upgrade. Some enterprising users have already found clever solutions using bookmarklets or data urls, but these are just hacks and it shouldn't be neccesary for users to jump through these hoops.
• Let the Web app specify an icon. Some kind of meta content, or even an existing standard like favicons would do, but the user will want to store their apps somewhere on the iPhone and click on a real icon to launch them - not a URL.
• Provide access to basic system resources such as preference files. Using cookies to store user data is dangerous because it mixes non-essential, potentially insecure data that the user may wish to delete along with vital settings and documents that they definitely don't, without any way for them to know which is which. That doesn't mean the preferences can't be sand-boxed to prevent security issues of course.
• Give the Web app full control over the screen contents. A Web app can draw its own navigation if needs be - there's no fundamental reason why a Web app needs an address bar or a back button.

And what have we described? Widgets, of course. yes, Mac OS already has this exact application model built in in the form of Dashboard widgets. Implementing these on the iPhone isn't going to be a big development effort for Apple because the infrastructure has already been written. They've even written a Dashcode SDK for widget development, so with a few small tweaks Apple already has all the development tools to give to their community.

It is a mystery to me then why Apple didn't go this route. You can bet that telling their development community that they were releasing a new version of Dashcode for iPhone application development would have gone down a hell of a lot better than telling them that they weren't getting anything except a new Safari beta (and then having the Gaul to call it a development environment).

I really hope that's where Apple is going. I hope that this was their plan all along and that they simply didn't have time to get Dashcode updated before the iPhone release. If they are instead working on a brand new set of Cocoa APIs and widgets for the iPhone then that will no doubt be a popular choice with the Macintosh developer community, but I think in the long run it would be a mistake and a missed opportunity.

Web apps on the iPhone have so much potential if done right, it would be a great shame if they are remembered only as the halfhearted stopgap Jobs used to distract developers while he got the real APIs in place.