Why Apple keeps its iPhone 2.0 SDK under NDA
Apple's insistence on keeping iPhone 2.0 development under strict non disclosure agreements is frustrating efforts in the development community to share ideas, teach classes on iPhone development, and print reference books on the subject.
Because the NDA precludes iPhone developers from participating in conference discussion panels or training sessions, blogging or contributing to mailing lists, or even having private discussions with other developers, many are left frustrated in their attempts to share what they've learned or find answers to problems they're experiencing.
That has pushed iPhone developers to seek creative ways around the limitations. According to an article in the Los Angeles Times, "Some developers who are seeking help have resorted to paying each other $1. That way, if challenged by Apple's legal department, they can argue that they are subcontractors and therefore free to discuss the software."
Apple certainly isn't alone in putting developers under NDA. Google's Android open source project selected a subset of its software developers earlier this year and offered them private access to special builds of the software after signing an NDA. This resulted in complaints from the open community among those who were shut out of access to all of Android's SDK updates over the last year between November 2007 and this month, when Google finally released another public beta.
Just days after releasing that second public beta of Android however, complaints began to pile up about Google's lack of "promised" support for Bluetooth features and for Google's own Gtalk service, which was pulled over security concerns. The two missing features that Google chose to delay in order to ship Android 1.0 on time were given nearly as much attention by bloggers as the company's entire year of progress on the Android SDK.
Apple works hard to manage its public appearance because its critics are similarly looking for any scrap of detail they can sensationalize to sell as news. By putting developers under NDA, the company can communicate more about its future plans to developers and retain the freedom to make changes as needed without the scrutiny of a non-technical media exposing every engineering decision to uninformed public debate, at least as long as developers respect the NDA they signed.
The historical failure of many developers to abide by their NDAs has had a chilling effect on the amount of detail Apple has been willing to provide. Even within the NDA-covered iPhone SDK, which anyone can signup to participate in, Apple has revealed next to nothing about the future of hardware peripheral support on the iPhone, including expanded Bluetooth support or any devices that might attach to its USB dock connector. There is also little known about the company's future plans to expose other low level device access to third parties.
Detailed information on how much access Apple will eventually grant developers may be withheld because Apple hasn't yet decided what it can support in the near term, given its finite resources. It's far safer for the company to under-promise and over-deliver than to outline an extensive plan for features and services that it is unable to complete.
Last year, Apple released interim web-based development details for the iPhone without any clue about whether plans to ever open a full SDK were even in the cards. This allowed the company to provide a partial solution immediately and reveal details on its Cocoa Touch efforts only when those tools were nearly ready to ship. Apple didn't escape criticism, but it was able to sustain interest in iPhone development and got third parties such as Facebook and Google working on iPhone web apps even before its full development strategy was finished.
In contrast, over a similar period of time public interest in Google's Android peaked early, then waned for nearly a year before being met with grumbling disappointment. Microsoft was similarly badgered in the press for dropping features from Windows Vista advertised during its years' long beta period, despite the fact that some of them, such as WinFS, weren't delivering the expected results and customers weren't even sure why they might need them. Vista ended up with a bad reputation for not living up to early expectations that were simply set too high, and which overshadowed its more significant advances.
Opaque engineering decisions
Apple has been similarly criticized for setting expectations that proved more difficult to deliver than expected. When Apple chose to delay the release of Leopard in order to concentrate its efforts on shipping the iPhone, the decision was met with scorn by Mac users who though they were being left out, and ridicule from critics who insisted that the six month delay would prevent Leopard from taking any competitive advantage of Vista's setbacks.
Further, despite noting that Leopard's advertised features were subject to change, Apple was also criticized for saying Leopard's Time Machine backup feature would work with the AirPort Extreme. At the launch of Leopard, the feature still wasn't ready. Apple simply dropped any mention without providing any hint of whether it would ever ship, frustrating many users. It was eventually provided through a software update involving both Leopard and the AirPort's firmware.
Apple was also taken to task for not supporting Java SE 6 in Leopard. The company made no comment on its plans, but eventually ended up delivering Java SE 6 exclusively for 64-bit Intel Macs. That engineering decision weighed the typical users of Java SE 6 against the resources needed to deliver it on each segment of the Mac platform. As with any decision, it did not please every user.
By simply ignoring the spirited and often uninformed debates that flare up around every engineering decision the company makes, Apple's engineers are able to focus on making decisions based on a more complete, internal picture of all of the factors involved, rather than being distracted to explain why each decision was made and rethinking each one in blogs and other public forums.
Apple's own developers are kept under strict NDA in part to keep engineering decisions based on attainable goals the company sets for itself, rather than opinions expressed in focus groups. Apple is working to avoid the committee-designed compromises and politically splintered engineering that often occurs in decentralized open source projects. Google's move to place Android's early development under NDA was no doubt made for similar reasons, and even Microsoft has expressed that it will be saying less about the new features of its upcoming software for the same reasons.
Another reason for locking up iPhone details behind NDA is that Apple can't seek to patent any inventions after they are publicly published. By keeping the iPhone's details under NDA, it can retroactively seek patent protection for ideas that it discovers are more novel that originally thought.
Earlier this month, the Daring Fireball blog cited a reader commenting on the subject who explained, "At my company, our lawyers advised us to keep what we considered more-or-less public software under NDA for a very long time because demoing software to someone under NDA, no matter how many people it is, avoids 'publishing' the software and any inventions contained therein. We know Apple’s been building up a patent strategy around multi-touch; maybe their lawyers believe there are patentable inventions described in the iPhone SDK and they are telling Apple to keep everything under NDA until they know provisional patents can be filed within a reasonable amount of time (you get a year after publishing in the US, but in the EU, I think you forfeit any patent claims once your invention is 'published')."
"In the eyes of the USPTO," the source noted, "every invention in the iPhone SDK is a non-published invention and will continue to be so until the NDA is lifted."
Waiting for the other NDA to drop
Despite all the reasons Apple has for keeping things private and under control, or at least as private as the "anyone can see but nobody can say" NDA allows, iPhone developers are still frustrated by their inability to share knowledge and the legal uncertainty surrounding any attempt to do so. Stanford University has already scheduled a class on iPhone programming for incoming students, which raises questions about how Apple will react to public discussion of its iPhone development platform.
Several authors have written reference guides they feel they can't publish due to worries that Apple would sue them for breaking their NDA. The LA Times cited the publisher of "iPhone in Action," who has already pre-sold 400 copies. So far, the publisher has delivered an electronic version that only covers web development, withholding the portions that delve into the Cocoa Touch SDK. The company fears it may have to refund users if it can't legally publish the information.
Also in limbo is "The iPhone Developer's Cookbook" by Erica Sadun, a writer and developer with a PhD in Computer Science who helped lead efforts to jailbreak the original iPhone. Somewhat ironically, Sadun could write more about the closed, undocumented software in iPhone 1.x than about the published details of iPhone 2.0, because like all iPhone 2.0 developers she is now bound by the NDA.