App Store Review Guidelines

From Pin Eight
Jump to: navigation, search

This is a mini-rant, a short essay refuting a common misconception among users of an Internet forum. If you think this essay is FUD, feel free to explain why on the essay's talk page.

The App Store Review Guidelines are a document distributed by Apple Inc. to authorized developers of iOS applications that dictates what can and cannot be submitted to the App Store. It completely excludes several categories of application from iPod touch, iPhone, and iPad devices that lack a paid-up developer account. Fans of these iProducts defend Apple's practices, claiming that almost nobody demands the functionality that the Guidelines ban. Even if this is true of each individual item, there are still a lot of people who want one or more items on the list as a whole.

Unlike Microsoft and Google, which make their App certification requirements for the Windows Store and Google Play Policies and Guidelines available to the public, Apple treats the Guidelines as a trade secret. For the first couple years that the App Store operated, it didn't even share the Guidelines with paying members of the iOS developer program, forcing a lot of guesswork for which the media criticized Apple. In late 2010, Apple started making the Guidelines available to members, but not to the public. Even people who sign up for an Apple ID and become a Registered Apple Developer don't have access to the Guidelines. This poses a problem: an application developer considering iOS for the first time could pay $99 to join the iOS developer program only to discover that his application concepts were guaranteed to be rejected. (It is unclear whether one can complete the payment process without already owning a Mac and a suitable iPhone or iPad.) So before you spend $1000 buying into this ecosystem, it is strongly recommended that you flesh out at least three ideas for applications in case one or two fall into categories that Apple has entirely rejected from the App Store.[1]

No app for that

One version of the Guidelines leaked in September 2010 listed over a dozen things an iOS app can't do:

Video games with realistic violence
"15.1 Apps portraying realistic images of people or animals being killed or maimed, shot, stabbed, tortured or injured will be rejected"
Russian roulette
"15.5 Apps that include games of Russian roulette will be rejected"
Chat roulette
"18.2 Apps that contain user generated content that is frequently pornographic (ex 'Chat Roulette' apps) will be rejected"
Card counting
"22.5 Apps that are designed for use as illegal gambling aids, including card counters, will be rejected"
Satire of an identifiable organization
"15.3 'Enemies' within the context of a game cannot solely target a specific race, culture, a real government or corporation, or any other real entity"
Fan-created applications celebrating an organization
"Quoth Steve", a quote of the day app based on Steve Jobs quotations, was rejected.[1]
Computer science homework
Initially, Apple banned programming language interpreters. An iOS port of a classic video game was pulled when it was discovered that the virtual Commodore 64 that it ran in could be rebooted into the BASIC prompt, allowing the user to key in programs that Apple had not approved.[2] It took years for Apple to loosen this and allow things like Codea.
Game makers
The Guidelines ban apps that "download code in any way or form" or "install or launch executable code", such as a game maker that plays games that another user has shared.
"2.7 Apps that download code in any way or form will be rejected"
"2.8 Apps that install or launch other executable code will be rejected"
Video games published by companies now out of business
Video game publishers often use emulation to rerelease older games on iOS. These emulators are cryptographically locked to run only one game. An emulator not locked to one game would require "downloading code" from a disk or ROM image, even if the image is lawfully made per 17 USC 117(a)(1). In addition, an emulator can't even mention the platform that it emulates if said platform is battery-powered.
"3.1 Apps with metadata that mentions the name of any other mobile platform will be rejected"
Launcher replacements
"10.4 Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected"
WLAN utilities
You won't find any applications for discovery and troubleshooting of wireless local area networks. For example, an application could let the user take notes about a Wi-Fi hotspot that a device discovers and use those notes to contribute to a collaborative database of public hotspots. Mozilla, maker of the Firefox web browser, has released an Android app called MozStumbler to map access points, but it can't be ported to iOS because Apple provides no public API for applications to gather information about access points that the device can see. Case in point: WiFi-Where requires a jailbreak.
"2.5 Apps that use non-public APIs will be rejected"
Web browsers that implement HTML features that Apple has left out of Safari
You can't get Firefox on iOS, [2] nor does WebGL work outside of iAd modules.[3] Uploads using the <input type="file"> element don't work either except for pictures and videos.
"2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
Subscriptions for a period shorter than 30 days, due to limitations of IAP
"11.6 Content subscriptions using IAP must last a minimum of 30 days and be available to the user from all of their iOS devices"
"11.9 Apps containing 'rental' content or services that expire after a limited time will be rejected"
One iOS fan has reassured me that "rentals" are distinct from "subscriptions", but without access to the latest Guidelines, I cannot verify this claim.
Book reading programs that use the volume buttons to change pages
"10.5 Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silentswitches, will be rejected"
Applications to organize evangelism
Apple tolerates religious content that does not offend or mislead. But using "location-based APIs" such as GPS in an application for a religion's outreach to track coverage of door-to-door preaching in a car group and track follow-up visits, depending on how an Apple application reviewer interprets "dispatch" and "fleet management". It appears Apple intended this to rule out safety-critical purposes for which it is unable to warrant performance, but the rule as written gives the reviewer wide latitude to cause unintended consequences.
"4.3 Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected"
Use of e-mail address as account identifier
A lot of existing web applications use an e-mail address to identify a user account. For example, Amazon and Dropbox use an e-mail address as an account identifier. An iOS app that ties into one of these might have to choose some substitute user identifier other than an e-mail address.
"17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected"

