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.

However, developers need to make sure their apps don’t resemble Apple’s UI too closely, as one developer discovered when its app was pulled for resembling the Messages app UI.

When developing streaming apps, developers must also be careful not to use too much cellular bandwidth:

Other than some more technical and obvious legal details, most of the other provisions in the new Guidelines center on app content, which even despite these new guidelines, continues to be amorphous at best.

While most issues on objectionable content are covered later in the document, section 2 on Functionality includes a seemingly out-of-place restriction.

Other content, taste and propriety issues are covered in more appropriate sections near the end of the document. Section 14 deals with prohibiting Personal attacks while making an exemption for professional political satirists and humorists. What constitutes a “professional” is not exactly defined, however.

Section 15 addresses violence in apps, including games, with an oddly-specific reference to games of Russian roulette.

Sections 16 and 18 cover Objectionable Content and Pornography, respectively, including a prohibition on apps that provide access to external user-generated content that is “frequently pornographic.”

The question of what constitutes pornography is an issue that developers have been wrestling with for some time and Apple has tried to clarify this before. It’s unclear whether these new guidelines really provide any clarity on this issue, although certainly other guidelines that prevent minimally functional apps from appearing on the App Store may help to weed out some of the more obvious examples that we’ve seen.

In the end, Apple providing some clarification of its App Store Review policies is a huge step in the right direction, providing some transparency to a process that in the past sometimes appeared to be dictated by little more sense than a blind monkey with a dartboard. In looking at many of the cases for rejection we’ve seen in the past two years in the light of these new Guidelines, it’s pretty clear that building the App Store has been a learning experience for both Apple and iOS developers alike, and that what we see today is largely a codification of this learning process. Even Apple concedes that today’s guidelines are a “living document” that will change as new apps present new questions and new challenges.

A great next step for Apple from here would be to provide a version explaining these Guidelines to its App Store customers at large rather than the current developer-focused document. This would help to diffuse much of the confusion that has in the past surrounded the “walled garden” of the App Store. Regardless, this new transparency should help developers and the public at large understand what the App Store is all about, and while there’s still a lot of room for interpretation, it seems that we can all walk away with a better understanding of what to expect—and what not to expect, from the App Store experience.