The already strict requirements that must be met for an application to be published on Apple's App Store are set to take a turn for the worse, as Apple's NDA-protected license agreement has now updated an already annoying existing clause, Section 3.3.1, to make it even more offensive.

The original clause stated:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

This clause has already frustrated developers in the past because there are tasks that developers would like to perform that can only be achieved through private APIs; though some have taken a risk and submitted applications that use such APIs, the result is often that the application is denied. The new version of 3.3.1 reads:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Things just got a whole lot more restrictive for iPhone developers. What this change means is that developers can no longer use software like Novell's MonoTouch, Unity3D, or Ansca's Corona to develop iPhone applications, and tools like Appcelerator's Titanium and PhoneGap are looking questionable. MonoTouch, Unity3D, and Corona allow developers to use the C# language and Lua scripting, respectively, to write iPhone applications. Titanium and PhoneGap allow application development using JavaScript and HTML; because they use WebKit behind the scenes to run that JavaScript, they might be OK.

The reasons that developers like and use these tools are many and varied. Titanium, PhoneGap, and Corona, in particular, offer rapid iPhone development environments that are simpler than the Cocoa and Objective-C environments used for native development. As such, they offer their users quicker, more responsive release cycles, and lower development costs. Unity3D provides a range of features to game developers like a 3D engine, a physics processing engine, audio processing, and so on—features that would be prohibitively expensive for most developers to write from scratch. MonoTouch more simply allows the use of a different programming language and different libraries, ones that certain developers might be more comfortable with.

A significant product that is soon to be added to this list of development tools is Adobe's Flash CS5.

The real enemy: Adobe

As is now well-known, Flash isn't supported on the iPhone (the license conditions prohibit that kind of runtime application), so in response, Adobe has given Flash CS5 the ability to produce iPhone applications, in a broadly similar manner to how the other tools work. As Adobe explains, Flash CS5 completely skips Objective-C, instead plumbing into the iPhone compiler to directly produce executable code.

Apple's seething dislike for Adobe has become increasingly apparent in recent years. It's a dislike that in many ways makes no real sense: most of Adobe's biggest products don't compete with Apple's (and vice versa), and using Adobe's applications has traditionally been one of the biggest reasons that people have chosen—and stuck with—Apple's platform. But that's all in the past; Apple has Flash in its sights and is doing its best to destroy it.

Adobe, for its part, has made some non-commital comments on the issue; the company still plans to ship Flash CS5, but its ability to create iPhone applications might turn out to be short-lived, to say the least.

Apple's new 3.3.1 restrictions have been met with some disdain from the developer community, too, and it's no surprise. After all, if followed literally, they'd prevent developers even from writing English language specifications for their programs—since such applications would not be originally written in one of the blessed languages! A case could be made that the rule change prevents even thinking or talking about iPhone programs. Of course, the App Store gatekeepers will not be quite so absurd, but there's certainly ample scope for inconsistent application of the rules. Nothing new there, unfortunately.

The other real enemy: Google

As well as hurting Adobe, and certainly tarnishing the company's brand new product, this move hurts Android. In fact, I think the harm done to Android could end up being even more substantial than the harm to Adobe. Although I would say that the biggest virtues of these banned tools are faster, easier development, the fact is that they also often encourage cross-platform development. Flash is perhaps the most obvious example of this, but MonoTouch, Unity3D, and Titanium all enable developers to write applications that are more easily ported to non-Apple platforms such as Windows and Android. Such conversion is not necessarily automatic—applications will typically need some amount of tailoring to adapt them to the different environments—but it's a big help.

Minority platforms are always going to be the biggest beneficiaries of cross-platform development. It might be hard to justify developing an application for a minority platform from scratch. But if I can take a program for the majority platform and then put in an extra 10% development effort to cover the minority too, that's a much more appealing prospect. Though Apple does not dominate the smartphone market taken as a whole (Symbian is the runaway leader, with RIM's BlackBerry in second place), I think it's clear that in the narrower market of, shall we say, mobile phone-computers, Apple is the leader. Symbian and BlackBerry devices are all too often relegated to being little more than phones with e-mail, and though applications can be developed for both, they have not inspired developers and users in the way that iPhone and Android have.

