iPhone SDK, DRM, and the Open Tool Chain

NerveGas has shared his thoughts on the iPhone SDK, DRM and the Open Tool Chain currently in use by developers. NerveGas is the author of the iPhone Open Application Development book. You can pre-order the book from Amazon here

The original post can be found at hackint0sh. I have also included it below for your convenience.

----------


With the release of Apple's SDK, the development community has come to the rude awakening that it's not all it's cracked up to be with its restricted features, missing methods, and heavy distribution scrutiny. Nobody had imagined that a development platform would be so heavily DRMed, but it looks like the compiler itself even includes DRM key exchange components. Where does this leave developers? Well, it looks like it's impossible to build anything with the Apple SDK that is DRM-free, possibly requiring approval from Apple just to run.

Apple's SDK restrictions appear to be taking a swipe at the open source community, which has already developed a functional open SDK (the tool chain), community distribution channel (via Installer.app, PXL, etc), and a very large audience of users. Nick Penree of Jailbreakme.com fame found over one million users used his site to install NullRiver's community installer on their device - just within the first few weeks. Apple is in fact lagging behind the open community, and rather than the open source community duplicating commercial efforts, Apple is embarrassingly the one trying to duplicate the open source community today. As a result, many of Apple's SDK restrictions appear specifically targeted at this established community: Apple has banned NullRiver's installer app, as well as PXL and other software installers, essentially locking out any third party distribution channels from iTunes (which may equate to unfair competition). They have also guaranteed themselves full control over the accessories market by limiting the SDK's ability to communicate with accessories. Finally, Apple has secured themselves potential contracts with game manufacturers, such as Nintendo, and with companies such as Sun and Adobe by banning any software that "executes another program's code" on the iPhone. This means companies will need to ink a special deal and pay a hefty ransom to Apple to release things like Java, Flash, and video game emulators (many of which are already available using the open tool chain).

The good news is that, in spite of Apple's attempts to thwart "unauthorized" software development on the iPhone, we now have two different SDKs to choose from - the open tool chain and Apple's. Enterprises requiring DRM control of their software, who can live with the restrictions that Apple's SDK imposes, are likely to fair well with an "officially supported" compiler and support from Apple. But where Apple has left the rest of the development community out to dry - that is, open source developers and small software houses (which will likely not see the light of day until 2009), the open tool chain provides the only way today to build DRM-free applications for the iPhone, and a distribution channel that can reach as large an audience (albeit, not as captive) as iTunes can. The open tool chain also runs on Linux and Windows, and doesn't restrict the developer from using any of the more advanced APIs - you can even run applications in the background, as God intended it. The various dev-team camps have made it so easy to add custom applications to the iPhone, in fact, that any grandma can do it today with just a few clicks - almost easier than using iTunes!

It seems that now, more than ever, does the community need to support the open source tool chain and the ability to freely write and run software for the iPhone. Why? Because Apple's SDK is designed for enterprise - and makes no bones about alienating everyone else. Fortunately, we have a free tool chain that has almost a year of maturity, a fantastic (and free) support base, and hundreds of great applications available today for the iPhone that anyone can download and use.


The Apple SDK, as many have come to find, has seemingly crippled much of the functionality that initially set the iPhone apart when first launched. Even simple features like the ability to run a program in the background, have been crippled in the Apple SDK. Fortunately, the APIs that the open tool chain uses seem to reflect more closely to the "real SDK" used by Apple to create their own applications. Most of the objects you use in the Apple SDK appear to be "wrappers" around these real objects, which limit their functionality. It's like a "fisher-price" SDK, so developers have a horn to honk, while Apple uses the private APIs for "real" software. While the Apple SDK lets you write applications that look somewhat like iPhone applications, the open tool chain allows you to get right down to the metal and write applications using the same objects as Apple's own applications - and use the same spectacular effects that are otherwise restricted.

If you think about it, a lot of the agreements we see on hold today likely have to do more with monopolizing the iPhone's distribution chain than actual technical hurdles. Take Adobe Flash for example - it runs fine on 400Mhz machines, and even runs on weaker mobile phones without any problems. It's likely that rather than technical problems holding this up, that Adobe simply doesn't want to pay whatever ransom Apple is demanding to put code that "executes other code" onto the iPhone. All of Apple's restrictions and T&C for their SDK point to market control being the key factor.

Just to confirm, the "Aspen" frameworks included with Apple's SDK appear to fully support the APIs used by the open tool chain - likely, because these are the real low-level APIs that are being used by Apple's own applications. While the Apple SDK has removed many methods from their headers, they still exist in the framework. For example, all of our old friends from UIHardware and UIKeyboard are in there:

30b32e9c t +[UIHardware deviceOrientation:]
30b3375c t +[UIHardware fullScreenApplicationContentRectForCurrentDeviceOr ientation]
30b32e40 t +[UIHardware fullScreenApplicationContentRect]

30be7744 t +[UIKeyboard activeKeyboard]
30be77d4 t +[UIKeyboard defaultSizeForInterfaceOrientation:]
30be7818 t +[UIKeyboard defaultSizeForOrientation:]
30be778c t +[UIKeyboard defaultSize]
... and so on

What does this mean? It's very encouraging, as 2.0 is likely to run all existing applications written on the open tool chain with few, if any, modifications! And this makes perfect sense - otherwise Apple would have to rewrite their own apps (which use the same APIs), presenting a significant Q/A problem (bringing their software back to beta quality). Should this change in the future, I have already begun building a set of compatibility libraries that should enable tool chain applications should Apple ever try and remove support for it.

As it stands today, the open tool chain is likely to be the dominant tool chain going into 2009, as the Apple SDK is clearly not ready for general adoption yet. Many pieces do not appear to function correctly, or at all, and there is presently no way to run these applications on the iPhone. Come June, only a limited number of developers will likely be admitted into the developer program, based on some remarks I've seen from Apple. The open tool chain works today, and has had almost a year to mature into what has become a very robust SDK with a large distribution base. I encourage developers to continue using it, and think it's going to be around for quite a while.

By: NerveGas