Avoiding App Rejection from Apple

Avoiding App Rejection from Apple

No developer wants to be rejected when submitting apps to the App Store. We all hope the process goes smoothly the first time, but there are many subtle rules and settings which need to be “just right” before Apple will approve your app.

Apple can reject your app in several ways during the submission process. The most common are probably:

    1. Automatically when you upload the app with Application Loader
    2. Due to IDFA usage
    3. Via iTunes Connect
    4. Following a human review of your app

Let’s examine each of these and the reasons by which they may issue a rejection.

1) Automatically via Application Loader

Application Loader is programmed to scan your app bundle and look for problems that would reject you immediately. The good news is that this quickly flags issues without you having to wait for a human review, a process which can take a week or more.

While the messages from Apple can be tricky to decipher, they’re generally quite clear as to where the problem lies. Most of them start with the string “ITMS-9000:“, so searching for that string may not result in useful information. So you really need to read the message and locate the actual issue.

One common one is:

“The bundle [bundle name] at bundle path [bundle path] is not signed using Apple submission certificate.”

This means that you have a problem in either your certificates, keys, or provisioning profiles, or that you chose the wrong type of provisioning profile. If you read the rest of the message, it can reveal the true cause.

If you tried to submit a Development: iOS App Development build or Distribution: Ad Hoc build, the fix is easy — just ensure that you’re submitting a Distribution: App Store build.

Another common issue is that your certificates have expired or have been corrupted somewhere along the way. The solution is generally to clear out your Keychain Access from within Utilities, ensuring that you get the keys and, afterward, regenerate everything from scratch.

“Missing recommended icon file. The bundle does not contain an app icon for [device] of exactly [size] pixels, in .png format for iOS versions >= 7.0…”

The icon file in question could be any of the required sizes. While it’s likely that you included them, the problem could be a simple naming error. Apple provides a couple of different ways to specify your icon names, but the simplest way is to follow our Project Build Settings guide carefully, adhering to the file names listed under Custom App Icons. Remember to name the icon image files exactly as listed, case sensitive, and include the example block of code in your build.settings file.

“This bundle is invalid. […] Do not submit apps using beta software.”

If you see this, you’ve some how chosen to build your app by selecting a beta test version of the iOS SDK from the Corona SDK build screen. We sometimes make these available to test with when a new version of iOS is almost ready to come out. The solution is to simply use the latest production iOS option from the option menu, if it exists (note that between new versions of iOS, we don’t allow you to pick the “wrong” iOS SDK).

“This bundle is invalid. New apps and app updates submitted to the App Store must be built with public (GM) versions of XCode 5.1.1 or higher and iOS 7 SDK. Do not submit apps built with beta software.”

Since the Corona SDK build servers use Xcode, we actually control this and it doesn’t impact your version of Xcode. Starting with Daily Build #2305 we switched to using Xcode 5.1.1 to build. At the time of this writing, this followed the latest public build (#2189), so we produced a new version of the latest public build, #2189a for Starter and Basic subscribers that builds correctly with Xcode 5.1.1. If you get this error, you should either build with a Daily Build later than #2305 or download and install #2189a.

“Your binary is not optimized for iPhone 5 – New iPhone apps and app updates submitted must support the 4-inch display on iPhone 5 and must include a launch image with the -568h size modifier immediately following the <basename> portion of the launch image’s filename.”

This one is simple. You must provide an image file in your root project directory named Default-568h@2x.png. This file must be 640 pixels wide and 1136 pixels tall, in .png format, oriented for portrait even if your app is designed for landscape orientation. See the Project Build Settings guide for more info.

“Improper Advertising Identifier [IDFA] Usage. Your app contains the Advertising Identifier [IDFA] API but you have not indicated its usage on the Prepare for Upload page in iTunes Connect.”

This one doesn’t generate an ITMS-9000 error and it can be frustrating. Apple has cracked down on the use of the IdentifierForAdvertisers feature in their SDK, and if you don’t have a business reason to use it, your app will get rejected. Before we discuss how to avoid this rejection, you need to understand what current Corona builds can and can’t do:

  • If you use ads (AdMob, iAds, etc.), there should be no issues.
  • If you use Facebook, you’ll have to check the correct checkbox to pass Apple’s tests. Facebook uses the IDFA for its tracking of “publishedInstalls” so we were forced to pull Facebook out of the Corona core (iOS only) in Daily Build #2169 and offer it as a plugin. If you’re building with an older version and you’re not using ads or Facebook, Apple will reject you. This includes the old Graphics 1.0 build #1262 which will now fail Apple’s requirement to build with Xcode 5.1.1.
  • If you don’t use either ads or Facebook, make sure you’re building with #2189a or later.

