Daniel Eran Dilger
Random header image... Refresh for more!

How Open will the iPhone Get?

iPhone Open or Closed
Daniel Eran Dilger
There is obvious interest in iPhone development, and users of the device have good reason to demand a vibrant software ecosystem growing up around it. There are a lot of applications Apple doesn’t have the time or inclination to deliver, but which would greatly increase the value of the phone and subsequently expand sales. Apple needs third party help.


At the same time, I have taken it upon myself to act as the tiny minority voice in explaining why I think Apple isn’t simply being foolish and shortsighted in the way that it is rolling out its iPhone software platform.

Back in January, I explained why Apple might face resistance from third party developers, and why it might be best suited following a managed platform strategy in the model of video games, where Apple would developing its own apps and work with developers to co-publish, without setting up a wide open development platform like the Mac or Windows.

[Inside the iPhone: Third Party Software]

I also defended against the market-speak droids that came out in a vengeance against Apple’s so called “closed platform” by highlighting the absurdity of ABI’s claim that not running third party software made the iPhone “not a smartphone,” pointing out that the overwhelming majority of today’s third party mobile software either:

  • solves problems in Windows Mobile that shouldn’t exist.
  • fills voids left by Windows Mobile that Microsoft should have covered.
  • exists without reason as frivolous garbage-ware.
  • is overpriced trash.
  • or will work on the iPhone already.

[More Absurd iPhone Myths: Third Party Software Panic]

With Journalists Like These, Who Needs to Report a Factual Story?
In May, I went to Apple’s shareholder meeting (just barely; they use metal detectors for security and I have a metal plate in my arm from a motorcycle accident), and used the opportunity to ask Steve Jobs about iPhone development In front of all those rich stockholder and media types.

“While Apple’s closed platform policy may make sense for consumers,” I asked, “does Apple recognize the needs of large, institutional buyers who are excited about the prospect of applying low cost, handheld computers with their own custom development?”

Jobs went on record to answer that Apple was working to balance the needs of software security and deployment with demands for custom development on the iPhone. The “real” press, including Ellen Lee in the San Francisco Chronicle and Troy Wolverton of the San Jose Mercury News, failed to ask any interesting questions or even note the interesting answers.

Instead, Lee published a diatribe about how Jobs was “feisty” and “fired back” at anyone who dare ask any questions. Lee also described an unhappy shareholder contingent based entirely upon–as reader David Barnes noted–conversations with two union leaders with clear political goals. She may as well have invented that story from her desk and saved herself a trip.

Wolverton turned in a tepid report in May, but then tried to retell Lee’s story in August, in an incendiary article that spun the meeting’s vote–three months later–as a hotbed of shareholder outrage and discontent. Wolverton still hasn’t got back to me as promised to explain away his documented record of half-truths and negative spin on all things Apple. What a coward!

[Answers from Steve Jobs at Apple’s Shareholder Meeting]
[RoughlyDrafted Forums – Answers from Steve Jobs at Apple’s Shareholder Meeting]
[Troy Wolverton Documents Faux Apple Shareholder Outrage]

Mobile Disruption: Apple's iPhone and Third Party Software
An iPhone SDK at WWDC?
Prior to WWDC in June, I explained why I didn’t think Apple would release a software development kit for it [at WWDC], and that it would likely orient apps around the web as Dashboard-like widgets instead. I outlined reasons why, in addition to pointing out that being “closed” did not necessarily mean being a completely locked down black box, and that Apple’s viewpoint was subject to change as the surrounding circumstances did.

[Mobile Disruption: Apple’s iPhone and Third Party Software]
[An iPhone SDK? Predictions for WWDC 2007!]

An Open iPhone Software Plan.
Days before the iPhone’s release, I pointed out that Apple had already gone on record about its plans for the iPhone back in an April earnings report:

CFO Peter Oppenheimer stated, “We believe the iPhone is a revolutionary device that is years ahead of the competition. At Macworld, we demonstrated a number of the iPhone’s breakthrough features, including its pioneering multi-touch display and user interface, visual voicemail, desktop class e-mail and web browsing, and of course, the best iPod ever.

”We plan to build on this incredible foundation by continuing to develop new software features as well as entirely new applications and incorporate them into the iPhone. Since iPhone customers will likely be our best advocates for the product, we want to get them many of these new features and applications at no additional charge as they become available.“

Apple's Secret iPhone Application Business Model
[Apple’s Secret iPhone Application Business Model]

Since then, I’ve pointed out the same thing: the iPhone isn’t likely to become a Mac-like open platform anytime soon, but its really not accurate to call it a closed platform either. Two recent articles presented more details on why, integrating in the historical events of the Office Wars.

[Six Reasons Why Apple May Never Open the iPhone]
[How Closed Is the iPhone?]

Reasons for Wanting an Open iPhone SDK.
Reader Ken Tozier responded with three main reasons he thinks Apple should open up the iPhone to developers. He wrote:

  • ”A supported SDK would eliminate the negative ‘hacker’ stigma for third party applications. Since Apple never partners with anyone but large corporations, under the closed model, the little guy will never get a chance to legitimately write applications for the iPhone. Without this legitimacy, only a miniscule proportion of iPhone users will ever take the risk on hacked applications. The average user will just be too scared off by the label ‘hacked.’

  • “A supported SDK would bring a large percentage of developers, who want to create iPhone/iPod-Touch apps under Apple’s control. It’s just easier and faster to use Apple’s Cocoa classes than plod through open source SVN trees trying to stitch together disparate code fragments into your own ‘big idea.’

  • ”Small developers are the ones who will be writing the most creative iPhone apps. Fleshing in the iPhone universe with myriad stars, that are just too small for Apple to bother with. Bar code readers based on the camera. Foreign language flash cards, Road trip license plate games for kids where, when they see a new license plate, they could press a button for info on that state. Lava lamps, virtual fish tanks. Carpenter’s levels. Nail finders. The possibilities are endless and Apple will never do any of them.

