Why Apple Plays God with the iPhone SDK

August 28th, 2008

Daniel Eran Dilger
AppleInsider’s article “Developers question why Apple keeps its iPhone 2.0 SDK under NDA” presented several reasons why developers are frustrated with Apple’s tight control over the iPhone platform. Another facet behind Apple wanting to maintain a centralized position of control over iPhone development, where developers are bound by NDA to interface only with Apple but not each other, is to head off tangent hacks that might complicate Apple’s ability to lead its platform in the direction it wants.One obvious recent example of this is OpenClip, a student developer’s plan to add copy and paste features to the iPhone by allowing third party apps to copy pasteboard data from other applications’ private directories. This works under the current iPhone 2.0 software, but only because Apple hadn’t yet finalized all of the details of its application sandbox security enforcement.

With the iPhone 2.1 SDK betas, which started shipping before OpenClip was released, the iPhone 2.1 software no longer allows apps to peek at each other’s files, the implementation of a policy Apple originally announced to developers in the “iPhone OS Programming Guide” with the original iPhone 2.0 SDK. There are many other examples of how hobbyist efforts to graft unofficial APIs into mainstream iPhone development could cause problems for Apple and for users.

This isn’t a new problem; third party developers also worked to enhance and extend the Classic Mac OS of the 1980s using INIT patches that changed how the System Software worked at a low level. Apple gave developers an expanded, officially sanctioned mechanism for doing this in System 7 with System Extensions. However, this turned out to be chaotically difficult to manage.

INITs or Extensions frequently ran into conflict with each other and destabilized the system. They also served as a vector for viruses. Once an Extension grew popular among users, it became difficult for Apple to work around any problems it might cause or to deliver new features that might run into conflict with existing Extensions. In Mac OS X, Apple intentionally provided no mechanism for broadly patching the OS in the manner of System 7′s Extensions.

Third party developers have still managed to find ways to hack into the OS however. Mac OS X’s Input Managers, a mechanism NeXT originally designed to serve a controller for adding language support for complex character sets across applications, were hacked into a general purpose way to patch into nearly every app on the system and inject code that could modify their behavior and user interface. It’s easy to see why Input Managers also serve as a security hole and a destabilizing factor that cause applications to crash and system updates to fail.

As Apple progressively tightens down the system to enhance users’ security, it has only asked developers not to use Input Managers inappropriately; it hasn’t yet banned them. it also asks developers not to install code into the Mac OS X kernel unless absolutely necessary, and provides security guidelines to follow when installing applications and in other cases where sloppy behaviors could expose users to potential threats.

In other areas, Apple has gone beyond just making suggestions and is enforcing rules that following known best practices in security. From the start, Mac OS X was compartmentalized into Unix domains, including a System domain for Apple’s software, a machine domain for system wide Applications, and a User domain that segregated the settings and files of each user. User accounts and file permissions enforced the domain boundaries, to help prevent software from assuming more control that it should.

In the iPhone OS, third party applications are further compartmentalized into sandboxes. There is no communal file system that all apps can share as there is on desktop computers. Instead, each app can only access its own files within its sandbox for security reasons. Apple also limits third party apps from lingering in the background after a user has dismissed them with the home button. This is both a power saving mechanism and part of the iPhone’s security policy.

The system also requires that all apps be signed by a recognized authority, so that malware vendors can’t distribute untraceable software. Efforts to inject malicious software into distribution through the iTunes Apps Store on the sly can be remotely shut down by Apple using its “kill switch” of certificate-based security. Apple’s heightened security enforcement measures on the iPhone are also making their way onto the Mac OS X desktop, in order to allow corporations to centrally manage the software installed on their computers and to allow parents to control the access their children are allowed.

Apple’s security efforts are being rolled out in incremental advancements. If the company allowed third party developers to fork its strategies and introduce frameworks that impeded or conflicted with its plans, it would dial the company back into the days of System 7, where Mac Extension conflicts caused crashes that Apple could do little about because it wasn’t exercising its authority to enforce security on its platform.

With its Android smartphone platform, Google appears to be offering users and developers the tantalizing fruit of determining for themselves what they want, including a security model where developers vouch for their own apps on a handshake and users are free to initiate their own trust relationships with developers without any certificate-based security administered by a central authority.

However, that kind of freedom has served as fertile ground for the viruses, spyware, and adware crisis of the desktop Windows PC. The web itself is another example of a platform where anything goes and security is an afterthought, with the result being egregious adware and the mass distribution of malware that exploits the freedom of Windows PCs to seed new replicants and spam.

Microsoft contributed to the seedy nature of the web early on with its ActiveX technology, which gave developers wide open freedom to do things within the browser, with disastrous results. The only way to secure the web is to limit what can be done within the browser and rely upon external authorities to certify encrypted transactions where necessary.

Android developers, hardware makers and service providers will also have the freedom to pick and chose which APIs, hardware, and applications they want to support, ostensibly giving users the freedom of an infinite number of choices to select from, a policy that has introduced chaos among Windows Mobile phones, where choice is often an impediment rather than a feature. Symbian phones similarly have three different UI layers to chose from. Linux on the desktop has two main desktop environments, KDE and GNOME, with incompatible behaviors and implementations.

