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:
- Automatically when you upload the app with Application Loader
- Due to IDFA usage
- Via iTunes Connect
- 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
“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
Defaultemail@example.com. 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:
- If you’re using ads, check the Serve advertisements within the app checkbox.
- If your app is being installed from some cross-promotion app or if you’re using Facebook, check the second box.
- 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.
Posted by Rob Miracle. Thanks for reading...