FROM http://www.mobileorchard.com/avoiding-iphone-app-rejection-from-apple/
I’ve been developing apps for the iPhone for over 6 months now. Over this time period, I’ve successfully submitted over 45 apps, the majority under my own company’s iTunes account. Given the large number of app submissions, I’ve had my share of app rejections.
As has been mentioned many many times on the various developer forums, Apple’s approval process can be very frustrating and inconsistent. However, if you are careful, you can greatly reduce your risk of getting an app rejected.
Based on my own experiences, here’s my list of things to be careful about:
1. The dreaded HIG Violation of Apple’s Human Interface Guidelines (HIG) is probably the most frequent cause for an app to be rejected. As an iPhone developer, you definitely need to read the HIG and follow the guidelines! Take every single item mentioned in the HIG seriously. Yes, many apps demonstrate gross violations of the HIG (after all, splash screens are a no-no according to the HIG), but you can never claim “App X does this and is already in the store” as an excuse when Apple rejects your app. Well, you can claim that, but Apple will not accept it as a valid justification.
There are certain items in the HIG to which Apple does seem to turn a blind eye (splash screens probably being the most obvious), but unless you like taking chances with your livelihood, avoid going against any of the HIG guidelines.
2. Matching icons Believe it or not, Apple is now requiring the 512×512 iTunes Store icon match the 57×57 icon displayed on the iPhone. As a reason for rejection, Apple will state having unmatching icons is in violation of the HIG. There’s nothing in the HIG that states these two icons must match, but since it’s Apple’s store, you basically need to play by their arbitrary rules. So, unless you want unnecessary delays in your approval, make sure your icons match. The icons don’t have to be identical, but there should be something shared between the two. Just having them both be pictures that are of a similar theme is not enough.
3. Simulating failures Apple doesn’t like anything that pretends the iPhone or iPod Touch is failing. So, simulating a cracked screen is a good way to get your app rejected. Any other idea of faking a failure of the iPhone which you might think others would find amusing will probably also be a reason for rejection from Apple.
4. Button images must be consistent If you decide to use one of the existing images Apple provides for buttons, be careful you use it for an identical function. While the HIG states you can use a standard button in a non-standard way if your app is providing a “immersive environment”, you are better off creating your own custom buttons to avoid the risk of rejection. If you use the “action button” image, make sure tapping on it brings up a menu with choices. If it doesn’t, Apple may reject the app.
5. Bandwidth usage over cellular networks If your app downloads data over the cellular network, ensure you do not use too much bandwidth. How much is too much? Well, there isn’t an exact number, but a tech support person from Apple advised me to not exceed 4.5 meg of data per 5 minutes of activity. You can test your app’s usage by going into your iPhone settings, choosing the General->Usage menu and clearing the stats. Then run your app for 5 minutes, return to this screen and see what the stats say. Also, to get the most accurate numbers, you should turn off any other network activity on your phone while you run the test (such as Email or MobileMe updates).
6. Popup for network detection If your app requires the use of the Internet, you must detect when the network is unavailable and provide a pop-up message informing the user. Just having the spinning busy icon display and a message saying “trying to connect” is not sufficient. Apple will reject your app if you don’t provide a message informing the user that they need a network connection.
7. False claims of a missing network On a related note, make sure you don’t have any false positives in your network detection. There’s a bug in the “reachability” functions provided by Apple. If you don’t first try to perform a network connection but instead just do a reachability test, the code will always report the network is unavailable. Apple will reject your app if they discover you have this false positive case.
8. Political lampooning Don’t make any jokes about political figures, past or present, in either your app or the description in iTunes. Apple will most-likely reject your app.
9. Ensure your app description is accurate Spend some time proof-reading your app description for iTunes. This description is the only information the reviewer is going to have about your app. Make sure there isn’t anything ambiguous in the description. If there is room for misunderstanding a feature, you run the risk of the reviewer rejecting the app because they felt the app does not behave as described.
10. Keep your “what’s new” descriptions brief Whenever you submit an update, Apple requires you to provide a description of what is new in the app. Related to the previous note above, try to be as clear and concise as possible. Don’t go into too much detail describing what has changed, otherwise you introduce more opportunity for the reviewer to misunderstand what has changed. I’ve had an app rejected because the reviewer misunderstood what I said had changed in the app.
11. OS compatibility If you claim your app works with OS 2.0 and higher, you better make sure you test whether your app really does work on all the OS versions between 2.0 and the current one. The reviewer most-likely will! There are some anomalies in the behavior of certain functions across the different versions of the OS (for example, reachability code returns a slightly different set of flags under 2.0 vs. 2.2, UILabels don’t respond to the Touch events under 2.1 and earlier, etc.). If the reviewer finds the app does not work properly with a certain version of the OS, the app will rightly be rejected. However, don’t expect the reviewer to mention that they were testing using a different OS. That little detail is usually not mentioned in the rejection email, leading to the potential for lost time trying to find a bug while testing with a different OS than the reviewer. Again, test the app with every version you claim to support.
This is by no means an exhaustive list. It’s just the things I’ve personally run into in my app submissions and is a laundry list of items I keep in the back of my mind whenever I’m developing a new app.
If you do find your app is rejected, the best advice I can give is try to remain calm. Remember there are thousands of other developers in your shoes. We feel your pain. It often feels unfair, and perhaps it is unfair at times. It can be a terribly frustrating experience, especially when you’ve done your best to follow every guideline Apple provides and you might be convinced Apple is wrong in their assessment of your app.
But, it’s Apple’s store. They can do whatever they want in the end and don’t have to be fair. If you feel your app has been wrongfully rejected, the best you can do is be courteous and try to outline your position, quoting from whatever relevant Apple documentation applies. But, in the end, don’t expect Apple to yield to your request, or in many cases, even acknowledge your request. Apple is generally very brief in their email responses and sometimes totally silent. The best bet for an approval is to implement a change based on Apple’s reason for rejection and move on. Trying to win an argument because you feel you are right is not going to be productive.
And if you do get a rejection, add it to your list of things to avoid for the next app.
Six weeks ago guest author Brian Stormont posted an article here titled Avoiding iPhone App Rejection From Apple. While writing a rejection story is almost a rite of passage amongst iPhone developers, Brian took a prescriptive what not to do angle.
Brian’s story elicited a big response. Dozens of people contributed comments and wrote privately to supply additional gotchas, tips and approaches. While some weren’t helpful — e.g., “Be Trent Reznor,” in reference to the rejection then approval, unchanged, of the Nine Inch Nails app — many were.
We’ve collated, consolidated, summarized and (except when the authors asked us not to) attributed the collective wisdom to present it to you here:
1. Trademarks, Particularly Icons — Numerous apps, including Bump, the Billionth App ran into delays and rejections for including icons and imagery that a Apple deemed a trademark violation. Common culprits: iPhone-like icons and Polaroid-like image frames.
2. Giveaways/Prize Apps/Contests — 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.
3. Don’t Ask, Don’t Tell — Sometimes being above-board doesn’t pay. An example: Alan Francis wrote to tell us about his experience submitting an app that included the Pinch Analytics, an package used in thousands of apps that collects anonymized usage data. As a courtesy to his users, Alan stated that he was collecting this data and provided an opt-out mechanism. Either one of these measures is unusual; combined, almost unheard of. His app was rejected until he added a giant warning label on first run, while thousands of other applications that failed to mention including analytics were allowed in.
4. Avoid Humor Where It’s Not Expected, Or Where It Violates The HIG —
An update to the Instant New York app was rejected when its developers jokingly included the phrase “extra dragons” in their release notes — though, as noted by Jeff Richardson, Apple did approve an update to Google’s app with release notes containing “longer version number” and “ninja.” Carl HerrMann’s intentionally silly BellyButton app was rejected for a disabled “lint” button, the HIG violating joke being that nobody would want link in their bellybutton.
5. Inadvertent “Objectionable Content” — Last week, the story of the rejection and then later approval of Eucalyptus — a library app featuring over 20,000 classic books — was widely reported upon. The app sourced freely available content from Project Gutenberg. Buried in the archives was a Victorian, text-only translation of the Kama Sutra of Vatsyayana. Apple rejected the app on “objectionable content” grounds. Its author, after first trying to resolve the issue with Apple, blogged about his experience whence it was picked up widely. Shortly thereafter Apple reversed its decision. Eucalyptus was the latest in a series; previous examples: Tweetie, the popular Twitter client, rejected because people swear on Twitter; Jesse Tayler’s Craig’s List Browser because, well, take your pick — it’s Craig’s list!; and Jelle Prins’s Lyrics because not all songs are PG. Wired’s story about Jelle adding a dirty-word filter, and the easter egg to disable it, is worth reading.
6. Update Spam — There’s some indication that Apple frowns upon publishing no-change updates in an attempt to keep your app appearing in the what’s new listings. Noel Llopis provided a humorous example: “I submitted an update for Tea Time. The update was just a bug fix with the images in the picker, so in the what’s new field I wrote. ‘Fixed a bug that would occasionally display the wrong image for a tea type.’ Apple rejected the update a week later saying that they ‘tried it, but the image never changed for different tea types’. I was totally baffled until I realized they were testing the countdown screen, which has a static image of a tea cup, not the images on the picker. So I had to resubmit the same binary adding ‘in the picker’ to the what’s new description.”
7. Doesn’t Work. Doesn’t Work As Advertised — Reportedly, the most common reason for rejecting an app is that it simply doesn’t work or doesn’t work as advertised. Seems obvious, and I wouldn’t have bothered to report it if it wasn’t apparently so common.
8. Public Figures — 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.
9. Too Few Potential Consumers (Or The Appearance Thereof) — Memo Akten produced remote control software that conforms to the TUIO protocol for sending multi-touch events over WiFi. Apple rejected it on grounds that its market was too small and suggested, instead, Ad Hoc Distribution. I spent 10 minutes trying to figure out how small this niche is and was ready to write it off until I discovered that this field is connected (conceptually, at least) to Microsoft’s Surface technology and is covered by the analyst firm IDG. Would an overtaxed app reviewer at Apple spend the time to make this determination? Best bet is to save them the work by supplying them with evidence in your submission has a vast, mainstream audience — or at least a sizable niche one.
Updated: 10. Don’t Include Price In Your Description — Just minutes after I originally posted this article Michael Kaye added a very good additional tip: “Don’t mention pricing in the App Description. For example mentioning ‘now only $1.99′ will according to Apple, ‘potentially confuse users’…and they have a point as its 99 pence in the UK, €1.99 in Europe etc.” Thanks for the great comment Michael!
