Apple should open OS X and let developers create iPhone applications native to the Mac platform -- instead of driving them down the Safari route.
Industry observers said that Apple would do well to change its stance and let developers have access to the iPhone's OS X operating system. Apple announced at its Worldwide Developers Conference last month that developers would be able to create Web-based applications for the iPhone using the Safari Web browser.
Tony Cripps, service manager for mobile user experience at analyst company Ovum, said that Apple's decision limits the iPhone, as compared to Microsoft and Nokia's approach in opening up their respective Windows Mobile and S60 platforms.
"Nokia's done a good job of trying to support developers of all persuasions -- C++, Java and Web developers -- on the S60 platform, and Apple may find itself needing to offer native development capabilities at some point," Cripps said.
Although the iPhone is a good showcase for Web-enabled mobile "widget" applications, Cripps said, Apple's move to appeal to Web developers rather than native application developers is a double-edged sword.
While there may be "orders of magnitude, more [from] Web developers than native developers, which should result in a buoyant early developer community", the downside to that is the locking-out of third-party developers, Cripps noted.
Raju Vegesna, an evangelist at online business software developer Zoho, noted that some Web applications currently cannot take full advantage of the iPhone.
"For example, I cannot save or download any files from any Web app to iPhone's storage," he said. "There are other limitations, like the unavailability of the iPhone keyboard for [document] editors, which make creating documents impossible through Web apps."
Anne Baker, vice president of marketing at Action Engine, a mobile application platform developer, noted that, if usability is the top priority, then Apple should realise that the limitations of the mobile Web make on-device applications a much better alternative for consumers.
She added: "The wait times and dropped connections found when using browser-based mobile applications make the experience of searching for content simply unacceptable for today's busy consumer. This is especially true for iPhone owners, considering that the device is running over the slower Edge network rather than 3G."
Gauge of success
But whatever the criticisms may be, the success of the iPhone will be measured by how much it impacts Apple's bottom line and not how big a developer community the company has.
"If building a native developer community for the iPhone becomes a strategically important means for Apple to improve its bottom line, then maybe it will change its mind. I just don't think the company believes that there's much value in doing that at the moment," Cripps said.
But at least one mobile operator remains cool about the much-touted iPhone.
Neil Montefiore, chief executive of Singapore mobile operator M1, told reporters on the sidelines of last month's CommunicAsia 2007: "If the iPhone is as successful as Apple wants it to be, it will only account for less than one percent of the total global phone production. It's not going to make a major impact from an operator's point of view."
Asian mobile users can only lay their hands on the iPhone in 2008. And, when that happens, it is unlikely that there will be a tie-up similar to the one between Apple and AT&T in the US.
Montefiore said: "We tend not to do exclusives because we believe customers should have a free choice, and it can't be exclusive because you can't lock phones to networks in Singapore," he said.
Apple declined to comment for this story.
The capabilities offered by BREW (Binary Runtime for Wireless on Verizon phones and J2ME (Java 2 Mobile Edition) are little less restrictive than what Apple is allowing via Safari. The problem is not Apple, but the (AT&T) carrier who disallows them to permit us to write applications. Carriers such as AT&T believe -whether rightly or wrongly- that permitting any joe-blow programmer to write code to run on a phone will compromise the security of their network. While it is certainly true that some enterprising infant could indeed create software to (1) automatically dial 900 phone services in the Cayman Islands or (2) spam SMS or email messages or (3) hack safari and automatically send a user's credit card information, intercepted from a bank or e-tailer back to themselves, there are simple nontechnical measures which can be taken against these and other threats. The problem is, they are just not foolproof. And once such a mess occurs, liability will be placed squarely with the enabling device maker.
Cingular (AT&T) and the other carriers recognize that even if it were possible to completely limit such threats, there is still no sure fire way to verify, on a regular basis, that no such software is operating on a user's handset. It will take a much higher bandwidth network to constantly (or, at least, daily) verify checksums of all software on handsets against a Verisign like registry and even then, malware and spyware are still a problem on the web as it is, so much more so if they ever got onto a phone system.
That's why you won't see AT&T or any other big carriers allowing Apple to allow us to write software for our phones anytime soon. J2ME and BREW are very restrictive environments. You have *NO* access to the actual phones and -unless things've changed dramatically since I checked, very limited access to sending and receiving data in the background without user intervention. Otherwise, somebody could write an application to filter and respond to SMS messages without the handset owner's presence. (If mom asks me anything with the word, "Where", write back this message that I'm busy doing homework and cannot be further disturbed; "if my boyfriend writes, send him this message full of hot sex while I'm busy with my lover.", etc.
The fact that we're not allowed to publish such software is what tells me that the carriers, and not the manufacturers are in control here.