The new rule expands section 3.3.1 of the developer agreement to state that “applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine”. Objective-C is the language that most developers use to write applications for Mac OS X, and it’s by far the most popular language for iPhone apps, too. C and C++ are probably the most popular languages for writing games, a key part of the App Store’s success.

Apple have had problems applying their guidelines consistently in the past, and that’s partly because the wording of the developer agreement is fairly loose. The new additions are no exception.

Clearly, the intent behind the new wording is to disallow using third party tools like the forthcoming Flash CS5 and the MonoTouch project, both of which allow you to write an iPhone app without writing any Objective-C. The payoff for the developer – in particular with the Flash tools – is that it would make it far easier to write an app that can run on not just the iPhone, but also on the rival Android and other mobile phone OSes, in exactly the same way that Flash developers can target multiple desktop operating systems with the Adobe AIR platform, which powers tools like the popular Twitter client TweetDeck.

But this intent is not captured accurately in the new wording. The wording also prevents developers from creating their own abstraction layer – what developers call a “domain specific language” – that would save them time by allowing to express themselves more concisely and then have a tool generate Objective-C for them. This is a very common technique among developers, and helps to increase the quality of code and the developer’s productivity by simplifying complex and repetitive coding.

Apple even produce such a tool themselves – called Interface Builder – that allows iPhone developers to create the interface for their app by dragging and dropping UI elements in a graphical way. On a strict reading of the new rules, Interface Builder is now not allowed because developers do not use it to write Objective-C, C or C++. Clearly that’s not something that Apple will ever object to, but it does demonstrate the ludicrousness of the new wording.

Let’s let Apple’s CEO Steve Jobs explain the rationale for the new wording:

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

There are several problems with this logic.

1. It’s redundant

There is already wording in the developer agreement that allows Apple to reject applications that do not comply with their Human Interface Guidelines (HIG) and other measures of quality. Bill Dudney, author of one of the most popular tutorials on iPhone development, and now an Apple developer evangelist, had his application FotoBrisko rejected for violation of the HIG.

So, if Jobs’s concern is apps there will be apps that degrade the quality of the iPhone experience, he needn’t worry because his App Store moderators will simply reject non-compliant apps. Right?

2. You can write appallingly bad applications in Objective-C

There are many poor applications in the App Store, the vast majority of which are written in Objective-C. Here’s an example, the appallingly ugly Password Engine:

Password Engine, available on the App Store today (iTunes link)

So, despite this new rule, iPhone users are not protected from poor applications.

Here’s Mike Gunderloy on how “intermediate layers” are in fact a core element of all computing:

I’ll just say that the justification Steve Jobs produced about “intermediate layers” producing substandard code is the purest spinning bullshit. If that was the real reason, we’d be restricted to using assembler. Or hand-optimized machine code. The whole history of digital computing is the history of successively more powerful intermediate layers.

3. Ignores market factors

If Steve Jobs is right and applications produced with tools other than Apple’s are fundamentally worse than those produced with them, then the market will notice those deficiencies and vote with its feet. If this is so, then developers will not want to use Flash to produce their apps because they won’t sell as many copies as they could if they wrote it with Apple’s tools, or an Apple tools-using competitor could produce a better app than them.

One thing you can be sure of is that most users neither know nor care what language their apps are written in.

A brief though-experiment. Would there really be a noticeable increase in quality from a fart app written in Objective-C over one written in Flash?

4. Bans good programming practice

Jeff Lamarche has written a great series of posts on how to use OpenGL ES on the iPhone. OpenGL ES is the platform that makes many of the iPhone’s games possible. In one of his posts he shows how he wrote a small command line tool to make generating some of the boilerplate OpenGL code a bit easier.

In doing so, he’s in technical breach of the developer agreement. Again, Apple will most likely not reject apps that are created using this technique, in part because you can be sure that big game development shops like EA use tools like this all the time. But the inconsistencies keep piling up, and each one makes developers more unsure about whether Apple will accept their app.

(Actually, is Jeff in violation? He wrote his tool in Objective-C, and that tool “wrote” some OpenGL-flavoured C. Can this code be said to have been “originally written” in Objective-C? We’ll need a couple of philosophers to work that one out. It’s a grey area, for sure.)

5. Hostile to the big brands that Apple is courting

Apple is delighted to inform us about how many big brands are creating apps for the iPhone. As Android gains momentum, so brands will also want to create apps for the rival platform. Apple’s hope is that if there are enough barriers in the way, brands will simply not bother to create an Android version of their app. But they need to judge that very carefully, because eventually it’s inevitable that Android will be installed on more handsets than iPhone OS, and brands will have to have an Android app.

