On Friday, we wrote about the changes Apple is making to the terms and conditions that it requires from iPhone, iPod Touch, and iPad developers before they can write software for these platforms. The new terms include a clause that prohibits a wide range of third-party toolkits and frameworks that offer developers benefits such as quicker, more robust application development and instant access to complex functionality like 3D game engines.

We believe the targets of this change to be, in particular, Adobe and Google's Android. Adobe is imminently releasing a new version of Flash that will, among other things, be able to produce iPhone applications. The new terms prohibit the use of such tools. Android is hurt because many of these frameworks facilitate cross-platform software development. As the smaller platform, Android benefits from the use of toolkits that allow developers to target the iPhone and then rapidly, and at low cost, migrate to Android.

Over the weekend, it appears that Steve Jobs weighed in on the issue. Jobs referenced John Gruber's rationale for the changes. He then, if the e-mails are authentic, clarified Apple's position, claiming that intermediate layers between developers and the platform have two results: they result in "sub-standard apps" and they hinder the "progress of the platform."

Let's take a look at each claim.

Standards

The first argument remains unconvincing to us for empirical reasons; just look at the App store! There are many excellent applications for iPhone that use the now-restricted frameworks (for example, the enjoyable and well-received games Colorbind, Battle Bears: Zombies, and Zombieville USA all use the Unity3D framework), while many sub-standard ones that do not (see: every fart application, ever). The use of frameworks is orthogonal to quality.

In fact, some of the very applications that Jobs demonstrated at the Apple event appear to use techniques that are now forbidden—Tap Tap Revenge makes use of Lua scripting, for instance. One thing shown off during this demonstration was how the game interacted with iPhone OS 4's multitasking support; this has significance because some commentators have speculated that the framework ban is somehow due to an inability of programs using these toolkits to support multitasking. Clearly, that is not the case.

If an application is good enough for Apple to highlight on-stage, it seems disingenuous to suggest that the app is sub-standard. If high-quality applications are what Apple is after, then that is what Apple should insist on; native code is no promise of quality.

Quality

The second claim might initially seem more sound. It's true that typical frameworks do not provide access to every single feature of the underlying operating system. This may not be universally true (I believe that MonoTouch, allowing C# development on the iPhone, offers extremely broad support for iPhone OS's APIs), but it's a common enough occurrence. As such, it's certainly the case that users of a particular framework might be cut off from some new platform feature that native coders would have access to, and that framework users are therefore restricted to a particular subset of the platform's capabilities. This in turn has the potential to damage uptake of new features.

But this claim also feels unconvincing when considered in more detail. Developers generally make their choice of framework with their eyes open. Developers already balance ease-of-use, time-to-market, and similar concerns against the level of access to the full operating system, and the result of this evaluation might lead to picking a toolkit that prevents access to certain platform features.

So what? This is nothing new. iPhone OS provides a huge range of APIs (a range that grows larger with each new release), and developers already make decisions about which APIs to use and which to ignore. No program uses every single API, nor should it.

The damage done to the platform by having, say, a games toolkit that cannot access the new iPhone OS 4 calendar API is negligible; developers writing games will almost certainly ignore the calendar API anyway. Making those same developers use native code just makes their job that much harder. On its own, it does little to ensure greater use of platform features.

Further, if Apple adds new, useful APIs that a broad set of developers wish to use, the developers of third-party toolkits and frameworks will surely respond to this demand by extending their frameworks to provide this access. If this doesn't happen, and a new API is left inaccessible, then perhaps it is not so much a flaw of the use of such toolkits, but rather an indication that the new capabilities are of minority interest.

This argument can also work in the other direction. The developers of the toolkits might very well have specialized expertise—expertise that users of the toolkit lack. Consider, for example, the Unity3D framework. The people writing Unity3D understand 3D graphics, physics engines, and so on, and it's quite plausible that they understand these things better than many users of their framework. As such, the Unity3D developers are in a position to expertly evaluate—and integrate—new features that Apple has added, such as the new hardware-accelerated mathematical operations. If left up to the individual game developers, however, this integration might not happen due to lack of expertise and resources.

This is not far-fetched; the use of this kind of framework is endemic in the world of console gaming. It enables game developers (whose expertise is typically creating compelling games rather than, say, maximizing performance of the PlayStation 3's Cell processor) to make better games that wring out more of the performance and capabilities of the underlying platform than would be the case if they had to start from scratch.

As such, well-written frameworks, far from reducing the level of uptake of platform features, can actually increase it.

There may also be a concern that if developers do want to use features that are not offered in their toolkits then they face a large task ahead: porting to native code (or perhaps to some other toolkit) just to escape the confines of the toolkit they are using, and so Apple wants to avoid this kind of lock-in (instead locking them in to Objective-C, of course).

Lessons from history

Such a problem has concerned Apple in the past, when many developers used Metrowerks' PowerPlant development environment to write "Classic" Mac OS software. When Apple subsequently introduced the CarbonLib transition framework to aid in porting to Mac OS X, these developers were then trapped, facing substantial costs to migrate their code.

This is certainly something that developers need to be aware of, but native code is no panacea in this regard. The provisioning of new platform APIs still requires developers to learn these APIs and then integrate them into their pre-existing programs, and this integration can have substantial consequences.

Programs might have to be radically restructured or rewritten to make use of new platform features (for example, breaking down complex tasks into individual pieces so that they can be used with Grand Central Dispatch, or transforming their data structures to be used with SIMD), and the inertia of these existing codebases is itself an impediment to the progress of the platform.

It's also a little peculiar to imply that these porting costs only exist when third-party frameworks are used. Apple is in the process of killing off the Carbon library on Mac OS X (no new features are being added to Carbon, and its 64-bit version was killed off unexpectedly, even though it was substantially complete), forcing developers to suffer an expensive migration to Cocoa. Developers had to undergo an expensive and lengthy porting operation in spite of using a first-party, native API.

Any time you have a legacy codebase, you are at risk of developers avoiding new features because they require too much development effort to add. Third-party frameworks do not create this problem; they are merely victims of it, just as native programs are.

The new 3.3.1 terms tie developers' hands, yet do nothing to ensure that applications are high quality or that platform features are exploited by software developers. In our view, the targets remain Adobe and Android, and everyone—except perhaps Apple—still loses.