App Store rejection reasons and how to avoid them

Most App Store rejections are not about taste. They cite a small set of guidelines: the app crashed, a login had no demo account, a purchase bypassed in-app purchase, a social login lacked Sign in with Apple, or there was no way to delete an account. This guide lists the common rejection reasons by guideline number, what reviewers actually check, and a review-readiness task your AI beta tester can run on the build before you press Submit.

Who it’s for

  • iOS developers submitting a first app or a major update
  • Founders who were just rejected and need to understand the notice
  • Cross-platform teams whose iOS build has not been through review before
  • Product managers planning a release date around App Review

Updated 2026-10-25.

Why apps get rejected

App Review checks every submission against the App Store Review Guidelines. The rejection notice in App Store Connect quotes the guideline number and usually includes a screenshot or a sentence about what the reviewer saw. The majority of rejections come from a handful of guidelines, and almost all of them can be caught by testing the exact build you plan to submit, on a device, with a fresh install and the reviewer's eyes.

Apple updates the guidelines several times a year. The numbers below are stable as of this writing, but always verify the wording against Apple's current text before you rely on it.

The most common rejection reasons by guideline

2.1 App Completeness

The single most common rejection. It covers crashes on launch, bugs the reviewer hit during testing, placeholder content ("Lorem ipsum", "Coming soon"), broken links, and a login screen with no working demo account. The reviewer tests on a real device, often an iPad even when you only target iPhone, over a normal network. If anything blocks them, they stop and send 2.1.

Fix: install the submitted build clean on a device, go through every screen, and give App Review a demo account in the review notes that works on the first try.

2.3 Accurate Metadata

Screenshots that show features the build does not have, a description that mentions another platform, a title with keywords stuffed in, or hidden features that only appear with a special code. Screenshots also have to come from the app itself, in the right device size.

Fix: compare each screenshot and sentence in the listing against what the build really does.

3.1.1 In-App Purchase

Digital content, features and subscriptions unlocked inside the app must use in-app purchase. Reviewers look for links or buttons that send users to a website to pay, promo codes that unlock paid content, or a subscription sold through a third-party processor. The rules about linking to external payment options have changed and differ by region and entitlement, so read the current text for your storefronts rather than relying on a blog post.

Related: 3.1.2 Subscriptions requires the price, billing period, and what the user gets to be clear before purchase, plus a working Restore Purchases option.

4.8 Login Services

If the app offers a third-party or social login (Google, Facebook, X and so on), it must also offer Sign in with Apple or an equivalent login that limits data collection, lets users hide their email, and does not track them. Apps that only use their own email and password system, or only enterprise, education or government identity systems, are exempt. See the Sign in with Apple guide for the exact exceptions.

5.1.1(i) Privacy Policy

A privacy policy link is required in the App Store Connect metadata and inside the app. Reviewers tap it. A 404, a placeholder page or a policy for a different product is a rejection.

5.1.1(v) Account Deletion

Apps that support account creation must let users start account deletion from within the app. A link to a support email or a request form is not enough except in narrow cases such as highly regulated industries. Deactivation is not deletion. Confirmation steps and a short grace period are acceptable if the account is actually deleted afterwards.

5.1.2 Data Use and Sharing

If the app tracks users across other apps and websites, it must show the App Tracking Transparency prompt before tracking and keep working when the user declines. The privacy labels (nutrition labels) you fill in for the listing must match what the app and its SDKs really collect. Reviewers compare analytics and ad SDKs against your declarations.

4.2 Minimum Functionality and 4.0 Design

Web pages wrapped in a native shell, apps that are only a marketing page, or apps that are mainly a repackaged website without native value get 4.2. Apps with layouts that are clearly not designed for iPhone, for example a stretched Android layout, can get 4.0.

What reviewers actually do

  • Install the build on a fresh device, not an upgrade.
  • Read the review notes and try the demo account first.
  • Tap every tab and most buttons, including Settings, legal links and support.
  • Trigger permission prompts and check the purpose strings make sense.
  • Start a purchase flow and look at where the money goes.
  • Compare the screenshots and description with what they see.

They have limited time per app. If the demo account fails or the first screen crashes, you get the rejection without any of the rest being tested.

