App Store review guidelines: why apps get rejected and how to avoid it

By Sigsten Gustavii· 26 October 2026· 8 min read

Every app on the App Store is looked at by a person at Apple before it goes live. That person checks it against the App Store Review Guidelines, a long public document, and either approves the app or sends it back with the guideline it failed and a note. Apple says that on average 90% of submissions are reviewed in less than 24 hours, so a rejection usually costs you a day or two, not weeks. It still stings, and most of the time it could have been avoided.

This guide walks through the guidelines that catch people out most often, what each one asks in plain words, and how to check your app against it before you press submit. Apple's guidelines are the authority; we quote their numbers and summarise, and you should read the full text for anything you are unsure about.

How App Review works

1. You upload a build to App Store Connect and fill in the listing: name, description, screenshots, privacy answers, age rating and review notes.
2. You submit it for review. A reviewer installs the app, opens it and tries what it says it does.
3. If it passes, it is approved and you choose when it goes live. If not, you get a message naming the guideline and what was wrong.
4. You fix the issue, upload a new build if the app changed, reply in App Store Connect and resubmit.
5. If you think the reviewer got it wrong, you can reply with an explanation or appeal to the App Review Board.

The guidelines that most often send apps back

2.1 App Completeness

App Completeness is on Apple's own list of common issues, and it is simple: the app is not finished. A button that does nothing, a screen that says "coming soon", placeholder text, a crash on a certain tap, a link to a page that does not exist. Reviewers also need to get in: if the app has accounts, give them a working demo login in the review notes, or make sure they can sign up.

2.3 Accurate Metadata

Your listing has to describe the app the reviewer is holding. Screenshots must show the app in use, the description must not promise features that are not there, and the name and keywords must not borrow other apps' names. If you change the app, check the screenshots still match.

4.2 Minimum Functionality

Apple asks for apps that are more than a repackaged website, with features and content that make them useful and "app-like". A web page inside a frame, a single static screen or a list of links is likely to be turned down here. Native apps that use the iPhone's own features, like the camera, Face ID or reminders, have a much easier time.

4.3 Spam

Apple turns down apps that duplicate others, including many versions of one app from the same developer. An app made from a common idea is fine; an app that is indistinguishable from dozens of others is not. Give it its own purpose, content and name.

5.1.1 Data Collection and Storage

Every app needs a privacy policy link, and its App Privacy answers in App Store Connect have to match what the app actually collects. Each permission the app asks for, like the camera or location, needs a clear reason shown to the person. And under 5.1.1(v), if people can create an account in your app, they must be able to delete it from inside the app, not only sign out.

3.1.1 In-App Purchase

Digital things sold inside an app, such as premium features, subscriptions or content, must be sold through Apple's in-app purchase. Physical goods and real-world services are different. If you sell something a buyer keeps, like an unlock, include a way to restore purchases; for subscriptions, guideline 3.1.2 asks you to show the price, the period and the renewal terms before anyone subscribes.

4.8 Login Services

If your app offers sign-in through a third-party or social service, such as Google, Apple asks you to also offer an equivalent login option that meets its privacy requirements; Sign in with Apple is the usual answer. Email and password sign-in of your own is not a third-party service.

How to check your app before you submit

Step 1: Walk through it as a reviewer

Install the app on a phone or open it in a simulator, with no data, as someone who has never seen it. Sign up, use every feature once, sign out and sign back in. Our guide to testing an iPhone app without an iPhone has a checklist for this.

Step 2: Clear sample content

AI builders often fill a new app with example rows so it looks alive while you build. Replace them with real content or clear them before you submit, or a reviewer may read them as placeholders.

Step 3: Check privacy and account deletion

Open the privacy policy link. Check every permission prompt has a clear reason. If there are accounts, delete a test account from inside the app and confirm it is gone.

Step 4: Write useful review notes

Review notes are your chance to talk to the reviewer. Explain anything that is not obvious and give a demo login. Keep it short:

Thank you for reviewing [app name].
What it does: [one sentence].
Demo account:
Email: [demo email]
Password: [demo password]
Where to find things:
- [Main feature]: [where it is]
- Delete account: Settings > Account > Delete account
- [Purchases, if any]: [where they are, and how to restore them]
Permissions: the app asks for [camera / location] to [reason].

Step 5: Match the listing to the app

Take fresh screenshots of the build you are submitting, and reread the description against the app.

A short checklist before you press submit

• Every button does something, and nothing says "coming soon".
• A demo login is in the review notes, and it works.
• Delete account exists inside the app, if the app has accounts.
• The privacy policy link opens, and the App Privacy answers match what the app collects.
• Each permission prompt says clearly why the app needs it.
• Digital purchases go through in-app purchase, with a way to restore them.
• Screenshots and the description match this build.
• Sample or test content is gone.

Going through this list takes ten minutes. A rejection and resubmission takes at least a day, and usually more of your attention than that.

How Borel helps you pass review

On Borel Pro, from $20 a month, the Publish card has Run review, a check of your app for App Review risks before it goes to Apple. Borel builds the exact version on its Mac and opens it, reads the code for what Apple asks of every app (a reason for each permission, privacy answers that match, no placeholder text, no secret keys), and checks the rules Apple most often turns apps down for, such as account deletion, Sign in with Apple, enough of an app, nothing unfinished, restoring purchases and subscription terms. The Ready for Apple page lists each one.

A clean check lowers the chance of a rejection; it never promises approval. Only Apple decides, and its reviewers can ask for changes no check foresaw. When they do, describe the fix in the chat, send a new build from Publish and resubmit. The full flow is in how to publish an app to the App Store without a Mac.

Common mistakes that lead to rejection

• Submitting with sample data still in. It reads as placeholder content.
• No demo login. If the reviewer cannot get past the sign-in screen, the review ends there.
• A Sign out button but no Delete account. Guideline 5.1.1(v) asks for both when accounts exist.
• Selling digital features through a web checkout. Use in-app purchase.
• Screenshots from an older version. They have to match the build under review.
• A website in a wrapper. Build the app natively, or give it features a web page does not have.
• Enrolling in Apple's Developer Program at the last minute. It costs $99 a year and can take time to approve for organizations.

If your app is rejected anyway

Read the message carefully: it names the guideline and usually what the reviewer saw. Fix exactly that, mention the fix in your reply, and resubmit. If you disagree, reply calmly with an explanation, or appeal to the App Review Board. Most rejections are a short detour, not a dead end. For testing with real people before you submit again, see TestFlight explained.

A rejection feels personal, but it is usually one missing detail. I would fix the one thing Apple names, reply politely and send it again.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.