iPhone and Widgets

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”

  • Todd,
    This is a great post, touching on a lot of the intersections I have been thinking about:
    – Apple’s need to control the brand experience (which we want them to do!)

    – Customers’ need to add their own interactive cool stuff to their iPhones and other e-tools

    – Customers’ need to “strut their stuff” by sharing the cool gadgets they’ve created

    – The ability for 3rd party developers to develop well-behaved and secure games and apps for the iPhone.. (This can still be done thru the same kinds of developer agreements Apple has with any 3rd party sw firm).

    – Do we need an API to write to for the iphone?

    – Can we make do with browser development (e.g. gadgets and widgets?)

    – Will an SDK be forthcoming? if not from Apple, from someone else?

    And, yes, I agree with you, I absolutely don’t want random applets calling my friends and family!

  • […] I previously had posted some thoughts on Apple’s announcement that applications for the iPhone can be written using Web 2.0 technologies (except Flash, for now). Patty Seybold contributed to the conversation with some comments and on her blog. After watching the video, I wanted to continue the conversation. […]

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.