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.
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.
As this is a very new policy, it’s still unclear whether the only Ratings criterion necessary to select is “Frequent/Intense Mature/Suggestive Themes”, or whether applications must also specify the other types of content that may be viewed with unfiltered internet access (nudity, horror/fear themes, drug references, etc.).
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.
[…] Lite cannot be posted because it is a feature-limited version. Free or “Lite” versions are acceptable, however the application must be a fully functional app and cannot reference features that are not implemented or up-sell to the full version.
(via App Rejected)
This is tricky and easy to misinterpret, but here’s what it most likely means:
This policy is loosely defined, but Apple’s enforcement hasn’t seemed to change since the App Store’s launch, so it seems mostly stable.
We’ve reviewed [App] and determined that we cannot post this version of your iPhone application to the App Store because of an Apple trademark image. We want to remind you of the importance of following Apple’s posted Guidelines for Using Apple’s Trademarks and Copyrights.
Apple applies this very broadly:
If you must refer to a user’s iPhone or iPod touch, it’s recommended to simply refer to the “device”.
We cannot post this version of [App] to the App Store because your application contains pricing information in the icon and/or marketing text (Application Description / Release Notes). Providing specific pricing information in these locations may lead to user confusion because of pricing differences in countries. It would be appropriate to remove pricing information from these locations.
To the best of our knowledge, this rule hasn’t yet been enforced to metadata updates while the app is live—only to the metadata at the time of initial or update submission.
It is probably acceptable to mention that the price has been reduced for a sale if you avoid mentioning specific numbers or currencies.
This also applies to mentions of pricing within your app, according to Brent Royal-Gordon:
This app included a small ad on the About screen for another app by the same company, and the ad text included the other app’s price.
More from Mobile Orchard’s excellent list:
While not expressly forbidden in the contracts, Apple rejects prize applications and apps that contains contests or giveaways. There are exceptions to this policy. For example, Apple seems willing to let game applications tie into an on-the-web leaderboard with prizes, though an in-app/embedded leaderboard with prizes is likely verboten. However, as the policy is either unwritten or unavailable for review outside of Apple, trying to create an app that narrowly fits within the inferred acceptable parameters or operates similarly to existing giveaway apps already in the store is risky.
Other applications have also been rejected for promising in the app’s descriptions to donate their proceeds to a charity. You may donate to a charity, and you may talk about it on a separate website if the app has one, but you may not include such promises in the App Store description.
