Commentary: Apple iPhone—A Browser’s Best Friend or Streaming Engine?

In contrast, Web 2.0 sites such as iGoogle only update a portion of the page as required. The client browser requests content from the server and displays it, but if an element on the page is clicked, only that element is updated, while the rest of the web page remains unchanged. This persistence of data, and only updating what's necessary versus the whole web page, is what makes Web 2.0 applications so effective.

Apple’s argument, made during the WWDC 2007 Keynote, is that Web 2.0 tools like AJAX also yield third-party development applications that are less bloated than self-contained file tools. Reading between the lines to the likes of Flash and the upcoming Silverlight, Apple is saying they want to reduce load times, and use lean apps as a key bandwidth-saving feature that will help the wireless service providers keep their data traffic within a reasonable level. Safari on a Mac weighs in around 6MB for the whole application minus localization, while the Flash player itself is around 10MB. Apple argues that Flash tries to do in it's own way what is already a part of the browser and—in the case of Internet Explorer, Safari, and iPhone—already part of the OS.

One area where Javascript may be limited is in QuickTime integration, because Apple has to figure out a way to keep web-based movies from playing immediately on the iPhone when the page loads (helpful—or critical, depending on your view—for those who are watching their bandwidth pennies). When Jobs showed movies at MacWorld, he tapped them and they went to full screen and started playing, and could then be rotated for widescreen playback.

Safari is even lightweight compared to other browsers, as Firefox weighs in just shy of 50MB. And one of the additional features of using the browser is that the implementation of new JavaScript and CSS extensions could happen behind the scenes. For instance, the Internet Engineering Task Force put out a set of URL tags for telephony a few years back, so it’s not inconceivable that a standards-based iPhone could take advantage of these tags to allow a web page to dial the phone. While we’ve seen workarounds, such as jajah.com’s plug-in for Internet Explorer or Firefox, the use of a CSS extension means that programming a web page to use the iPhone to dial a number would be a snap.

Finally, on the streaming side, one assumes that all iPod video formats will be supported. The fact that Safari is used as the SDK and base platform means that HTTP streaming should be part of the package from the get-go and H.264—a video format that Apple is a key proponent of—will probably be the preferred streaming format, as noted by the adoption of H.264 for YouTube content on the Apple TV, although it may not be the only format that can be used. Content providers who choose to use H.264 for video and AAC for audio will most likely also have two basic settings to choose from: a setting for videos that will play across WiFi and a setting to play videos across EDGE (AT&T’s data network).

In conclusion, it appears that Apple has heard—and heeded—the request to allow third-party applications on the iPhone. While the "SDK" that Apple has released—Safari on Windows, the Mac, and the iPhone—is a novel approach, it should prove in the long-term a sensible approach to porting applications from the desktop to the handset.