App Store Review Guidelines published; third-party dev tools allowed

In a surprise move of transparency today, Apple stated in a press release that it is publishing its App Store Review Guidelines which will allow developers to better understand how it reviews submitted apps.

The Guidelines are only available to registered iPhone developers and require a login, but here are some of the broader themes:

• We have lots of kids downloading lots of apps, and parental controls don't work unless the parents set them up (many don't). So know that we're keeping an eye out for the kids.
• We have over 250,000 apps in the App Store. We don't need any more Fart apps. If your app doesn't do something useful or provide some form of lasting entertainment, it may not be accepted.
• If your App looks like it was cobbled together in a few days, or you're trying to get your first practice App into the store to impress your friends, please brace yourself for rejection. We have lots of serious developers who don't want their quality Apps to be surrounded by amateur hour.
• We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it.
• If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps.
• This is a living document, and new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this.

Most surprisingly, Apple is changing a policy that it adopted in April 2010 as part of the iPhone OS 4.0 beta SDK. The controversial old section 3.3.1 of the iPhone Developer Program License Agreement read:

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).

iOS Developer Program License Agreement sections 3.3.1, 3.3.2 and 3.3.9 relax these restrictions:

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.

The new section 3.3.1 of the updated agreement now 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.

The updated agreement no longer bans specific programming languages and “intermediary translation or compatibility layers" -- which would appear to re-allow the use of tools like Adobe’s Flash cross-compiler -- provided that the app doesn't download or install executable code.

This is the new section 3.3.2:

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.

Kudos to Apple for taking a major step toward transparency in the App Store, it's a positive step in the right direction -- but more importantly it means that Apple is listening to its developers.