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.
This is great:
… 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.
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.
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.
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.
Post with 1 note
More from BigDropInc Web Design Company:
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.
[…] 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.
Page 1 of 2