Whether you’re a beginning iOS developer or a seasoned pro, you’ve no doubt encountered an App Store rejection at one point in your career (and if you haven’t, then you must be a very lucky person).

In this article, I’m going to discuss some of the top reasons that apps get rejected on the App Store. Many of the rules that governed the App Store in the early days have changed and continue to be refined as Apple gauges their impact. A prudent developer always keeps an eye on the latest changes.

Don’t forget that for a more lighthearted approach to reading through the App Store review guidelines, you can download the comic book version that was distributed in 2016 at WWDC. In each of the sections below, we’ll reference the review guideline that’s the reason for the rejection.

Your App is a Joke

4.3 Spam - Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, and Kama Sutra apps already. Spamming the store may lead to your removal from the Developer Program.

A few years ago, Apple began requiring that all apps being submitted for the App Store provide some sort of lasting value for the end user. This means that apps like flashlight apps, fart apps, and other apps like these would be rejected because they do not provide lasting value to the user.

Before submitting your apps to the store, ensure that they do provide some type of value to the user and that you’re not trying to enter a saturated category where there are plenty of other apps. You can do this by bundling features from multiple similar apps into a single app, as Apple suggests in the review guidelines.

Apps that don’t follow API guidelines or use private APIs

2.5.1 Software Requirements - Apps may only use public APIs and must run on the currently shipping OS. Learn more about public APIs. Keep your apps up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of an OS.

Private APIs are marked ‘private’ for a reason. Use them and your app will be rejected. Many developers have tried (and failed) to get around this in various ways, but Apple always finds out sooner or later. Using Apple’s private APIs is a very bad idea because those APIs may not be stable between iOS updates.

It is also important to always follow the guides and Human Interface Guidelines (lovingly referred to as ‘the HIG’) for the technology you’re implementing. Newer Apple frameworks like AVKit’s camera access, microphone access, iCloud, HomeKit, HealthKit, and more require special items in your Info.plist.

Take HealthKit: One requirement is a privacy policy viewable by all users to view both within the app and in the App Store listing. This requirement and others like it can only be known if you read all of the documentation for the technology you’re implementing.

Adult Content, But Rated ‘G’

1.1 Objectionable Content - Apps should not include content that is offensive, insensitive, upsetting, intended to disgust, or in exceptionally poor taste

Apple requires that all developers list the rating of their app in order to help lock out certain apps using parental controls for content on the App Store and iTunes Stores. When selecting ratings on iTunes Connect, ensure it is indicative of all the content accessible in the app. This is one of the easiest ways to get rejected – if your app has inappropriate content then Apple will request that you change the rating or remove the objectionable content.

Under Construction

2.1 App Completeness - Submissions to App Review should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission. Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login. If you offer in-app purchases in your app, make sure they are complete, up-to-date, and visible to the reviewer, or that you explain why not in your review notes. Please don’t treat App Review as a software testing service. We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.

A few years back, Apple began cracking down on apps that didn’t include full functionality as advertised and instead posed as “lite” or “demo” apps. The proper way to handle this is by allowing users to download your app with limited access, but then allow upgrades to additional features with In-App Purchases. Without providing a way to unlock the full access to the app, Apple will almost certainly reject the app.

Every Multi-Touch you make, I’ll be watching you

iOS provides an advertising identifier for apps that require a way to identify users for the purpose of serving up ads. Of course, you can utilize this identifier inside of your app without the need for specifically calling it out in Info.plist. However, upon App Store submission, you’re required to tell App Review whether or not your app uses this identifier. It’s a checkbox whenever you submit a new binary to the store and it’s required to tell them either Yes or No that the app uses the identifier.

If Apple finds out you’re using the identifier without letting them know about it, then they will reject the app since it can violate many App Store guidelines and privacy laws surrounding advertising to young audiences.

Picture vs Reality, #noFilter

2.3 Accurate Metadata- Customers should know what they’re getting when they download or buy your app, so make sure your app description, screenshots, and previews accurately reflect the app’s core experience and remember to keep them up-to-date with new versions.

When listing your app, you must always ensure that the screenshots are of the app that is submitted and that the information posted in the App Store listing correct. Marketing language which touts your app as ‘the best thing since sliced apps’ is fine, but lying about features and capabilities is not. If you provide inaccurate or incomplete information in the listing, then it’s almost guaranteed that your app will be rejected during the review process.

Missing demo account info

Provide an active demo account and login information, plus any other hardware or resources that might be needed to review your app (e.g. a sample QR code)

If your app has an account creation process, then Apple requires that you create a demo account that can be used to test the app during the review process. This account information can be passed along during the app setup process in iTunes Connect.

By not providing the information, Apple may contact you directly during the review process to get the information, which will delay the entire review process.

Cory Bohon

Cross Platform Engineer

MartianCraft builds world class apps for the biggest brands in the world, and the most passionate entrepreneurs. We'd love to help bring your mobile ideas to reality. Get in touch.