Ways to get rejected by Apple – App Store Tips

So you’ve got ‘the next best thing’, that killer game that will no doubt rock the socks off the App Store and make you an instant millionaire. Mhmm. Before you submit to the App Store, take a look at some common ways to set off Apple’s sirens and get you slapped on the hand and sent to the back of the line to wallow with the other dejected folk. This list focuses on game development specifics, as opposed to app development. Listed in no particular order:

1.) Matching high resolution icon
Having a matching 57×57 and 512×512 icon is key. The small icon is used on the device while the larger version is used in iTunes. The important part is that the large and small icons required for submission must be visually equivalent. Just because the bigger version is, well, bigger, doesn’t mean you can or should cram a bunch of extra visual elements into your design. Additionally, the new December ’09 iTunes redesign puts your high resolution icon front and center in iTunes so developers out there who were simply scaling up their 57×57 bitmap icon to 512×512 to satisfy the requirement are no longer going to get away with this. I recommend building your app icon in a vector-based drawing app (Illustrator) to allow for easy size changes later on. Think ahead to advertisements, banners, website backgrounds… You don’t want to be limited by your small icon size.

2.) Vibrate function on iPod Touch
Are you calling the vibrate function without first checking the model of the device that is running your game? The iPod Touch does not have the hardware to vibrate and according to Apple, an uncaught call to the vibration function on an iPod Touch is not allowed and is grounds for rejection. Other users have noted that Apple’s official SDK documentation states that vibration can ONLY be used for alerts but this one seems to be intentionally ignored for games.

3.) Camera access on iPod Touch
Same as #2. Calling a function that is available only on a subsection of the iDevices is grounds for removal. GPS applies here as well (1g iPhone and iPod Touch devices do not have GPS capability). It has been said that it is not enough to just inform the user by alerting “You can not use this function on an iPod” when the user taps the camera button, for example. The button should never be displayed. Note that this is not the same as graying out the button. (See #12)

4.) Network lobbies and WWW calls
If your game has any type of networking in it, be careful of specific panes, modes, pages, and areas that are designated to be for online networked use only. If you have a game lobby where online game matching occurs, the user should not be able to reach this area if there is no internet connection. A popup dialog should inform the user that they are not connected to a valid network connection. Checking for an internet connection can be tricky due to the fact that the Apple provided ‘Reachability’ sample project is said to be suboptimal for connectivity checks. Refer to this url for more information on this. If you’re using Unity iPhone, you’re in luck! “iPhoneSettings.internetReachability” returns a bool that properly describes your current internet reachability.

5.) Pictures of an iPhone on your iPhone
Imagery depicting an iPhone or iPod Touch will get you a swift rejection from Apple. Apple cites these cases as copyright concerns and while sometimes valid, this can be very frustrating for designers wanting to explain a process to the end user. Take for example a racing game in which the tutorial shows the user how to control the vehicle. “Place both hands on either side of the iPhone, home button facing you and pointing toward the right, and rotate clockwise or counterclockwise to simulate a steering wheel turning action”. The simpler method would be to show an image but Apple doesn’t take kindly to this. Note that some lucky developers have gotten away with this but with every app update comes another review process and another chance for rejection.

6.) Defamatory imagery of famous people
Apple rejects images that defame famous people. I’d love to see a tabloid try to get through the review process. Good luck. Extra warning for those creating a political app. Some have noted rejection due to political caricatures.

7.) Simulating failures
If your million dollar app involves a broken/cracked screen joke, bluescreen, kernel panic, or other simulated hardware or software failure, think again. If it will make a little girl cry because she thinks her iPhone is broken, it probably won’t get through the approval process.

8.) Use of Private APIs
I’ll admit I’m not the most knowledgeable on the subject of private API use but I can provide some layman’s interpretation of this common issue. Apple provides but does not document some functions that even they themselves use. These functions may change at any time so since they may be unstable, untested, and not guaranteed to stick around, Apple is rejecting games or apps with these calls via an automatic detection process. Recently, Apple has been providing warning emails instead of a full out rejection, which I think is a really wonderful idea. It cuts down on the number of reviews their team has to do and helps make the developers lives a bit better by avoiding a resubmission.

9.) Egregious network activity
Some developers have noted a rejection based on bandwidth usage. A rule of thumb is that a game or app should never exceed 4.5mb of data per 5 minutes of activity. I would imaging AT&T’s GPS app, which downloads all map data in real time, exceeds this limit but developers should nonetheless monitor traffic to see if they’re getting near this critical bandwidth limit.