How to test before you submit

  1. Export the exact build you will upload and install it clean on a device or send it to your AI beta tester.
  2. Create a dedicated review account with realistic data that never expires, and write its credentials into the review notes.
  3. Walk every screen as a stranger: no placeholder text, no dead links, no "beta" labels or debug menus.
  4. Tap the privacy policy, terms and support links from inside the app.
  5. Check Sign in with Apple is offered next to every social login and actually works.
  6. Find account deletion in under a minute from the main settings screen and complete it with a throwaway account.
  7. Run every purchase and restore flow with a sandbox account.
  8. Open the listing side by side with the app and check every screenshot and claim.

Example review-readiness finding

Title: Privacy policy link in Settings opens a 404 page
Guideline at risk: 5.1.1(i) Privacy Policy
Environment: iPhone 15, iOS 18.1, build 1.0.0 (34), clean install
Severity: High (common 2.1 / 5.1.1 rejection trigger)

Steps to reproduce:
1. Open Settings tab.
2. Scroll to Legal and tap "Privacy policy".

Expected: The privacy policy page opens in an in-app browser.
Actual: Safari view shows "404 Not Found" at example.com/privacy-policy.
The App Store Connect metadata links to example.com/privacy, which works.

Evidence: screenshot of the 404 page.

After a rejection

  • Read the full message in the Resolution Center. The guideline number tells you the category; the text and screenshot tell you the exact trigger.
  • If the reviewer misunderstood something, reply in the Resolution Center with precise steps and the demo credentials instead of resubmitting unchanged.
  • If you believe the decision is wrong, you can submit an appeal to the App Review Board. Appeals take time, so fix what you can in parallel.
  • Resubmitting with a fix is usually faster than arguing. Keep your reply factual and short.
  • Record the reason in your release checklist so the same rejection does not come back next version.

How an AI beta tester helps

betatest.ing's Store readiness tests run the App Store review checklist on your uploaded .ipa on a real iPhone: clean install, every screen, demo login, legal links, permission prompts and purpose strings, Sign in with Apple next to social logins, the account deletion path, and purchases in the sandbox only. Each problem comes back as a finding with the guideline it risks, steps to reproduce, severity, an annotated screenshot and a recording where a flow breaks, plus a scored report. It does not replace App Review or legal advice, but it catches the obvious 2.1, 4.8 and 5.1.1 rejections before Apple does.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Run an App Store review-readiness check on my iOS app [UPLOADED .IPA OR PUBLIC APP STORE LINK] on a real iPhone. It is [WHAT THE APP DOES]. Install it clean and behave like an App Review reviewer: use the saved demo login, open every tab and settings screen, and tap every legal, support and external link. Flag anything that would risk a rejection and name the guideline: crashes, bugs, placeholder text or debug menus (2.1); privacy policy link missing or broken (5.1.1(i)); social logins without Sign in with Apple (4.8); no in-app account deletion or deletion that only deactivates (5.1.1(v)); paid digital content sold outside in-app purchase or a missing Restore Purchases option (3.1.1, 3.1.2); permission or tracking prompts without clear purpose text (5.1.2). Compare the app against the store listing [APP STORE LISTING URL OR 'skip'] for screenshots or claims that do not match (2.3). Do not make any purchases. Log each issue as a finding with the guideline, steps to reproduce, severity and an annotated screenshot, record flows that break, and end with a report that scores review readiness with the top fixes before submission.

Fill in your details

Here, or later in the chat with your tester.

  • [UPLOADED .IPA OR PUBLIC APP STORE LINK] "the uploaded .ipa" for an unreleased build, or the App Store link of the current version
  • [WHAT THE APP DOES] One sentence about the app and who it is for
  • [APP STORE LISTING URL OR 'skip'] Your public listing to compare against, or skip for a first submission

What the AI beta tester checks

  • Clean install, launch and demo login with the saved test account
  • Crashes, dead buttons, placeholder content and debug menus (2.1)
  • Privacy policy, terms and support links from inside the app (5.1.1(i))
  • Sign in with Apple offered next to third-party logins (4.8)
  • In-app account deletion present, findable and real (5.1.1(v))
  • Purchases through in-app purchase, clear subscription terms, Restore Purchases (3.1.1, 3.1.2)
  • Permission and tracking prompts with clear purpose strings (5.1.2)
  • Store listing screenshots and claims match the build (2.3)
  • Layouts designed for iPhone sizes, nothing under the notch or home indicator