2) Dealing with IDFA Usage

Within iTunes Connect, when you’re ready to upload a new binary, you’ll be asked about encryption and ads.

If you do not use ads or Facebook, ensure that you select the No radio button as shown here.  NOTE: Apple’s iAds does not use the IDFA so you can select no if you’re only using iAds:


Otherwise, select Yes and then fill out the bottom half of the form:


  1. If you’re using ads, check the Serve advertisements within the app checkbox.
  2. If your app is being installed from some cross-promotion app or if you’re using Facebook, check the second box.
  3. Finally, check the Limit Ad Tracking setting in iOS checkbox.

3) Rejections by iTunes Connect

These are pretty straightforward. For example, you submitted a binary but you’re missing a screen shot or some other piece of metadata. Just fix the issue in iTunes Connect and you should be able to submit your binary without having to upload it again.

You might also get an email from Apple complaining about Push Notification entitlements, but this can be ignored.

4) Human Rejections

A few days after you submit your binary, an actual human reviewer will look at your app. Apple has multiple teams and some reviewers are more strict than others, but most rejections will be issued because of obvious bugs or content that Apple doesn’t allow, including adult content, websites “repackaged” as apps, low-quality apps, etc.

Note that if Apple rejects your app because of a bug, you should reply and attempt to get a “console log” to inspect. This may help you find where the error occurred.


Hopefully this article has explained some common reasons why your app may be rejected by Apple and how to resolve them so that your hard work can reach the marketplace. While Apple is constantly evolving and adjusting the submission rules and quality standards, we at Corona Labs will work hard to make sure that you can submit apps that Apple will accept.

Rob Miracle

