iPhone App Development Raises Interesting Questions

If you are a web-standards or web-accessibility purist then you have been given quite a lot of reasons to put your hackles up with the release of iPhone (yeah, Steve doesn't use an article so I'm not going to either). You see, people are releasing sites that are iPhone-specific and even employing dastardly mechanisms to sniff your browser and only serve their wares to those wealthy enough to shill out $600 for iPhone.

THE NERVE!

People are crying foul, relating this practice to the early days of the web when companies blithely released Internet Explorer-only sites. The web-standards movement has made much progress in the last few years to stymie this practice and the prevailing thinking has been that most people developing for the web are aware that their products should function in all of the major browsers and should do so through the implementation of web standards. iPhone-specific sites are, to them, a disastrous step backwards.

I firmly believe in web standards and evangelize them whenever someone will give me a pulpit to do so; and I am in complete disagreement with these people. Because the development language for iPhone applications is HTML, CSS, and JavaScript and the delivery mechanism for iPhone applications is Safari, people are considering these applications to be websites. As such, they are clamoring for them to be completely cross-browser compatible.

These are not websites, they are applications. This is a key differentiator. Apple has been allowing people to write applications using HTML/CSS/JS for some time now with their widget platform. Has anyone, ever, asked for a widget to be IE6 compatible? No way, because the delivery platform for widgets is not Safari, it is through the OS X dashboard.

If Apple had created a dashboard-like launcher that people could develop for, this conversation would never have taken place because the context would have made more sense to people. The delivery mechanism itself is muddying the waters. "If this application is delivered through the web, it MUST be available in all browsers and you should not prohibit me from using it the way I want to use it."

It's a decent argument, but is one for the purists. In a way, using Safari as the delivery platform is a better solution than a widget-launcher because there is no release/download/upgrade/release/download cycle for the user. Everyone gets the most current version all the time, readily accessible through Safari.

iPhone applications are not websites and should not be considered as such. One note, I am not referring to the practice of serving up separate, static websites to iPhone users (for example, an alternate version of CNN.com). I do disagree with this practice in principle, but am speaking here about application development.