Thoughts on Apple’s new App Store Guidelines

As you’ve no doubt heard, Apple has finally pulled back the veil of secrecy and ambiguity that surrounds the application review process for the App Store, publishing a very frank and straightforward set of App Store Review Guidelines designed to let iOS application developers know what to expect from the review process and therefore how to build their applications to meet Apple’s requirements.

The document is clearly written in plain, and perhaps even somewhat blunt language and opens with an introduction setting the tone for what Apple expects from successful App Store developers. The emphasis here is on producing tasteful and professional apps that are well thought out and perform useful tasks or provide lasting entertainment. The document comes right out and says “We don’t need any more Fart apps” and “if your app looks like it was cobbled together in a few days” it will be rejected. Apple also makes it pretty clear that the App Store should not be considered a place for free speech or self-expression:

Digging into the document a bit, it’s worth pondering what has really changed, and whether this new set of Guidelines represents a relaxation in some of Apple’s policies or simply a codification of limitations that were previously left ambiguous and therefore to the seeming capriciousness of Apple’s App Store Reviewers.

Some of the limitations are obvious and have been there since day one, albeit not in as plain form. Apps that crash, exhibit bugs, don’t do what they say they do, or use parts of the hardware or iOS that they shouldn’t will be rejected. No real surprises there.

Beyond this, however, there are a few new restrictions that don’t seem to have applied to apps in the past—at least not originally. Whether this is just because these apps slipped through Apple’s review process is difficult to say, but it more likely suggests that Apple has been making up the rules as it goes along and has only now come up with enough of them to produce an actual document. Even so, these new Guidelines still contain more than a few wide nets that Apple can cast at its sole discretion. Even terms like “lasting entertainment value” can be pretty open to interpretation.

For instance, Section 2.11 states

Although it would seem that this is intended to prevent direct copycat apps, there’s a lot of room here to define what constitutes a “duplicate,” particularly with the wide variety of similar apps we’ve seen in the past for services like Twitter.

This could be intended to eliminate some of the barely functional “serial apps” that are put out, such as dozens of different speed dialers that differ only in the icon used for them and apps used only to display single photos. However, Section 2.20 addresses this:

On the subject of barely functional apps, the new Guidelines contain several sections pertaining to the kind of basic apps that the company doesn’t want to see, which may serve to eliminate some of the digital business cards and “appified” web sites that we’ve seen in the past.

It will be interesting to see how rigidly Apple applies these policies. For example, will a “business card” app be approved if it includes a novelty calculator or puzzle game?  What about an “appified” web site that provides the ability to e-mail links or share on Twitter and Facebook?

Section 3 deals primarily with the truth in advertising aspect of application descriptions, icons and keywords, but also bars the mention of Apple’s competition in App Store descriptions.

We’ve seen this policy enforced before, but it’s nice to see that it’s now codified right here in plain language.

It should also come as no surprise that Apple clearly prohibits gaming the App Store review system, an offense we’ve already seen at least one developer booted for.

A lot of the information in the guidelines also pertains to privacy and ensuring that in-app purchases are used in an appropriate manner. The Guidelines clearly state that user consent is required before using any location data, transmitting data about a user or sending Push Notifications, and that Push Notifications cannot be used to send personal or confidential information, unsolicited messages or any kind of advertising, promotions, or direct marketing.

Likewise, a section on Game Center makes it abundantly clear that the information in the Game Center network is to be treated with extreme discretion, preventing apps from even displaying a Game Center user’s Player ID.

Section 5.7 on Push Notifications provides an interesting new policy prohibiting apps from charging for the use of Push Notifications.

This is one area which we’ve clearly seen apps violate in the past by offering in-app purchase options simply to enable push notification features. However, it’s unclear where this line is: Apps that charge only to enable Push Notifications are out, but what about apps that offer other Push Notification related services? For example, Boxcar previously used a per-service based in-app purchase model where users would buy additional notification services, including push notifications, although it dropped in-app purchases back in June and went to an ad-supported model instead.

Under section 11 on purchasing, the Guidelines emphasize in the same vein that in-app purchases cannot be used to unlock built-in hardware or iOS capabilities.

In essence, Apple doesn’t want developers nickel-and-diming users for features that Apple has already provided.

In fact, the Purchasing section provides some interesting clarifications on what in-app purchasing can and cannot be used for, and how it should work. Apps cannot unlock or enable additional features or functionality or add content or services using any system other than the In App Purchase system, but cannot use the In App Purchase system to purchase physical goods or goods and services used outside of the application.

This explains the logic behind PayPal’s mobile payment library, since this is designed to be used for physical goods and services. Apps such as Kindle or Nook should also continue to be safe, since content is not purchased in the app, but rather via a web browser. Further, both Kindle and Nook content can be used outside of the application, as per section 11.3.

Another interesting Guideline indicates that subscription-based in-app purchases must be valid for at least 30 days and that users must be able to access the subscription from any of their iOS devices.

This has been a point of confusion ever since subscription-based in-app purchases became available. It has never been a big problem for one-time purchases as the App Store treats a re-purchase of an in-app upgrade in the same way as re-purchasing an actual app, allowing the user to apply the purchase again at no additional charge. Subscriptions are a problem by their very nature, however, since they expire and need to be re-purchased. In this case, the App Store would generally offer to extend the user’s subscription and charge the user for the extension. Several apps have previously offered shorter-term subscriptions, and apps such as MotionX GPS originally fell afoul of the requirement to be accessible on all devices, originally requiring users to purchase separate subscriptions on each iOS device. The company has since changed its approach and now associated subscriptions with a user account so that multiple devices logging into the same account can all benefit from the same subscription.

The new Guidelines also have a fair bit to say about user interface, making it pretty clear that Apple expects developers to read and abide by its Human Interface Guideilnes, something that many developers have been remiss about doing in the past.

In fact, Apple goes so far as to state that it reserves the right to reject apps if it simply doesn’t like the user interface.

Further, Apple expects developers to use its UI for what it was built to do, so designing your own UI paradigm is out, as is making the hardware buttons do things they aren’t supposed to do.