10.) Localized text in images
This is a tough one. In order to properly support localization, you should keep all images free of localized text. If you only care about sales in one region, go for it, but this seems to be an increasingly bad idea.

11.) Pricing text in description or images
Keep your description free of dollar amounts. Each app store uses different currencies so referencing price in dollar amounts will not help your case. Once again, this is rampant in descriptions (Big Sale! Only 99c!) but if your target audience is not US, you might want to think twice about that.

12.) Limited functionality
This can mean a multitude of things. An app can be tagged as having ‘limited functionality’ if it has no apparent goal, feature, or purpose. Limited functionality also refers to crippling an app and re-releasing it as a lite or demo version. This is a commonly disputed and nebulous idea. What can and can’t be done in a lite version of a game? Well the answer is still not very defined but Apple will tell you that a Lite app cannot appear to be crippled. For example, visually disabled buttons or sections of the app are not allowed. Apple will also state that you cannot prompt the user to upgrade to the full version and you cannot display the price of the full version inside the lite app. Now you may be thinking ‘But I’ve seen many apps that do exactly what you’re telling me not to do!’ and you would be correct. Many, many apps have broken this rule time and time again while others continue to be rejected for it. Since the lite version debacle is still a moving target, my only advice is to make a lite version and hope it is approved. If not, follow their specific instructions on how to fix it up for the next go.

13.) Fatal bugs
This seems like a no-brainer but you need to fully test your app on all devices in all situations. Since this isn’t always feasible, do the best you can to avoid bugs and focus on crashing bugs since a crash on launch on any of the *supported* devices means an instant rejection.

14.) Handling user data
If you collect user information and the data is sent over a network, you need to explain to the user what will happen to their data and give them an option to opt out. For example, leaderboards require certain notification to the user that even their bogus name used on the high score boards will be sent over the internet and seen by others.

15.) Misuse of Apple’s UI elements
Users know how the iPhone’s UI is supposed to work and have been trained by Apple’s built-in apps. If you use a button image or a UI metaphor in an unconventional way, users will become confused and Apple may reject you for it.

Closing thoughts:
A post on MobileCrunch yesterday surmises that the App Store rules are becoming a bit more lax, moving forward. We’ll see how this goes, but for now, it’s best to err on the side of caution and obey the rules to avoid longer wait times and the disappointment of App Store rejection.

Are there more that I’ve missed? Leave a comment.


  1. Wow, reading that list makes me *really* want to work on an iPhone game… NOT! [/90s]

    Seriously, though… some of the items in the list are almost common sense, but at the same time I can see how people might naively assume the iPhone platform is even more of a Wild West than it is (or than Apple is trying desperately to make it).

    I'm sure this list will be *very* helpful for other developers, especially the tip about not putting an image of the iPhone in there.

  2. My app got rejected because of the non-matching icons. I immediately replaced it in iTunes connect. I then replied to the email Apple sent that had outlined the issue.

    The status in iTunes Connect said “rejected”. After I uploaded the image and replied to the email, it still says rejected.

    Do I need to start over again or just wait a few days? When an app gets rejected for small reasons, is the normal procedure to simply upload a new binary or image or whatever, reply to the Apple email with the tracking code in it, and then wait?

    Does the review process start over again when you have a tweak? Do I have a whole week to wait again to see if that icon made the grade?

    Thanks for any info…

  3. You need to resubmit. Once you are rejected you need to re-do the submission process, unfortunately. Apple usually doesn’t respond to the emails. You end up at the back of the line when a rejection happens, it’s just the way it works.

  4. Nice post. I learn something more difficult on different blogs everyday. It is going to all the time be stimulating to learn content material from other writers and follow just a little one thing from their store. I’d want to make use of some with the content material on my blog whether or not you don’t mind. Natually I’ll provide you with a hyperlink on your net blog. Thanks for sharing. Repliche Da Vinci Orologi

  5. Great write-up, I am regular visitor of one’s site, maintain up the nice operate, and It is going to be a regular visitor for a lengthy time. Goldstar Locksmith 9620 w russell rd #2134 las vegas NV 89148 United States 702-475-6826.

  6. This excellent blog post, “Ways to get rejected by Apple – App Store Tips | GTProductions” demonstrates the
    fact that u really know what precisely u r writing about!
    I actually fully agree. With thanks ,Lucinda

  7. Nice tips, really helpful way to think about app rejection. For the localization aspect, I would suggest using a tool to help the process, https://poeditor.com/. Translators can work collaboratively on apps online with its help.