Having decided to open up iPhone OS to third-party apps, Apple is still keeping some of operating system’s functionality out of the reach of independent developers. although the company is—at least in theory—under no obligation to make any particular feature publicly available, some developers are showing their disapproval at this approach, claiming that it gives Apple’s own apps an unfair advantage. Meanwhile, the company has stated that it keeps some functionality private only because of technical, rather than competitive reasons.
At the centre of this controversy are so-called “private frameworks.” A framework encompasses a set of functions that a developer can use to perform one or more tasks, such as displaying graphics, playing sounds, or interacting with hardware. As such, frameworks act as a gatekeeper between an app and its ability to do just about anything, giving Apple ultimate control over what third-party developers can and cannot do in their software.
While most of the frameworks that are part of iPhone OS are public and can be used by anyone, Apple reserves a few of them for internal use, labelling them as “private.” This, in itself, doesn’t prevent developers from taking advantage of them—reverse engineering the private frameworks is a simple task that can be easily accomplished using common development tools. However, the use of private frameworks is grounds for the rejection of an application during the App Store’s approval process; therefore, if a developer wants to sell their software through iTunes, they have no choice but to steer clear of any functionality that Apple has not approved for public use. (In recent months, there have been cases where Apple has been more lenient about such usage and asked developers to take out the offending feature in a future update.)
Unfortunately, the same limitation doesn’t always apply to Apple itself: nothing has prevented the company from using private frameworks, even for its applications that are distributed via the App Store. And those private frameworks can deliver functionality that third-party apps simply cannot match without running afoul of the approval rules.
Marco Arment, developer of the popular Instapaper apps, points out in a post on his blog that iBooks makes use of a significant number of undocumented functions, and that a third-party developer’s inability to do the same makes “all third-party reading-related apps second-class citizens.” iBooks’s ability to let you adjust the brightness of the screen inside the app—without having to jump to the iPad’s Settings application—is an example of functionality not available to third-party programmers.
Two potential problems arise from this disparity: first, as Arment points out, Apple’s own apps create expectations that diminish the production value of third-party software. Since normal users are not well-acquainted with the subtleties of programming, it’s difficult to explain that an app’s inability to match the functionality provided by its Apple’s counterparts is not due to a lack of ability or interest on the developer’s part, but, rather, to the legalities of participating in the App Store. One could also argue that private frameworks give Apple an unfair advantage, especially as its interests expand from the core device functionality into other areas—as with the recent introduction of iBooks.
Second, private frameworks stifle the ability of third-party developers to innovate and improve on the stock Apple software. For example, soon after the introduction of the iPhone 3G, many developers attempted to improve on the functionality provided by Apple’s default camera software and add newer and more powerful features, only to find out that doing so was only possible with the use of private frameworks.
For its part, Apple has always been very clear on the fact that private framework usage isn’t allowed—even going so far as developing automated tools that scan software destined for the App Store for the use of unpublished functionality. In fact, Apple’s own use of private frameworks in apps that can be downloaded from the App Store seems to be limited to what is strictly necessary, with much of that functionality eventually ending up becoming public.
The reasoning behind Apple’s intransigence is that private frameworks are, according to the company, “works-in-progress” that have not yet been finalized and could change at any time in the future. If this were to happen, any app built using the functionality provided by them would stop working, leading to all sorts of incompatibility problems that Apple, as the ultimate gatekeeper of the App Store, would have to deal with. Public frameworks, on the other hand, are guaranteed to stick around for a really long time—on some platforms like UNIX, they have stuck around for decades—therefore guaranteeing long-lasting compatibility with any software that uses them.
In fact, Daring Fireball’s John Gruber unearthed a video in which Apple’s SVP of Software Engineering Bertrand Serlet (who, as his biography pointedly explains, reports directly to CEO Steve Jobs) explains that the company treads very carefully around its application development interfaces because, once born they tend to be very difficult to kill off.
And, for what it’s worth, some third-party developers are vocal in their agreement with Apple’s policy. Red Sweater Software’s Daniel Jalkut, a former Apple framework engineer himself, argued on Twitter that private APIs are a necessity for testing. In fact, he goes so far as to point out that they’re a good thing for developers, allowing Apple to work out the kinks before making the features available to others.
Competition or control?
In its defense, it’s worth noting that Apple does seem to keep an eye on what developers want from its frameworks and eventually makes more and more functionality available to them. For example, the camera access framework has been opened up considerably since the release of iPhone OS 2.1 to allow developers to create their own interfaces and augment the capabilities of the built-in Camera app. Similarly, a number of previously-private frameworks—such as those that allow a developer to tell whether a device is docked and how much battery charge remains—have been made available for public consumption, lending credence to the fact that Apple’s motives are fuelled by a desire to control its platform rather than to necessarily maintain a competitive edge.
Moreover, with a sneak peek at the future of the iPhone OS just around the corner, it’s highly likely that more functionality—much of it perhaps specific to the iPad and forthcoming models of the iPhone—will soon be released to developers. Perhaps, therefore, all that developers need is a bit of patience as the Apple development machine gets around to finalizing the private frameworks and opening them up.
In the end, private frameworks remain edge cases; the vast majority of apps that are submitted to the App Store are either approved or rejected on a basis other than private framework usage, and the numbers clearly indicate that this issue has not prevented the formation of a vibrant—and profitable—software ecosystem around iPhone OS.