“The iPhone already contains a large chunk of ARM adapted Cocoa classes with the exact same method prototypes that have been in use for years in OS X. Apple isn’t going to change classes like NSDictionaries, NSStrings, NSURLs etc for the simple reason that it’s battle tested, ‘just works’ and changing these would break all their stuff too.

”So, that just leaves a handful of high level iPhone specific classes. For example, I’d be a happy camper if, in addition to file read/write, Apple gave us the following iPhone hardware accessor classes:

  • NSBasebandService
  • NSBasebandClient

  • NSBluetoothService
  • NSBluetoothClient

  • NSWiFiService
  • NSWiFiClient

  • NSMultiTouchClient
  • NSAccelerometerClient

“With NSBasebandService and NSWiFiService, it would be possible to create a wireless modem application where your laptop talks to the phone in WiFi-ese and the phone talks to another phone on the other side of the world through the baseband. Teleconferencing from a camp site.

”With NSMultiTouchClient, you could use the raw coordinate (and pressure?) data however you wanted. Keys on a virtual instrument, pads on a virtual drum kit, whatever.

“With NSAccelerometerClient you could create really cool multi-player games and physics demonstrations for the classroom.

”Apple needs to do this. I can’t put an accurate percentage on it, but my gut feeling is that third party apps could increase iPhone sales by 10 to 15 percent. Maybe even more if someone comes up with something revolutionary.“

The Hacker Stigma.
Tozier raised some good points. However, regarding the hacker stigma, what great or useful applications do people not use because of such a stigma? Mac the Ripper, Handbrake, and torrent apps and sites are wildly popular, even though they are known to be ”grey area“ and require thwarting of laws and jurisdictions just to host them.

People might be afraid of putting unknown third party software on their mobile, but they should be. If Apple rubber stamped its approval on all third party software to remove this stigma, it would only confer all rage related to glitches, battery loss, spyware, and other problems directly upon Apple.

Why would Apple want to take responsibility for a bunch of hobbyist apps when it faces regular petty lawsuits over ”whether it adequately informed users that batteries might wear out“ and other frivolousness?

Frozen Cocoa: Tastes Great But Doesn’t Flow.
The hackers are already working to use Apple’s Cocoa classes. There is no alternative system on the iPhone to use. Just as on the Mac desktop, many apps are existing Free and Open Source Software wrapped in nice Cocoa interfaces. That’s what iPhone apps would largely be as well. But for Apple to offer official support for this, it would have to freeze its Cocoa frameworks and make them public.

Apple already maintains private frameworks in Mac OS X; developers can’t really use these, not because Apple wants to reserve them for itself, but because they are in flux. Apple commonly develops a framework privately, then after testing it in production and refining it, opens them up for developers to use in the next release of Mac OS X.

If developers were allowed to build against the closed versions, their work would break as Apple made improvements. It’s the same on the iPhone. If Apple opened up its internals as a public API, it would then be hamstrung to make any changes.

We already know that Apple plans to make major changes to a number of things, particularly Notes and Calendar in relation to Leopard. If Apple allowed developers to go out and build a ”Notes+“ they would be angry after Apple released its own plans related to Notes, and ”outraged Mac users“ would be paraded around offering their opinion that Apple shouldn’t step on developers shoes and should pay third parties before offering a similar solution to the same problem. Think of Watson and Konfabulator.

An Expanding iPhone Software Ecosystem of Small Developers.
At the same time however, Tozier raises salient points about the breadth and depth of software that Apple will never provide solutions to. I have an iPhone. I want to install cool things on it. I can imagine things that would be incredibly useful and powerful and fun.

I’m surprised Apple hasn’t made any allowance to even package up ”local web apps“ that developers could distribute that could do things without a network connection. It would be great if Apple could deliver a sandbox environment that would skirt around all the problems I raised and deliver a vibrant software ecosphere for the OS X devices.

I can also think of a dozen other things It would also be great if Apple could tackle. Unfortunately, market realities mean that the company’s abilities are constrained and it has to focus on the most valuable opportunities. As the company builds the iPhone platform, I think it will make sense to progressively allow increased access to third parties.

Steps Toward Open.
I think ”local web apps“ would be an extremely important first step, along with simpler Dashboard-like widgets similar to the iPhone’s Maps, Weather, and Stocks. Put them on a separate set of pages behind ”Dashboard“ or something. Very little risk.

A second step would be to allow access to the cooler stuff via the web, so local web apps could access sensors and Bluetooth and other things. This begins to raise security risks and liability risks. The first apps are going to be used to copy around songs and pop up ads; there is too much money in ”not paying for content“ and ”pushing messages at people.“ Look at Windows: open ubiquitous platform, satiated with software piracy and viral adware.

I agree that the idyllic paradise is flowing with the milk and honey of third party software, but there are real threats to defend against as well. Which is why I brought up Mac OS licensing. Who would have guessed that software licensing would cost Apple more money that it made? Good ideas are sometimes really just ideas.

But ideas are so much fun to speculate about. Let’s play Reverse Bingo for iPhone Software, by trying to correctly guess which icons will fill up the iPhone’s home page. I have a few ideas, but there’s still time to suggest your own.

What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , ,