Unpublished rules and clarifications from Apple's App Review team that can cause your iPhone app to be rejected.
Are we missing one of your rejection reasons that other developers may not know about? Submit it.
Submitted by Mahmud Ahsan: If your screenshots depict an iAd banner, make sure that it’s not showing an error state:
We’ve reviewed your application, but cannot post this version to the App Store because your marketing screenshots display an invalid iAd state. […] The marketing screenshots should not display an error condition in the iAd banner.
This makes sense: an iAd error could be perceived as an application error, or as an Apple failure, neither of which should be depicted in App Store screenshots.
Submitted by Mark Jones:
“I received a rejection today because we submitted an application specifically for a local Private Golf Club and they (the club) do not want everyone in the world to be able to download their app. The content in the app is specific to club members, i.e. schedules of events, contact info for golf pros, tennis pros, feedback questionaires to improve processes, etc.”
This is common. The vague “limited audience” phrase seems intended not as a measure of its potential success, but certain types of customer-base limits, such as being employees of a certain company or, in this case, members of a certain private club.
But it does not seem to apply to other small audiences, such as residents of certain towns or practitioners of certain specialties. Maybe the distinction is whether the audience is public and inherently disorganized, or private and organized.
… Paul came up with an idea that would actually allow Pastebot to run in the background. … The idea is to have a silent audio clip play in the background. This would use one of Apple’s backgrounding APIs that allows music to play in the background. Turns out it works flawlessly. … Rejected. It wasn’t what we hoped for, but to be honest it was expected. We aren’t allowed to play a silent audio clip in the background. … They have rules to follow to keep the background services from being used in ways they were not intended to. Fair enough. In the rejection letter, Apple gave us two options:
- Provide audible content to the user while running in the background
- Remove the audio from the background
… Why don’t we just let our users select a song from their music library to play in the background?
No word yet on whether this will make it through. (Our guess: it won’t.) But it’s quite interesting if it does. Still, we cannot recommend that you rely on this for any core functionality of your app, as Apple could decide to reject workarounds like this at any time.
Apple started removing apps from the Store today that provide Dashboard-like widget environments. Shifty Jelly cites an email response from Steve Jobs:
We are not allowing apps that create their own desktops. Sorry.
Details on enforcement remain scarce, but any app that shows a screen containing various user-configured widgets, such as a clock, weather forecast, and stock ticker, seems vulnerable.
It seems as though the ban is only for the creation of multiple-widget, desktop- or Dashboard-like environments. Applications that function as individual “widgets” themselves, such as a weather app, do not appear to be affected.
Apple has recently been testing submitted apps with a static analysis tool that detects whether an app calls any undocumented methods, even in public frameworks. The tool appears to detect only the undocumented methods’ names, so if you create a category method with the same name as an undocumented method and call it, the analyzer will flag that as an undocumented method call.
Any detected undocumented method calls result in rejection.
This has always been the documented policy, but in the past, undocumented calls were frequently slipped through approval if they weren’t obvious or went unnoticed by the reviewers. As a result, many apps in the Store use undocumented methods. This no longer appears to be possible for any new apps or updates.
Submitted by Dan Fabulich:
We’ve reviewed [app] and determined that we cannot post this version of your iPhone application to the App Store at this time because of inappropriate ‘Keywords’ used to identify your application. We will not post applications that reference other applications in their search criteria. It would be appropriate to remove [name of a competitor’s app].”
Keyword terms must be related to your application content and cannot contain offensive terms. It is not appropriate to reference other applications.
This is great news. One popular sales-inflating technique we’ve all seen is to list popular or competing apps in the description field to be included in search queries for them, e.g. “Perfect for fans of Flight Control, Koi Pond, iFart Mobile, and iShoot!” This prohibits such techniques in the Keywords.
Note that this rejection only cites inclusion of such words in the (relatively new) Keywords field. We do not know whether the policy applies, or will be applied, to the Description field.
We get this a lot (thanks, Nick et al.):
We have determined that this application contains minimal user functionality and will not be appropriate for the App Store.
We’ve heard minimal specifics on apps that cause this rejection, but the most common implication is that apps are rejected for being simple brand showcases, showing a few photos or playing a few music tracks, without any other real purpose or features. These apps are usually developed by consultants for clients who want a brand presence in the App Store but can’t (or won’t) provide any useful functionality.
This rule has also been used to reject extremely simple joke or novelty apps.
Enforcement seems to be increasing recently. For instance, if a developer submitted a “flashlight” app today that just displayed a white screen and had no other features, it would probably be rejected for this rule, despite such apps being acceptable last year.
As this is a difficult criterion to judge, expect inconsistent enforcement, especially for questionable edge cases.
Submitted by Wouter:
[App] cannot be posted to the App Store because it is transferring excessive volumes of data over the cellular network, which as outlined in the iPhone Developer Program License Agreement section 3.3.20, is prohibited.
Wouter says that the app was loading a video over the network. Apple doesn’t cite an exact data limit, though a few developers have suggested that there’s an approximate guideline of no more than 5 MB in an unspecified short time interval, possibly 5-10 minutes.
From Max Williams: “You’re not allowed to have any kind of cracked or broken screen effect.” The rejection cites “simulating failures” as prohibited.
Your app also cannot, intentionally or not, do something that could be construed as an iPhone software or App Store error, as whiskyvangoghgo discovered:
We attempted to publish an app called “@%#!?! Allergies”. The name was rejected on the grounds that users may think that the odd characters were the output of an error in the iTunes Store.
More generally, you can’t do something that could potentially make the iPhone or App Store look bad.
The recent removal of Google Voice apps has brought this to everyone’s attention again. Many of us had forgotten since the Podcaster rejection first taught us about this rule.
Your app cannot substantially overlap or replace built-in functionality. You can’t make a phone-call app or an email client or an MP3 player or a podcast downloader.
This is a slippery slope, and we have too few data points to understand the nuances of this rule. Generally, stay out of Apple’s way and don’t compete directly with a built-in app. If your app does something that Apple is unlikely to care about themselves because it’s too specialized or appeals to an audience smaller than “everyone”, you’re probably safe.
Please make it clear to the user that their personal user data is being uploaded to your server, and obtain their consent before submission.
From Dave Wood, whose app “reported the device stats, model, OS version, etc. to our servers on startup”.
Submitted by Chris Hitchcock:
When the device is not connected to a network and the user attempts to view additional details on the web, your application does not load its contents and stays blank. This behavior might lead to user confusion. It would be appropriate to display either a notification or an alert stating that internet connectivity is required.
This site is for less-obvious rejection rules, but this rule causes such a large volume of rejections that it’s worth including because it so frequently hits even the best developers.
Any network-access attempts:
Keep in mind that the Reachability code is not reliable enough to be used as the sole source of connectivity information: sometimes it reports no connection when there is one, and sometimes it reports a connection when it’s not fully present or not usable for a complete connection. Always respond properly to UIWebView’s and NSURLConnection’s error-related delegate callbacks.
Apple will reject apps that allow you to purchase items from a third party. My deal tracking app was rejected and I was told to launch that content in Safari instead. Of course that defeats part of the purpose of such an app.
Submitted by Craig Hunter.
We’ve reviewed [App] and determined that we cannot post this version of your iPhone application to the App Store at this time because it is not appropriately rated. Our review indicates that the application content is not consistent with the current rating. [App] allows unfiltered access to the internet, where content with mature or suggestive themes can be accessed. Applications must be rated accordingly for the highest level of content that the user is able to access.
The definition of “unfiltered internet access” seems very broad and could include nearly every app with a user-controllable UIWebView or every app that fetches internet-based data, such as Twitter’s trending topics.
UPDATE: As of spring 2010, it appears that this policy is no longer in effect. Updates to applications with the 17+ rating for this purpose can now generally be submitted as 4+ without issues.
Via Mobile Orchard’s Avoiding iPhone App Rejection From Apple, Part 2:
Brian’s original article included “political lampooning.” I’ll extend that to include association or portrayal of public figures. Two examples: around Obama’s inauguration, CodeMorphic created an app called Obamify that manipulated photos to appear like those iconic posters from the campaign; the app went into infinite review. Yak Apps had to remove imagery containing Mr. and Mrs. Obama before their “First Dog” app was approved.
This rule is very likely to be the explanation for the “game-changer” rejection: it was all about Chuck Norris.
Mentioning Steve Jobs is also prohibited: (submitted by Jon Keaty)
Apple will reject any app that mentions Steve Jobs in any context, such as a clue in a puzzle. It does not matter how trivial the reference, just the name is enough.
Furthermore, reader James tipped us off about a problem he hit when mentioning the street address of the Apple campus:
The loading screen for [the app] used the address for Apple’s Cupertino campus, and was rejected (Apple actually said “This app is taking more time to review”, then the developers received a call from Apple). The address was changed, and the app was approved.
It’s safest to avoid mentioning Apple, its corporate information, or any of its personnel directly in the app or description, even if it’s well-intentioned.
