A Taste of What’s New in the Updated App Store License Agreement and New Review Guidelines

Thursday, 9 September 2010

Apple today announced several significant changes to the iOS developer agreement, and a new document called the App Store Review Guidelines. The latter is intended as a plain-English guide to the rules and guidelines Apple is using to determine which apps to accept into the store — a guide that has been sorely lacking to date.

These documents are only available to registered iOS developers, however, so here’s a look at some of what’s new.

Section 3.3.1 — Third-Party Developer Tools and Languages

This is the section that was changed a few months ago, with the release of iOS 4.0, to ban the use of third-party developer tools. In the 4.0 version of the agreement, section 3.3.1 read (italics added):

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

In today’s updated agreement, the entire italicized section has been removed. There’s no longer any mention of specific programming languages, nor any prohibition against “intermediary translation or compatibility layers”. This means, I believe, that tools such as Adobe’s Flash cross-compiler are no longer banned from use. If you can produce a binary that complies with the guidelines, how you produced it doesn’t matter.

Section 3.3.2 — Interpreters

Old:

3.3.2 An Application may not itself install or launch other
executable code by any means, including without limitation through
the use of a plug-in architecture, calling other frameworks, other
APIs or otherwise. Unless otherwise approved by Apple in writing,
no interpreted code may be downloaded or used in an Application
except for code that is interpreted and run by Apple’s Documented
APIs and built-in interpreter(s). Notwithstanding the foregoing,
with Apple’s prior written consent, an Application may use
embedded interpreted code in a limited way if such use is solely
for providing minor features or functionality that are consistent
with the intended and advertised purpose of the Application.

New:

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.

I don’t think this new language is a change in policy. It’s just a shorter, more direct explanation. So, for example, games that include a Lua interpreter are OK, but only if they use the Lua interpreter to run scripts that are hard-coded into the app bundle itself — it can’t be used to interpret script that users can download or install later. This change in language matches the de facto policy that has been applied by the App Store reviewers.

Section 3.3.9 — Privacy and Analytics

Old:

3.3.9 You and Your Applications may not collect, use, or disclose
to any third party, user or device data without prior user
consent, and then only under the following conditions:

The collection, use or disclosure is necessary in order to
provide a service or function that is directly relevant to the use
of the Application. For example, without Apple’s prior written
consent, You may not use third party analytics software in Your
Application to collect and send device data to a third party for
aggregation, processing, or analysis.

The collection, use or disclosure is for the purpose of serving
advertising to Your Application; is provided to an independent
advertising service provider whose primary business is serving
mobile ads (for example, an advertising service provider owned by
or affiliated with a developer or distributor of mobile devices,
mobile operating systems or development environments other than
Apple would not qualify as independent); and the disclosure is
limited to UDID, user location data, and other data specifically
designated by Apple as available for advertising purposes.

New:

3.3.9 You and Your Applications may not collect user or device
data without prior user consent, and then only to provide a
service or function that is directly relevant to the use of the
Application, or to serve advertising. You may not use analytics
software in Your Application to collect and send device data to
a third party.

Again, shorter and sweeter. The language that seemed written specifically to ban AdMob — the mobile ad network purchased by Google, a purveyor of mobile operating systems — has been removed.

That’s it for the significant changes to the developer license agreement.

App Store Review Guidelines

This new document is written in remarkably casual language. For example, a few bullet items from the beginning:

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.

10.5 Apps that alter the functions of standard switches, such as the
Volume Up/Down and Ring/Silent switches, will be rejected

And some interesting ones:

2.11 Apps that duplicate apps already in the App Store may be
rejected, particularly if there are many of them

3.10 Developers who attempt to manipulate or cheat the user
reviews or chart ranking in the App Store with fake or paid
reviews, or any other inappropriate methods will be removed from
the iOS Developer Program […]

11.11 In general, the more expensive your app, the more thoroughly
we will review it […]

14.1 Any app that is defamatory, offensive, mean-spirited, or
likely to place the targeted individual or group in harms way will
be rejected

14.2 Professional political satirists and humorists are exempt
from the ban on offensive or mean-spirited commentary

(Not sure why “professionals” qualify for an exemption here, nor what it is that qualifies someone as a “professional”.)

The existence of this document is a very welcome change, and it goes a long way to answering much of the criticism regarding prior controversial App Store rejections, by putting in writing the rules that are actually used by the reviewers.