Rob Miracle creates mobile apps for his own enjoyment and the amusement of others. He serves the Corona Community in the forums, on the blog, and at local events.

  • Jonsi
    Posted at 14:19h, 19 June

    Great summary! Really useful.

  • Ingemar
    Posted at 15:52h, 19 June

    If you *only* use iAd you must choose No for IDFA usage, otherwise you app will most likely get rejected as iAd does not use IDFA. There have been many reports from developers that have fallen in this trap by answering Yes.

    • Rob Miracle
      Posted at 15:53h, 19 June

      Good catch!

  • Alan
    Posted at 09:22h, 20 June

    We have had an app rejected for an ad related issue, which I think other developers should know about.

    Our game had an opt-in advert – users could watch a Vungle video advert to earn our in game currency. To us, this seemed like an ideal way to use adverts. The user only saw them after deciding they wanted to, so the gameplay experience was not interrupted by pop up ads or bannners. It seemed like a win/win situation, users would be more likely to engage with the adverts if they had chosen to view them, rather than having them forced upon them, and they were rewarded for doing so.

    The app was rejected for violating the following rule:
    3.10: Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the iOS Developer Program.

    Specifically, we were told that our app was manipulating the app store rankings by rewarding users for watching ads for other apps (e.g. more ads being watched = more downloads for that app).

    Others have had similar responses:

    We still haven’t wrapped our head around the logic of this decision, it seems to be at a detriment to all parties:

    User – cannot be shown incentivized ads, only ads which popup intrusively.
    Devs a – cannot make as much revenue via advertising.
    Devs b – cannot drive downloads by advertising their apps in other apps.
    Ad providers – do I need to explain this one?
    Apple themselves – less apps being downloaded would imply less money being spent in the app store.

    We’re going to try using brand ads instead – as these clearly don’t manipulate the app store.
    Looking forward to more clarity from Apple on the matter…

    • Ed Maurina
      Posted at 17:09h, 27 October

      I know this is an old post, but it is worth noting, that Rovio does exactly this for the game ‘Retry’

  • Nick
    Posted at 15:44h, 20 June

    Vungle got me rejected along with applovin (cocos2dx on that one) also more games button that shows apps that aren’t your own will nail you too.

    7 times for me now. Reward video = nope. Chartboost more games button = yes, if you link your own games.

    Don’t get nailed, people saying oh it’s fine bla lbs bla. No
    It’s not. 7 submissions under corona cocos 2dx and appcelerator.

    Just be aware and if you pay attention you’ll figure out how to get through review process


  • MAS1
    Posted at 00:51h, 21 June

    @Alan I use Vungle video ads in my iOS apps with incentives so I get where you are coming from.

    I also see Apple’s perspective. Ads + incentives = reduced IAP for Apple. Needs more coins? Don’t give Apple a cut with IAP – just watch a video!

    Also Devs B does not apply.

  • nick
    Posted at 11:34h, 23 June

    “Devs b – cannot drive downloads by advertising their apps in other apps.”

    This is FALSE. You can use “more apps” button, just show your own games. I got through approval process, I have “free games” and “more games” which one shows my free games and one shows my paid and free games.

  • Alan
    Posted at 07:57h, 30 June

    I should have been more clear with the “devs b” bit.
    What I meant is, if I only have 1 game and I want it to be advertised in other developer’s games, I can no longer do that.

  • Tiffany
    Posted at 12:30h, 02 July

    This is useful because it confirms what I thought was probably the issue. Unfortunately, I’ve been unsuccessful in fixing it. I get the “The bundle [bundle name] at bundle path [bundle path] is not signed using Apple submission certificate.” error and I’m definitely using distribution instead of development, I’ve re-downloaded the certificates and provisioning profiles and requested the certificate signing request. I’m able to build the files from the Corona Simulator but using the Application Loader is where it falls apart. I feel like I need someone to look at the Keychain Access and my list of certificates to make sure what on earth I could be doing wrong or leaving out because I’m at my wits end with it. I’m trying Apple Support but thought I’d try here as well.

    • Rob Miracle
      Posted at 13:03h, 02 July

      Tiffany, I would suggest you ask about this in the forums. Perhaps you could post some screen shots from Keychain Access and someone might be able to point you to the issue.


      • Tiffany
        Posted at 13:25h, 02 July

        Will do. Thx!

  • Jenny
    Posted at 05:35h, 10 September

    I have built my app in xcode 5.1.1 and ios 7 SDK but the app got rejected saying the reasons as xcode version and ios SDK.??? Can any one help me with this?

    • Rob Miracle
      Posted at 06:06h, 10 September

      Please make sure you have downloaded the latest build of CoronaSDK (2393a) from the downloads page. This was fixed a couple of weeks ago. The original 2393 or any build before that (or daily builds before 2404) have this issue.

  • Kumar Das
    Posted at 06:09h, 15 October

    Please help me out here….Yesterday my app was rejected by Apple. They asked me to respond to the following questions – Text inside {…} are mine

    1. Does the app require users to agree to terms (EULA)?
    {It does not, should I ask my users to go through this ? This will require a new binary}

    2. Does the app use moderators to remove offensive users?
    {It does not, but we have a web-based Admin panel which enables admins to do this}

    3. Does the app have a mechanism for users to flag objectionable content and report users generating this content? If so, where is that mechanism located?
    {It does not, but we have a web-based Admin panel which enables admins to do this}

    4. Does the app’s chat feature have a flagging mechanism?
    {It does not, but users can terminate a chat-session}

    Any suggestions will be greatly appreciated.
    Thanks in advance


    • Rob Miracle
      Posted at 08:49h, 15 October

      For #1, if your app does not require it, simply tell them that. However, for a multi-user app where people are interacting with each other and there may be moderation going on, having an End User License Agreement isn’t a bad thing to have. Spell out the rights and responsibilities and expected behavior for the community. This is really for your benefit as much as it is the customers.

      For #2, your app does use moderators. Maybe not physically through the app, but you are doing moderation. I would say the answer to that is yes, but explain it’s done through the admin tool.

      For #3, they are asking if the app users can flag things which it sounds like they cannot. This is a feature that if I were the app’s user I would want to have. Admins flagging content is kind of silly. Who are they flagging it for? They are already seeing it. Flagging is the act of reporting that content to the admin so the admin can deal with it. Admins reporting to admins doesn’t make much sense. If you don’t want to provide this, simply tell them the truth that it doesn’t. But you should consider supporting it.

      For #4, you can explain your answer and that should be good, but again, if a user is being abusive and someone can end the chat, shouldn’t an admin be made aware of the abusive chat? Providing reporting for this too would be beneficial.


  • Nandu kumar
    Posted at 00:56h, 08 December

    Hi, I am facing an issue with IDFA when I am submitting my app to itunes connect.
    I have included ads with my app 1.0 version. Working fine with this. I wanted to remove ads for my app 1.1 version. I removed the code for showing ads and when I am submitting for review. If I select NO for IDFA It is showing something like this.

    “””Your app is using the Advertising Identifier(IDFA). You must either provide details about the IDFA usage or remove it from the app and submit your binary again.”””

    Any one facing the same issue. Please help me to solve this issue.
    Thank you.