While some critics of Apple’s security policies worry the company exercises too much control what software providers can offer on the iPhone, it’s also true that the company’s mobile platform has delivered a level of success and security for mobile software distribution that other platforms can’t match, with tangible benefits for both developers and users.

The iPhone’s App Store prevents widespread piracy of developers’ work, allowing them to sell their software in volume for just a few dollars a title rather than the $15 to $50 that mobile software commonly sells for on other platforms. Users can also be confident that applications they download through iTunes aren’t infected with viruses, or spying on them via key loggers or other background tasks, and can’t even access their location without asking permission first. Android, Windows Mobile, and other mobile platforms can only hope that malicious developers don’t assault their users. Those vendors also lack a kill switch to do anything about it afterward.

And despite all the freedom Android promises to provide in hardware variety (something Windows Mobile currently delivers), iPhone users have the actual freedom of knowing that titles they buy from the Apps Store will work on their phone. iPhone developers have the freedom to add accelerometer support into their apps because all iPhones have the hardware to use it. That’s not the case with Windows Mobile, and it won’t be true with Android either.

While it’s true other platforms offer features the iPhone doesn’t, Apple’s platform starts off from a secure foundation that will be easy to build new features upon; it’s far harder to retrofit security into a platform that was designed to be full featured and impose few limits nor set any clear standards. Security requires a trustworthy authority. If Apple stopped playing God, it wouldn’t be doing its job.
Did you like this article? Let me know. Comment here, 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 (oh wait, I have to fix that first). It’s also cool to submit my articles to Digg, Reddit, or Slashdot where more people will see them. Consider making a small donation supporting this site. Thanks!

Don’t worry, I’ve heard the debates and hypotheses too. Something to do with holding off submarine patents, or just generally making competitors’ jobs that much harder as they have to worry about treading on NDA’ed holy ground.

But if there’s something which pisses off the indy developer community which Apple has cultivated so well in Cocoa on Mac OS X: it’s not being able to talk to and help out eachother in the clear. The NDA move is certainly keeping a cloud of discontent, and so is not without its concern.

“Linux on the desktop has two main desktop environments, KDE and GNOME, with incompatible behaviors and implementations…”

I’ve pointed out before that this is incorrect. Please do some research on this…! I have Kmail running on Gnome, and while it uses KDE libs in the backend, from the frontend GUI it acts like any other Gnome app. The only difference to the end-user is that the theme and the converntions used are slightly different.

KDE and Gnome do have incompatible behaviors and implementations, as in how you go about using and coding for them. It has nothing to do with displaying or managing an application, as both are valid X window managers and can handle any application that X can run. They are different, enough so that they’re two separate projects, which is fine, it gives choice and most linux users want that. But the way they go about things and the way you’d integrate your app into the extra features of each is different.

But perhaps you could answer this for me, are their API calls the same, or is there a compatibility layer available? If not, then the original statement holds up. Oh and you re-enforced this in your last sentence, “The only difference to the end-user is that the theme and the converntions used are slightly different.” which is all I’m getting from the original statement.

It wasn’t 100% clear that the “incompatibilities” stated were from a developmental view point. Yep, (as I’ve said all along) there’s differences in the API, but to the end user its nearly seemless. I’d probably have phrased it:

“Linux on the desktop has two main desktop environments, KDE and GNOME, with very different backend implementations and libraries. “

This article seems to argue that secrecy and obscurity are necessary for security of the iPhone platform. This is usually an unsound assumption, and sometimes a dangerous assumption.

Blaming developers for abusing a poor API that introduces security holes and instability misses the point: any API has problems, but a good platform company evolves the API to solve them. The twenty-year-old API issues identified above are examples of Apple’s failure to provide the necessary APIs and address instabilities in the existing APIs. It seems Apple has learned from those lessons, but to say that it is the reason for their NDA policies makes no sense whatsoever.

As a light user of linux (long-time Unix and Mac) I have to disagree. I finally learned where everything was on Ubuntu (preference, applications menu, package installer, etc.) and then went to help a friend on something else (I don’t remember which but it was the ‘other’ manager) and it took forever and was very frustrating to do simple thing. Please don’t start telling me the answers as I did figure it all out but to the end user with no knowledge of the underlying system the two were very different and had ‘incompatible behaviors’.

The NDA seems a lot like Microsoft DRM. It makes the jobs of honest developers more difficult, just like DRM makes the lives of the honest music-buying public more difficult.

At the same time, Microsoft has likely already reverse engineered the Mac OS, the iPhone OS and the iPhone SDK. The black hat hackers are freely sharing their tricks, if only clandestinely.

The only benefit from the NDA is that it keeps the black hatters from openly sharing secrets to try to hack the iPhone OS. The NDA keeps their efforts underground.

At the same time, it makes it hard for white hat developers to share their knowledge with each other for the mutual benefit of advancing the platform.

I would find it hard to believe that the whole NDA fiasco is about patents. However, Apple did get burned the first time around when the Mac OS was revolutionary.

@ everyone

