The App Store rejection checklist: 12 things to test before you submit
App Store rejection checklist with guideline numbers: account deletion, Sign in with Apple, in-app purchases, privacy labels and crashes to test first. By betatest.ing team · October 16, 2026 · 7 min read.
Key takeaways
- Guideline 2.1 (completeness, crashes, demo account) is the most common rejection; test the exact release build on the oldest supported iOS and on iPad if enabled.
- Account deletion must be in-app and real (5.1.1(v)); Sign in with Apple or an equivalent is required when you offer third-party login (4.8).
- Digital goods need In-App Purchase with a working Restore (3.1.1) and clear subscription terms (3.1.2); test purchase, reinstall and restore in the sandbox.
- Privacy labels and the policy must match every SDK you ship (5.1.1, 5.1.2); purpose strings must explain why and appear in context.
- Metadata (2.3) and minimum functionality (4.2) are judgment calls automation cannot make; everything else on the list can be re-run on every build.
In this article
- 1. The app launches and the core flow works (Guideline 2.1)
- 2. A working demo account is in App Review Information (Guideline 2.1)
- 3. Account deletion is available in the app (Guideline 5.1.1(v))
- 4. Sign in with Apple is offered where it is required (Guideline 4.8)
- 5. Digital goods go through In-App Purchase (Guideline 3.1.1)
- 6. Restore Purchases works (Guideline 3.1.1)
- 7. Subscription terms are disclosed (Guideline 3.1.2)
- 8. The privacy policy and privacy labels match the app (Guidelines 5.1.1 and 5.1.2)
- 9. Permission prompts have purpose strings that make sense (Guideline 5.1.1(i))
- 10. No private APIs, no non-public entitlements (Guideline 2.5.1)
- 11. Metadata is accurate (Guideline 2.3)
- 12. The app does something an app should do (Guideline 4.2)
- Related guides
- Running the checklist without losing a week
App Review rejections are rarely mysterious. Most of them cite the same handful of sections in the App Store Review Guidelines, and most of those could have been caught by a tester with a checklist the week before submission. This is that checklist: twelve items, each with the guideline number to read, a concrete test, and the way teams usually fail it.
A note on how to use it: every item is written as something to actually do on a device with the release build, not something to assert in a meeting. If you cannot point to a screenshot or recording that shows the check passing, it has not been checked.
1. The app launches and the core flow works (Guideline 2.1)
Guideline 2.1, App Completeness, covers crashes, bugs, placeholder content and features that are not finished. It is the most cited rejection reason because it is the broadest.
Test: Install the exact build you will submit on an iPhone and, if you support it, an iPad. Cold launch. Complete the single most important flow end to end. Then do it on the oldest iOS version you declare as supported.
Usual failure: "Coming soon" screens, lorem ipsum, a feature behind a flag that is off in production, or an iPad layout nobody looked at because the app is "iPhone-first" but iPad is still enabled in the target.
2. A working demo account is in App Review Information (Guideline 2.1)
If your app requires login, the reviewer needs credentials. If the credentials do not work, or a code is sent to a phone you own, the review stops.
Test: Log out, then log in with exactly the demo credentials you entered in App Store Connect, on a fresh install. Confirm the account has representative data and that any second factor is disabled or routed somewhere the reviewer can see.
Usual failure: The demo account was reset by a database migration, or it is in a staging environment the release build does not point to.
3. Account deletion is available in the app (Guideline 5.1.1(v))
Apps that let users create an account must also let them initiate account deletion from inside the app. Apple's guideline 5.1.1(v) and its support article on account deletion describe what counts: deletion, not deactivation, and not merely a link to a support email.
Test: From a logged-in session, find the deletion option without help, trigger it, confirm, and then try to log in again. Check what happens to active subscriptions, which Apple says you must explain to the user.
Usual failure: The option exists only on the website, or it submits a "request" that goes to a mailbox with no confirmation.
4. Sign in with Apple is offered where it is required (Guideline 4.8)
Guideline 4.8, Login Services, requires that if your app uses a third-party or social login service, you must also offer a login option that limits data collection to name and email, lets users keep their email private, and does not track them. Sign in with Apple meets this, and so do some other services that meet the criteria. The requirement does not apply if you use only your own account system.
Test: On the login screen, count the options. If Google, Facebook or similar appear, confirm the compliant option appears with equal prominence. Complete a sign-up with it using Hide My Email and confirm the app works with the relay address.
Usual failure: Adding Google Sign-In late in the project and forgetting the obligation it creates.
5. Digital goods go through In-App Purchase (Guideline 3.1.1)
Guideline 3.1.1 requires In-App Purchase for unlocking features or content inside the app, and it forbids buttons or links that steer users to external purchase methods except where specific entitlements or regional rules apply. Rules in this area have changed in several regions, so read the current text and the entitlements that apply to you.
Test: Walk every path that mentions money. Each must either use StoreKit or fall under the exceptions for physical goods and services consumed outside the app (Guideline 3.1.3). Buy something in the sandbox and confirm the entitlement appears.
Usual failure: A "Manage subscription" link that opens a web checkout, or a reader app that does not have the entitlement.
6. Restore Purchases works (Guideline 3.1.1)
The same section requires a restore mechanism for non-consumables and subscriptions.
Test: Buy in the sandbox, delete the app, reinstall, tap Restore. The entitlement must return without a second charge. Test on a second device signed in with the same sandbox Apple ID.
Usual failure: The button exists but only re-checks a server record that was never written.
7. Subscription terms are disclosed (Guideline 3.1.2)
Auto-renewable subscriptions must clearly show the price, duration, what the user gets, and how to manage or cancel, and must link to your terms and privacy policy.
Test: On the paywall, read it as a stranger. Can you tell the price per period, the trial length if any, and when you will be charged? Is there a link to terms and a privacy policy that opens?
Usual failure: A trial that says "Free" in large type and the renewal price in small gray text that is cut off on an iPhone SE.
8. The privacy policy and privacy labels match the app (Guidelines 5.1.1 and 5.1.2)
Guideline 5.1.1 requires a privacy policy link in App Store Connect and in the app, and 5.1.2 governs data use and sharing. Separately, App Store Connect requires App Privacy details, the "nutrition labels", describing what your app and its SDKs collect.
Test: Open the privacy policy from the app. Then list every SDK in your build and check its collection against your App Privacy answers. Analytics, crash reporting and ad SDKs are the usual gaps.
Usual failure: Declaring "Data Not Collected" while shipping a crash reporter that collects device identifiers.
9. Permission prompts have purpose strings that make sense (Guideline 5.1.1(i))
Every protected resource you access needs a purpose string, and Apple expects the string to explain why, in terms a user understands. The prompt should also appear when the feature is used, not at launch.
Test: Trigger each permission prompt. Read the text. Deny it and confirm the app still works for everything that did not need it.
Usual failure: A default string like "This app needs camera access", or a prompt for location at first launch before the user has done anything.
10. No private APIs, no non-public entitlements (Guideline 2.5.1)
Apps may only use public APIs. Static analysis at upload catches most cases, but third-party SDKs can smuggle in private selectors.
Test: Upload to TestFlight and watch for warnings during processing. Keep SDKs on current versions.
Usual failure: An old analytics or attribution SDK.
11. Metadata is accurate (Guideline 2.3)
Screenshots must show the app as it is, the description must not claim features that are not there, and the age rating must match the content. Guideline 2.3.3 covers screenshots and 2.3.8 covers metadata generally.
Test: Put each screenshot next to the real screen on the release build. Check the keywords and description for mentions of platforms or features you do not have. Re-answer the age rating questionnaire honestly.
Usual failure: Screenshots from the last redesign.
12. The app does something an app should do (Guideline 4.2)
Guideline 4.2, Minimum Functionality, rejects apps that are a web page in a wrapper, a single-page marketing brochure, or that provide less than the website does.
Test: Compare the app with your website, feature by feature. If the app is strictly a subset with no native capability, expect questions.
Usual failure: A web view with a native tab bar.
Related guides
Running the checklist without losing a week
Twelve items, each needing a device, a sandbox account and a fresh install, is a day of careful work, and it has to be repeated when the build changes. Teams skip it, submit, wait, and then do the work after a rejection.
The repeatable parts can be automated. An AI beta tester can install the candidate build on hosted iPhones, complete the core flow, find and exercise account deletion, check the login options, run a sandbox purchase and a restore after reinstall, trigger every permission prompt and read the purpose strings, open the privacy policy link, and screenshot the paywall at the largest Dynamic Type size. betatest.ing does this as a Store readiness test category that reports what it found alongside your functional bugs, each with steps, annotated screenshots and a recording. What it cannot do is judge your age rating or decide whether your app clears Guideline 4.2; those stay with you.
For the wider pre-submission routine, see our iOS app beta testing guide, and use the beta testing checklist generator to turn these twelve items into a shareable list for your team.
Start for $1 and run a Store readiness pass on your release build before App Review does.
Related guides
Each ends with a test task you can send to your AI beta tester.
Keep reading
- Google Play rejections: the policies that catch indie developers — Play review checks forms as much as code. The policies that reject indie apps most often, what each one actually requires, and the test that proves you pass before you submit.
- AI mobile app testing: what an AI beta tester can and can't do on a phone — An AI beta tester on a phone sees the accessibility tree and the screen, taps, types, reads crash logs and records everything. It cannot be a real camera, notification or wallet. Here is the line.
- From beta to launch: how to decide your product is ready — "Ready" is a decision, not a feeling. Write exit criteria before the beta, measure against them at the end, and launch with a known-issues list instead of waiting for zero bugs.