Who will the brands blame when it turns out that they can’t easily translate their app to other platforms?

6. Incentivises Adobe to redouble their efforts on other platforms

Adobe were, prior to Thursday’s announcement, concentrating significant engineering resources on the iPhone platform. If Apple doesn’t relent, do you think they’ll just give up on mobile platforms? Me neither. They’ll concentrate their efforts on Android and Windows Mobile, both of whom will be happy to help them out in any way they can in order to eat into Apple’s App Store lead.

Maybe Jobs is right and it’s impossible to produce apps that people like with Flash, but that’s still a gamble for Apple, and one that might cost them dearly if he’s wrong.

7. Contradicts Apple’s claim to want to help developers make money

In Thursday’s iPhone OS event, Jobs announced Apple’s new mobile advertising platform, iAds. He prefaced his remarks by saying that Apple likes cheap apps in the store, but recognises that developers have to be able to make money.

But this is only true as far as it goes. What he really means is that Apple wants developers to make money so long as they are loyal to Apple’s vision of the mobile future. Now, Apple wants to tell developers how to do their jobs, or to go elsewhere. That’s not the behaviour of a company that is all-out committed to helping developers make money.

(And, remember, Apple’s app store submission guidelines already allow them to reject substandard apps. If the app is substandard, it doesn’t matter what tools it was developed in, and the opposite – the opposite Apple says is impossible – is too.)

8. Where does it stop?

Apple’s rules for the App Store have only become more restrictive over time. With every restriction that they add, they make a few more developers worry that their particular app category, or a specific technique that is key to their app will be next to full under Jobs’s supremely tasteful axe. Uncertainty about whether your code will be approved for the iPhone platform is not the way to encourage developers to write apps for it.

Ultimately the only likely result of such uncertainty is that developers will flee for a less restrictive platform.

---

What should be clear from this analysis is that the target of Apple’s hostility is not Adobe, but Google. Taken together with iAds, section 3.3.1 is a way to preserve Apple’s current domination of the mobile app market. (Of course, that doesn’t stop Apple relishing a further knock to Adobe.)

As we know, Apple uses the sheer number of apps in the App Store as a marketing device. But in doing so they’ve made themselves hostages to fortune. They know that, because Android will inevitably be installed on more handsets than iPhone OS, the Android App Market will eventually contain more apps than Apple’s App Store. I’m not saying there aren’t ways for them to spin that – they could lead with the astonishing number of downloads instead – but it is a number they’ve relied on and will have to silently drop from their publicity sooner or later. It’s also one that Android carriers will be able to throw back in Apple’s face.

The strange thing about Apple’s actions is that I think they’ve probably hastened the day when Android becomes the dominant mobile application platform. Developers don’t like being locked in, and are horrified by the idea that they may be unable to distribute their work to customers. Google and others can offer a decisive advantage over Apple if they can provide greater reassurance that theirs is a developer-friendly platform, and you can be bet that this is exactly what they’ll do.

More and more talented developers are announcing that they will not develop for the iPhone because there’s just too much uncertainty about whether they will be able to recoup their investment of time by actually getting their app into the hands of users.

You’ll find plenty of people defending Apple’s new posture, mainly on the grounds that they dislike Adobe and its Flash platform. I’ve seen several delighting in Adobe’s predicament because of a perceived lack of loyalty to the Macintosh platform in the mid 90s, as though Adobe’s lack of loyalty could justify Apple’s behaviour today. The irony of ironies, though, is that many of the Flash haters are opposed to it because it is not an open platform! The only consistent position is to object to both the closedness of Flash and the iPhone, even if they are closed in different ways, with different rationales and to different effect.

The real shame here is that I think Jobs is right that the best iPhone apps are written in Objective-C. I hate Adobe AIR apps with a passion, and other cross-platform apps are rarely a satisfactory experience on any of the platforms that they run on. You could say the same for Apple’s own iTunes, which sucks even more badly on Windows than it does on the Mac.

But why not let users decide what they like? Why not let the quality of fully native Objective-C apps speak for themselves? Astonishingly, Jobs has found a way to be right and an asshole at the same time.

Instead of a confident Apple heralding the next stage in the iPhone’s development as the best mobile OS on the planet, Thursday’s announcement ensures that Apple now looks scared of Android, and is prepared to act rashly to defend itself. Rather than take on Android with superior features, better build quality, better usability and aggressive pricing, Apple shows its anxiety by hamfistedly trampling all over the people who helped them become the number on mobile app platform in the first place: the developers. What a turnaround that is!