What you get

  • Findings tagged with the App Store guideline each one risks
  • Steps to reproduce, severity and annotated screenshots for every issue
  • Recordings of flows that crash or block the reviewer
  • A review-readiness score and the top fixes before submission

How to run it with betatest.ing

  1. Add your app as a project in betatest.ing and upload the .ipa you intend to submit (ad-hoc, development or enterprise export).
  2. Save the demo account you will give App Review as the project's test login.
  3. Send the review-readiness task; the tester runs it on a real iPhone.
  4. Fix the flagged items, upload the new build and re-run before submitting.

Tips

  • Test the exact build you will upload; a different scheme or environment hides bugs the reviewer will see.
  • Write review notes with the demo login, how to reach gated features, and anything that needs hardware you cannot ship.
  • Keep the privacy policy URL identical in App Store Connect and inside the app.
  • If a feature needs a real account (bank, employer), explain it and provide a video in the notes.
  • Re-read the current guideline text for 3.1.1 and 5.1.1 before each submission; they change.

App Store rejection reasons: FAQ

What is the most common App Store rejection reason?

Guideline 2.1 App Completeness: crashes, bugs the reviewer hits, placeholder content, broken links, or a login with no working demo account. Almost all of it is caught by installing the submitted build clean on a device and walking every screen.

How do I know which guideline I was rejected under?

The message in App Store Connect's Resolution Center quotes the guideline number and section, often with a screenshot. The number identifies the category; the text identifies the exact trigger, so read both before fixing anything.

Do I need Sign in with Apple?

Only if you offer a third-party or social login such as Google or Facebook. Apps with just their own email and password system, or only enterprise, education or government logins, are exempt under guideline 4.8. Check Apple's current text for the full list of exceptions.

Is a 'contact support to delete your account' link enough?

Usually not. Guideline 5.1.1(v) expects users to be able to start deletion inside the app. Apple allows directing users to a website only in limited cases, and deactivation does not count as deletion.

Can I link to my website to sell a subscription?

Digital content and subscriptions used inside the app must be sold through in-app purchase under 3.1.1. Rules about links to external payment options have changed and differ by region and entitlement, so verify the current guideline for the storefronts you sell in.

What should I put in the review notes?

A working demo login that does not expire, how to reach any gated or location-dependent features, which permissions matter and why, and a short explanation of anything the reviewer may not understand without context. A video link helps for hardware-dependent features.

Can an AI beta tester predict an App Store rejection?

It can catch the common, testable triggers: crashes, broken links, missing demo access, missing Sign in with Apple, no account deletion, purchases outside IAP and unclear permission prompts. It cannot guarantee approval; App Review makes judgment calls that no tool can predict.

How long does a rejection delay the launch?

Each resubmission goes back through review, and appeals take longer than a resubmission. Plan a buffer of several days between your first submission and any announced launch date, and fix rejections rather than arguing when the fix is quick.

Related beta testing guides

  • Google Play rejection reasons — Google Play rejections tend to be about declarations more than design: a Data safety form that does not match what the app collects, a missing account deletion link, an undeclared sensitive permission or an outdated target API level. This guide lists the common rejection and removal reasons, what to fix for each, and a Play policy check your AI beta tester can run on the build before you submit it for review.
  • Sign in with Apple requirement — If your iOS app offers Google, Facebook or any other third-party login, App Store guideline 4.8 expects Sign in with Apple or an equivalent privacy-focused option too. This guide explains when the rule applies and when it does not, the parts of the flow that break most often (Hide My Email, missing names, revoked credentials, account linking), and a test task your AI beta tester can run on a real iPhone.
  • In-app account deletion requirement — Both app stores require apps that let users create an account to let them delete it, inside the app, for real. It is one of the most common reasons an otherwise finished app gets rejected. This page explains what Apple and Google require, how grace periods, data export and subscriptions fit in, and what to test so the deletion flow passes review and actually works.
  • In-app purchase testing — In-app purchases are the flow you can least afford to ship broken and the one teams test least, because nobody wants to pay real money on every build. This guide covers how the Apple and Google sandboxes work, which subscription states to test, and a task your AI beta tester can run against your paywall without ever completing a real purchase.
  • iOS app beta testing — TestFlight is how almost every iOS app gets into beta testers' hands before the App Store. This guide explains how TestFlight testing works, what to check on iPhone that differs from Android, and how to run an AI beta test on a real iPhone from an uploaded .ipa build.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in guides