Switched On: iPhone SDK won't chase hackers away

The better part of a trade show keynote and six months of anticipation preceded the iPhone's launch, but a casual post on Apple's Web site signaled its relaunch as a platform supported by third-party native applications. Apple's attempt to protect the security of a wireless network by encouraging Web 2.0-based applications taking advantage of Ajax technologies could not realistically mimic the capabilities provided by native applications, at least without some way to provide offline functionality using developing technologies such as Google Gears. Furthermore, there were a host of utilities that have evolved on other smartphones (such as system-wide search or alternative input methods) that were beyond the scope of such an approach.

So, come February, Apple will return to its PC heritage and extend its party to third parties. Developers get their iPhone. Users get their applications. And normally reticent bloggers emerge from their keyboards and podcasting microphones like woodland creatures after a storm, just a little more likely to share their timid opinions with the world. Unfortunately, the rationale of all iPhone hackers cannot be swept away as easily as a fingertip switches among open Web sites in the iPhone's Safari browser.

First is the still-remaining issue of carrier lock-in. While support for the iPhone in the three largest European economies has reduced some of the incentive for this, there are still scores of countries with compatible GSM carriers that do not offer the iPhone. And indeed, in many countries with GSM networks, there are competitive carriers with which Apple has not struck a deal (such as T-Mobile in the U.S.). Exclusives are nothing new in the U.S. celluar industry and often help bring down the price of devices, but the iPhone raised their profile particularly among a group that historically has had a direct and deep relationship with their hardware provider.

Second is the new code-signing requirement, which is certainly a better compromise than limiting the functionality of the iPhone, but doesn't necessarily guarantee freedom to do what a PC developer would. Here, Apple has little control over the supply of hacks, but may be able to sway demand for them depending on how willing it is to certify applications that could conceivably compete with its or its partners' revenue streams. Examples would include voice over IP programs such as Skype or a native version of the Amazon MP3 store. Indeed, one need not go very far down the most-wanted list of iPhone applications to see this conflict as native instant messaging -- supported on many other smartphone platforms -- could cannibalize SMS revenue, one of the few upsell opportunities that AT&T has at this point.

Apple could have controlled the distribution of iPhone applications by using iTunes as the exclusive distribution point for loading, much as it has for games on the iPod. Code-signing has the opportunity to encourage a much richer ecosystem of applications, but while third-party applications may function beneath your fingers, Apple could still hold developers under its thumb.

http://www.engadget.com/2007/10/22/s...-hackers-away/