No real defense

Some observers strive to justify this decision by claiming it's better for Apple's users, because in their world all cross-platform apps are bad, so they're better off without. It's true that cross-platform apps often buck platform UI conventions, and so end up feeling kind of alien—available on lots of platforms, but not really fitting properly on any of them (as anyone who's had the misfortune to use iTunes on Window will testify). But it's not as though being platform-specific is some guarantee of quality. There are plenty of lousy natively-written iPhone applications out there, and these are often produced in a cookie-cutter fashion, so that they can be churned out en masse. In contrast, there are also lots of good cross-platform programs out there.

Nowhere is this more apparent than in the world of gaming. Games are in many ways a class of their own, because games generally offer unique user interfaces: interfaces that are tailored to the game, rather than leveraging the platform. And there are certainly a lot of developers out there producing high quality, popular games using tools like Flash. This idea that cross-platform applications will be bad, such that Apple's users are better off without them, just isn't universally true.

Yes, some cross-platform applications will be bad. Some native applications will be bad, too. The reasonable, equitable solution is not to ban the use of tools that produce cross-platform applications. It's to say "applications must conform to all appropriate user-interface guidelines" and ban any application that doesn't. This is something the company is already doing anyway, and something that's unlikely to be a big issue. The existing development toolkits for iPhone make it easier to produce cross-platform applications, but certainly don't enable the kind of Write Once Run Anywhere approach that Java once promised. They just enable developers to migrate the "working parts" of their applications from one platform to another. The all-important user interfaces will still need to be customized to the needs of the different mobile OSes.

No, this policy change can't be attributed to a desire to ensure the quality of the user experience. It's about control. Developers must choose to target iPhone explicitly, or not at all. Apple doesn't want anyone to even consider writing applications for other platforms, and is going to stand in the way of anyone trying to do so.

Open hostility

Hostility towards competitors is, I suppose, all part of the game. But this action is also hugely hostile towards developers themselves. The banned development environments offer things that Apple's Xcode doesn't. Sometimes it's just a different choice of language, one that a particular deveoper might feel more comfortable in. But often the advantage is simplification—the use of higher-level programming languages (like Lua, or JavaScript, or C#) and frameworks that take out a lot of the grunt-work of software development (like writing a 3D engine). In turn, developers get quicker development cycles, easier development, fewer bugs, and overall, superior applications. Banning these tools doesn't just hurt competitors. It hurts developers on Apple's platform, and in turn hurts the platform itself.

The absurdity of this is even more apparent if one thinks back to the initial announcemnt of the iPhone. The iPhone was never going to have an SDK. The mantra was "use web applications". Indeed, that was one of the driving forces behind Apple's creation of a first-rate mobile browser. Since the browser was going to be the application platform on iPhone, it had to be good. And indeed it was. The company was reluctant to produce an SDK; this was not simply a case of managing expectations, and keeping quiet about the SDK until it was good and ready. It was a sincere desire to use the web as the development platform. The eventual decision to release an SDK caught many within the company by surprise.

Web apps are still an option, of course, for developers willing to live with their inherent restrictions. For those who can stick with C and C++ for the majority of their development, some level of compatibility between iPhone and other platforms is still possible. But both options still fail to give the considerable benefits that the third-party development platforms provide.

Apple's current—and in our opinion, objectionable—position is now close to the complete opposite of its initial stance. From promoting openness and standards, the company is now pushing for an ever more locked-down and restricted platform. It's bad for competition, it's bad for developers, and it's bad for consumers. I hope that there will be enough of a backlash that the company is forced to reconsider, but with the draw of all those millions of iPhone (and now, iPad) customers, I fear that Apple's developers will, perhaps with some reluctance, just accept the restriction and do whatever Cupertino demands.