...In this case, the implication is that the death of a British Columbia man who was hit by a falling helicopter could have been averted if he hadnt been wearing his iPod.

I just thought I should point out this could be easily solved. When the iPod is turned on, it could show a splash screen that alternates between different safety tips. "Watch for falling helicopters!" could be one, with a black silhouette helicopter. And, of course, at the bottom of the screen is the ubiquitous "Don't steal music."

(I wish my vector art skills were up to the task of drawing a helicopter right now.)

However, it took a long time to get the search field itself (which uses <input type="search"/>) working nicely on the iPod touch. Of course, it turned out to be my fault: My CSS had an extra } in it just above the entry that limited the field's width. So the width is properly limited to something reasonable now. On the other hand, the search field doesn't seem to get a different appearance from the text field or the search history. I can live with that.

It seems to degrade fairly nicely on other browsers. Of course, it doesn't get the grey "click here to search"-type text, but I don't really feel that's worth adding. Hopefully, this will be adopted by the standard and end up in other browsers, too. In the meantime, I can live with this limitation, too. It certainly makes the code cleaner.

More on the input tag another time...

I'm sure the options are still settable in some deep, dark profile editing page. The point is that I can now log in without having to get past this page.

You might wonder why I cared. I don't have an Apple pre-release seed key right now, but I've had one in the past and likely will again in the future. If my account was accessed when I had a seed key and someone downloaded, say, a Leopard seed and posted it somewhere... well, I might or might not be eventually found liable, but if it was tracked to my account (probably a very big if) I'd probably find myself sued.¹ Yuck.

1. I'm sure these guys were caught by tracking their BitTorrents or something like that.

It took me a while, but I realized after making that post that I needed to reconsider what I was doing for iPhone development¹. See, I have an application in mind for the iPhone. I originally planned to develop it for the web, but I need to reconsider that.

There's a bunch of advantages to sticking with the web SDK:

• Centralized data authority. Users will never need to worry about whether their desktop computer or their iPhone has the latest version of their data.
• No data management for users:They never need to worry about backups, because I can backup everything automatically.
• Fully cross-platform²: All other things being equal, a bigger market is better, right? Sure, I'd want to do some customization for the "desktop version" later, to take advantage of the larger screen, but it wouldn't be a rewrite by any means.
• SDK available today: A chicken in the hand is worth at least a dozen unknown birds squawking in a tree.
• Automatic updates for all! Hooray! This is especially relevant to me, because I can see tweaking some of the algorithms behind the scenes for many years.

For my application, I can see these advantages to a UIKit SDK application:

• Better performance: web page downloads over AT&T are going to take a while regardless of what else I do.
• Richer interface: despite WebKit being pretty darned capable³, I probably wouldn't be able to do some of the more complicated animations or graphical manipulation that I wanted to do.
• Offline use: except some of the things I want to do would likely require a connection anyway⁴.
• More interaction methods: This is the only one that really bothers me. Being able to flick between pages and respond to rotates easily is important for an iPhone application. I hope Apple has something up their sleeve on this front.

How does it all stack up? I think I'll be doing the development using the web. Nothing's really changed, but now I've thought it through and feel comfortable with the choice.

Given that decision, I'm done. If I decided on UIKit, I'd now be wrestling with whether to unlock my iPod touch⁵ and start looking into third party documentation on the SDK to get an early start. I'm not sure this would really be a head start, as there's probably quite a few others who will decide (or have already decided) to take this route.

1. Like Gruber, I'm just going to use iPhone as the generic term for iPhone or iPod touch.
2. In the sense of the software being able to run on all modern web browsers, I mean.
3. See PopCap's Bejeweled, for instance.
4. This raises the question of what exactly the iPhone SDK can and can not do. Will it have full network connectivity?
5. I'm not really breaking my rule here. My device is, specifically, an iPod touch.

What I do have a comment on is the last point of his article: The nomenclature of the iPhone.

I think Apple did users and developers a huge injustice calling the iPhone "iPhone." Apple had a great product name in the iPod. iPod doesn't mean "music player" — in fact, it doesn't really mean anything. What was the point in calling the iPod something so meaningless if the name wasn't going to grow? The iPhone easily could have been the "iPod phone."

We all read about the Linksys incident and now Apple's apparently having difficulty with the iPhone trademark in Canada¹. All for a product name that in the long run is going to confuse consumers.

Anyway, I wouldn't be surprised if Apple called it the iPhone simply because it was the name everyone expected them to use.

1. To be blunt, though, I think Rogers' horrible service and pricing is more likely to be what grounds the iPhone in Canada. Boo, hiss, boo.