Had Apple played their hand correctly with that advanced Mac technology, no other company would have ever been able to use the GUI interface of the Mac, or at least not before the patents would’ve run their full course. But that point, Mac would have become an installed standard for all fully functional computers.

Microsoft would’ve been a footnote in the history of computing. Microsoft would’ve only been a parasitic company that lived off the IBM ecosystem, that was superseded by the Mac juggernaut. Microsoft would’ve dropped off the face of the earth when IBM would’ve worked out a deal with Apple to use Mac OS in the IBM. Microsoft would’ve died off with the DOS clones that would no longer be compatible with IBM and Mac. Being unable to legally copy the Mac OS, nor its’ interface; the Microsoft clones would seem like archaic machines from the stone age.

IBM would have signed over a large percentage of their PC business revenue to Apple, probably making Apple the richest company in the computer industry.

Apple and IBM would’ve been the only 2 companies making computers. They would be making crazy money hand over fist. All computers would be as stable as any other appliance. No one would expect a computer to crash, any more than a refrigerator crashes which is never.

All computers would talk to each other (IBMs and Macs that is). Their would still be some DOS, Commodore, Tandy, and Amiga computers for the sake of competition, but combined they would sell in the single digits. They would not be considered full computers, but text-based computational toys.

Apple is now at the point that they can protect their iPhone, hardware and software, and their App Store and the SDK for making apps for their ecosystem. Apple can protect their intellectual property, or they can let everyone else steal the fruits of their hard work.

As everyone can see, not protecting their IP didn’t work out so well the first time. This time around, the paranoid behavior seems way out there. But given the gravity of the situation, a bit of paranoia might be exactly what’s called for.

Ever used an Amiga? They were smokin’. The GUI was second only to the Mac, but hardware acceleration was heavily at work throughout and they were priced just right.

It was only the IBM / MS magic of the overpriced, underperforming, positively barbaric DOS PC which killed the Amiga. An example of the software inflicted death spiral which only the Mac survived. All before the web of course…

I get what you’re saying though: if Apple had protected their design, things would have gone differently. Depends just how broad a swathe of concepts they could have owned. In many ways the Amiga was more independent than Windows ever was; that shameful clone! Besides: what would Xerox PARC have had to say about it?

(And no: I didn’t ever have an Amiga. But friends did and they rocked while they survived.)

Apple had worked out a research sharing and licensing deal that involved a number of Xerox PARC researchers moving over to work at Apple.

Apple pioneered the graphical user interface. Had they protected their IP, the other companies would’ve been prevented from copying their innovation without asking permission and paying licensing fees.

Xerox had worked out some of the basic concepts. The interface work was done in conjunction with Apple and/or at Apple, with Apple engineers. The idea came from Xerox PARC, but was only fully developed at Apple.

To think that computers could’ve have been stable appliances for Internet browsing and software from a vibrant third party software development community.

Had Microsoft not gotten their monopoly, they would not have killed off the vibrant independent software community that had created many profitable companies.

I’ve been reading RD for too long, and it’s an amazing site, congrats to the author. It was the “register” thingy on wordpress (I get the bends everytime a blog asks for “registering” just to leave two words, it’s an appalling feature of RD).

Apart from agreeing with the author, and I am a very lay person on this, I laughed a bit too hard at Realtosh’s idea that Apple would have “won the war” against IBM had Microsoft not been able to (legally) copycat Mac OS, and that it would have been such a swell sweet story, with perhaps flowers of the sixties falling over everyone’s desktop, and all the miracles prophetized by the second coming of JC, etcetera.

The crude reality is that if Apple had won the war, we would have lost it again. Apple would have become the dominant monopoly of Software, and I really, really doubt that Apple wouldn’t become as numb and as lazy as Microsoft has become. If Sculley had, in such a surreal timeline as that, still been able to fire Jobs, we would have been left not with a cheap array of lousy computers, but with a very expensive array of less-lousy computers, and my own generation wouldn’t have learned computers as young as we did, for my mother surely didn’t have the money to buy a Mac. I also don’t trust Sculley’s model of business, he probably was worse a jerk than Gates and Ballmer combined. It’s risky business to enter the world of “what if”!

Thing is, we are at 2008, and Apple’s “Survival Mode” of Business made it top-notch, high speed innovator of the first decade of 21st century. It’s all about evolution really. Death and Natural Selection.

In this case, I hope the next one to die to be MS, but I doubt it as well :)

Don’t worry: I know the Xerox PARC story well. I could even tell you about how Apple hired Xerox wünderkind Bruce Horn, who had been hired originally as a school kid for experiments with the Alto UI. My point was that if Apple could have claimed legally binding ownership over such a slew of GUI concepts as your argument demands, so too could and should have Xerox before them. The Amiga was as distinct from the Mac as the Mac was the Alto and Smalltalk.

I agree with @LuisDias on that point of detail. Although I suspect that innovations with the iPod and iPhone prove that Apple can be less sluggish than Microsoft’s proven record even when they’re starting years ahead of the competition. Conceding, naturally, that this is 2008, not 1988. It’s all ultimately a parlour game!