Todd Biske: Outside the Box

The Mac developer community has been abuzz with Steve Jobs’ announcements regarding development for the iPhone. In short, he told the development community to leverage the web. He specifically mentioned AJAX, which points to a model like Apple’s Dashboard Widgets: Dynamic HTML + CSS + AJAX. If you’ve ever tried Widget programming, or Vista Gadget programming for that manner, while the bulk is Dynamic HTML + CSS + AJAX, there are a small set of native APIs exposed that provide some necessary capabilities such as saving preferences. The question that wasn’t answered in the Keynote was whether such an API will exist for the iPhone. Clearly, there are concerns about security that must be investigated. Steve mentioned having the ability to place a phone call. It could be very dangerous if you go to a website and through JavaScript it starts sending SMS messages or making phone calls. A no-API solution would be more client-driven, where the iPhone would recognize that a phone number is displayed in a widget and give the user the option to call. Off the top of my head, I can’t think of anything where I’d want a program doing those things for me.

Given this, is the lack of a distinct API a big deal or not? My opinion is that it isn’t. Why? The biggest reason is that the iPhone is not a general purpose computer. It’s three things according to Steve: a phone, an iPod, and an Internet Communicator. On the phone side, it already provides everything needed for making calls, so no big deal there. On the iPod side, same thing. On the Internet Communicator side is where the debate comes into play. Or does it? Being an Internet Communicator these days is typically concerned with being a Web Communicator, and since the iPhone has a real web browser, not WAP, doesn’t it provide everything we need (except Flash support)? I’ve previously posted that I think we’ll be seeing more and more lightweight widgets with rich UIs available via web technologies. It would seem that these types of solutions are very well suited for a mobile device like the iPhone. I’m not one of those people who needs Microsoft Word or Excel on a small handheld device. There are developers who may be annoyed that they won’t have APIs for direct access to the Multi-touch interface, but I would argue that’s Apple’s problem, not theirs. How many applications are being written that need a new keyboard or mouse? There’s only one category that I can think of, which should be the only area upset with the announcement: games.

For as long as I can remember, there have been continued evolutions in game controllers. The original joystick of the Atari 2600 is not still in use on today’s Playstation or Wii. So, it’s very conceivable that game developers could find some cool way to leverage the multi-touch interface. Secondly, the size and form factor of the iPhone is well-suited for gaming. Apple even knows this, as they opened up the iPod for games some time ago. Let’s remember, however, that Apple does not allow anyone to produce games for the iPod. I would guess that this is necessary to ensure the security of the iPod is maintained. While an iPod can’t go calling someone, would you be happy if a game wiped out your contacts, songs, or videos? It’s entirely possible that it could also be used to transfer a worm/virus via iTunes synchronization. So, to maintain the “Apple experience” it has to be a tightly controlled environment. With the connectivity of the iPhone, this is even more important. While the same challenges face other mobile phone providers, none of them rely on experience to the extent that Apple does. It’s part of their corporate image, and it’s not something they’re going to bend on. Given that Apple has a partner ecosystem for iPod games, I’m sure the same thing will happen for iPhone games. Given that, I think Apple’s done exactly the right thing. The only thing they need to provide is the iPhone Dashboard. I don’t want a Safari bookmark for every iPhone Web 2.0 app, I want the phone to manage it just as Apple’s Dashboard does with its widgets today. Who knows… perhaps that’s the mysterious 12th icon. I hope to find out in two weeks!

Update: I forgot to discuss the whole Safari on Windows thing. The discussion from Dan Farber at ZDNet made me think of it. My opinion is that it must be a developer play. If the route to the iPhone is through the creation of Dashboard-like widgets, and the underlying CSS engine is Safari, developers have to have a tool for testing it. Starting with the Mac, the first tool for this was Safari. It was only later that Apple came out with Dashcode. I’m guessing that it was probably a far easier path to take Safari to Windows than it would have been to take Dashcode.

Update #2: There’s another discussion on this from Patty Seybold at her Outside Innovation blog.

2 Responses to “iPhone and Widgets”