Commentary: Apple iPhone—A Browser’s Best Friend or Streaming Engine?
Less than three weeks before the launch of its highly anticipated iPhone, Apple used last week’s Worldwide Developers Conference to release something else that people—well, developers, at least—have been clamoring for: a software development kit (SDK).
Yet, in typical Apple fashion, the SDK didn’t include arcane code that only a programmer could love. Taking a page from the Sun playbook, Apple’s SDK is its cross-platform browser, Safari. The result is a zero-learning-curve SDK that allows standard web developers to craft applications that will run as easily on the iPhone as they will on the Windows and Macintosh platform. Apple, in fact, will argue that the iPhone, running OS X, is using the same platform.
Think through Apple’s dilemma: After the iPhone was announced in January at MacWorld San Francisco, one of the major requests was for third-party applications. Yet Apple had to guarantee that it wouldn’t impact its wireless service partner’s network by allowing numerous untested (from a scalability standpoint) applications out into the wild. So the balance became closing off the new handset from applications versus alienating a traditional wireless carrier that had just become the "new" old AT&T.
Apple seems to have realized that, had they released a native SDK, Windows developers would have been scrambling to learn Cocoa, Objective-C, and Xcode. And to do this, they probably would have had to go buy a Macintosh to do the development, with less than three weeks to implement before the iPhone’s June 29 launch date. While Apple enjoys the halo effect that surrounds the iPod’s ease of use bleeding over on to Mac sales, the company is also hedging as many of its bets against the iPhone—and third-party applications seems to be one of the biggest bets.
Out with the Old, in with the New
The main difference between the "old" Web 1.0 world and the new Web 2.0 world, in terms of programming, is best illustrated with a portal site—a site that aggregates various pieces of information. In a Web 1.0 site, such as DrudgeReport.com, a client browser requested content from the server and then displayed the content; when a user clicked on a link, the client browser requested more content and displayed the next web page. In the example of DrudgeReport, the entire page refreshes every minute, regardless of whether content changes.