This aims to be a list of actual AppStore rejection criteria based on our, and hopefully your, direct experience. Please add to this compendium by leaving your own rejection reasons in the comments and we’ll add them to the main list on a daily basis.
1) Vibration. It is not permitted to use continuous vibration in your apps – short bursts as warnings is all that is allowed. Don’t bother trying to set up a timer to keep the vibration going, it will cause your app to be rejected.
2) Linking to private frameworks. This is obvious, but somehow in playing around with stuff we had linked to the MoviePlayer.framework. That’s a no-no, and cost us about ten days while we unlinked that framework, recompiled, and then resubmitted.
3) Improper handling of editing in tableview cells. Also obvious, but be aware that if you enable table cell editing, you’ll have to manually specify which cells should respond to editing controls and which should not. We had some random prefs cells in one of our early apps that were able to be swiped to bring up a ‘delete’ badge. Of course it didn’t do anything, but Apple justly considered this poor design and rejected our app.
4) Icons. Make sure the 57 pixel icon is identical to the 512 pixel version. Also, use a different icon if you are creating ‘lite’ and ‘pro’ versions of your app (i.e., free and paid). Using the same icon for both sends your app straight to … you guessed it … teh bin.
5) Flatulence. Don’t even try. ’nuff said. Now Allowed! Hallelujah!
6) Copying existing functionality. This one is much more subtle and insidious, and has probably affected the great percentage of developers. In addition to the widely publicized Podcaster debacle, reports from user comments indicate that Apple is casting a wide net when looking for duplicated functionality. Mini web browsers, or apps that essentially show web pages, seem particularly vulnerable, even if they add new and/or useful functionality. Stay away from email clients as well.
7) Using appropriate keyboard type. If your app asks for a phone number or other numeral-only input and you present a keyboard that also includes the possibility of entering standard alpha-numeric input … yep. (Thanks Jeremy1026)
Version numbers. If your app is currently at version 0.99 or below, you’d better consider giving it a promotion as Apple seems to prefer 1.0 and above. One of ours was recently rejected for being .016, with a message suggesting that our version number wasn’t even numeric. When we resubmitted the same app from scratch as version 1.0, it went through.
9) Using Apple’s graphics in your own apps. Since Apple did such a tremendous job on the UI for the iPhone, it is awfully tempting to use their graphics and/or style in your own apps. Resist the temptation: we’ve heard of projects being rejected for using the Bonjour logo, as well as Apple’s network icon (the little picture of the globe with all the glowing lines), and others. Even if you use Apple’s button images you may tempt fate if you use them in any way that is at odds with how Apple uses them. For instance, the blue button with the “+” sign can ONLY be used to add a contact to a list – don’t try to use it for anything else.
10) Tableviews again. Victor Wang is REALLY picky about tableviews. If you let a user highlight a row in order to select something or initiate an action, you’d better make darn sure that row is DEselected by the time the tableview is displayed again. Want to keep that row selected as a ‘feature’ (perhaps to remind the user which item they last selected)? Not if you want your app to be approved by Apple, you don’t!
11) Network reachability. If your app uses a network connection, it is YOUR responsibility to tell the user if and when their device loses its network connection. In a recent appstore rejection screenshot, the Apple tester had clearly turned on Airplane mode, then launched the app. When the tester was only informed that the app could not log in, but not that the reason for the login failure was because of the lack of a network connection, the app was rejected.
12) Offensive language from your users. If your app has an interactive component that lets users post text, or if your app pulls user-generated content from the internet, it is YOUR responsibility to censor the language – otherwise Apple will censor your app right out of THEIR store. In a recent report, the Apple tester had written ‘F**K’ into a chat window, and then immediately disqualified the app for obscene language.
12) Use of private APIs. If it isn’t in the iPhone SDK documentation, you can’t use it. This is particularly frustrating for OS X developers moving code over to the iPhone because a lot of functions do work fine and you don’t even suspect that they could be off-limits for the iPhone. Nevertheless, here are some of those calls you might want to make sure are not in your codebase:
currentHost
descriptionWithCalendarFormat:timeZone:locale:
removeFileAtPath:handler:
setNumberOfRows:
terminate
No comments:
Post a Comment