Even if an iProduct is technically superior in some way to a particular Android product, that's no help if somebody depends on a particular application, and Apple has made the business decision to allow that application to remain exclusive to Android. For some people who value simplicity and cannot anticipate needing to do any of these tasks in the next six years, an iDevice may be the right choice. But for the rest of us, Droid does what iDon't.

Disproof of Turing completeness

The term "general-purpose computer" is often defined in terms of Turing completeness, or whether a machine can act as a universal Turing machine. (Because a Turing machine has unbounded memory, real-world "Turing completeness" is slightly weaker, implying equivalence to a Turing machine with bounded memory.) The following is a proof that the iPod touch, iPhone, and iPad are not Turing complete out of the box.

Consider a computer program with the following pseudocode, titled "Pick-a-Winner":

  • Let Players be a queue of two to six distinct symbols, one of which is "Vladimir".
  • Let Dice be a source of random natural numbers uniformly distributed from the list [1, 2, 3, 4, 5, 6].
  • Repeat the following steps until the length of Players is 1.
    1. Let current be one element popped from Players.
    2. Let roll be one element popped from Dice.
    3. If roll is not 1, push current to the end of Players.
  • If the remaining symbol in Players is "Vladimir", accept and halt; otherwise, reject and halt.

Pick-a-Winner could be trivially implemented on a Turing machine, with Players encoded at early positions on the tape and the remainder filled with enough Dice to have at least five 1 values. (The length of Dice will form a negative binomial distribution, the same distribution whose long tail doomed The Little Match Girl.)

However, the process of Pick-a-Winner is equivalent to Russian roulette. As stated above, Apple Inc. refuses to digitally sign a program implementing the rules of Russian roulette. But any universal Turing machine can run Pick-a-Winner. Therefore, a machine that refuses to execute a program that Apple has not signed cannot be Turing complete because Pick-a-Winner is excluded from programs that it can run. This makes an iPod touch, iPhone, or iPad without a developer license or jailbreak not a general-purpose computer, QED.

References

  1. Nellie Bowles. "Quoth Steve Jobs, but Never in the App Store". Re/code, 2014-03-16. Accessed 2014-03-29.
  2. Jacqui Cheng. "Firefox is out of the iOS game until Apple changes its ways". Ars Technica, 2013-03-11. Accessed 2013-03-11.
  3. "When will WebGL be supported on iOS Mobile Safari?" Apple Support Communities, 2011-12-29.
Personal tools