App Store rejection 2.1 App Completeness: a release-build test plan before you resubmit (2026)

An App Store rejection under 2.1 App Completeness means the reviewer couldn't use your app the way a customer would. It might have crashed, shown placeholder content, blocked them at a login screen or hidden an in-app purchase. The fix is rarely a single line of code. Before you resubmit, run a short test plan on the release build, using a fresh install and the same credentials you give App Review. This post walks through that plan and shows how other developers fixed the same rejection.

What does App Store guideline 2.1 App Completeness check?

Guideline 2.1 checks that the build you submit is a finished, working app. It needs complete metadata, working links, a demo login, a live back end, and in-app purchases the reviewer can find and use.

Apple's App Review Guidelines split 2.1 into two parts. 2.1(a) says submissions "should be final versions with all necessary metadata and fully functional URLs included" and that placeholder text and empty websites should be removed. It also tells you to test on a device for bugs and stability, and to "include demo account info (and turn on your back-end service!) if your app includes a login." Apple "will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." 2.1(b) says in-app purchases must be "complete, up-to-date, visible to the reviewer and functional." If a configured purchase can't be found in the app, explain why in your review notes.

This rejection is common. Apple's Preparing for App Review page says: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more."

Why doesn't testing the debug build catch 2.1 problems?

A debug build doesn't run the way the reviewer's copy will. The reviewer installs a distribution-signed release build on a clean device, with no saved session and no debug shortcuts.

Your simulator is already signed in. Your local API may point at a staging server that never goes down. Debug flags skip the paywall, and feature flags default to on. The reviewer gets none of that. Apple's review page also asks you to "thoroughly test on devices running the latest software," so the reviewer may be on a newer iOS than your test phone.

TestFlight is the closest you can get to the reviewer's setup. According to the TestFlight overview, you can add up to 100 internal testers from your App Store Connect team and up to 10,000 external testers. You can test a build for up to 90 days. Upload the exact build you plan to submit, install it from TestFlight on a device that has never run the app, and test that copy.

What should a release-build test plan cover before you resubmit?

A release-build test plan checks every way a fresh reviewer can get stuck: launch, permissions, login, back end, content, links, purchases, network failures and iPad. Run the steps in order on the TestFlight build and note each result so you can quote it in your review notes.

1. Clean install on the latest iOS. Delete any previous copy, install from TestFlight and launch with no saved state. Cold-launch three times and confirm onboarding doesn't crash.
2. Deny every permission prompt once. Turn down notifications, location, camera and tracking. The app should still reach a usable screen. Also confirm Info.plist has a usage description for every protected resource the app or its SDKs use.
3. Sign in with the exact demo credentials. Copy them from App Store Connect, not from your password manager. The account should have realistic data, should not need email verification, and should not use two-factor authentication tied to your own phone.
4. Confirm the back end is production and live. The build must point at production endpoints. Rate limits, IP allowlists and geo-blocking must not lock out a reviewer. Guideline 2.1(a) tells you to turn on your back-end service.
5. Walk every tab and screen. Look for lorem ipsum, "Coming soon" screens, empty states with no explanation, test images and buttons that do nothing.
6. Tap every link. That includes privacy policy, support, terms and any web views. Apple says "A link to user support with up-to-date contact information and a link to your privacy policy is required for all apps."
7. Open every in-app purchase. Sign in as a new account. Check that each product submitted with the version appears with a price, can be bought in the sandbox, and that Restore Purchases works.
8. Test on a slow or broken network. Switch on airplane mode partway through a flow. A clear error message is fine. A spinner that never stops, or a crash, is not.
9. Check iPad if you support it. If the app runs on iPad, launch it there and make sure the layout doesn't trap the user.

The demo account in step 3 causes more repeat rejections than any other step. Our guide to setting up an App Store review demo account covers how to build one that lasts.

How do you map a 2.1 rejection message to a fix?

To map a 2.1 rejection to a fix, read the sentence after the guideline number. It names the symptom, and each symptom points to one step in the test plan.

Suppose a habit-tracking app is rejected with the message "We were unable to review the app because it crashed on launch." A second note says the reviewer could not locate the in-app purchases. The table below matches common symptoms to a cause, a test and a fix.

For a broader method of reading any rejection message, see App Store rejection: how to fix it, guideline by guideline.

What did other developers' 2.1 rejections look like?

Public 2.1 cases follow the same pattern. The app works on the developer's setup and fails for the reviewer because of something only a fresh install or a stranger's login would expose.

• Crash from a missing usage description. On the Solar2D forums, a developer was told "We were unable to review the app because it crashed on launch" on an iPhone 13 mini running iOS 18.3.2, even though the app ran in TestFlight. Another member found this in the attached crash log: "This app has crashed because it attempted to access privacy-sensitive data without a usage description." The developer reported, "It passed after adding : NSUserTrackingUsageDescription."
• Social logins the reviewer couldn't use. A developer on the Apple Developer Forums reported repeated 2.1 rejections because reviewers "were unable to use social logins." They had supplied Apple and Google demo accounts, but the Apple ID sign-in needed a verification code sent to the developer's phone. Apple staff replied that App Review would contact them directly. No public fix was posted.
• In-app purchases "could not be found in the submitted binary." In a RevenueCat community thread, a developer was rejected because a monthly plan wasn't found in the binary, even though sandbox purchases worked. One helper said a similar rejection was resolved by replying with a detailed walkthrough and screenshots of every path to the paywall. RevenueCat staff advised showing every submitted product on the default paywall and keeping StoreKit test files out of the Archive scheme.

In all three cases the developer's own testing passed. The failure only appeared from a reviewer's starting point, with no 2FA phone, no prior session and no knowledge of where the paywall was. That starting point is what the test plan above recreates.

What should App Review notes say after a 2.1 rejection?

Review notes after a 2.1 rejection should give working demo credentials, list what changed since the rejected build, and say exactly where to find in-app purchases and any non-obvious features.

Apple's review page says to put account details and special configuration in the App Review Information section. If a feature needs hardware or an environment that's hard to set up, "be prepared to provide a demo video or the hardware." Guideline 2.3.1(a) adds that new features must be described "with specificity" in the Notes for Review, and that "generic descriptions will be rejected." A short, structured note works well:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

If legal or security obligations rule out a demo account, guideline 2.1(a) allows a built-in demo mode, but only with prior approval by Apple, and that mode must show the app's full features and functionality. Don't switch to a demo mode without that approval.

How do you resubmit or appeal a 2.1 rejection?

To resubmit after a 2.1 rejection, upload or select the build you tested, reply to App Review in App Store Connect with what you changed, update the review notes and submit again. Appeal only if you believe the reviewer misunderstood the app.

1. Check that the build number attached to the version in App Store Connect matches the TestFlight build you tested.
2. Reply to the rejection message with a short summary of each fix. For a purchase or navigation issue, add step-by-step directions and screenshots.
3. Update the App Review Information section with current credentials and notes.
4. Submit for review. As of October 2026, Apple says it typically reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours."

If you believe Apple got it wrong, the App Review page lets you appeal to the App Review Board. Give specific reasons why the app complies, and "Submit only one appeal per submission that didn't pass review." For a 2.1 rejection, though, reproducing the problem on a clean device is usually faster than arguing. If you'd rather hand the resubmission off, our App Store submission service covers review preparation and rejection feedback for both stores for $599, with developer account fees separate.

2.1 problems often come back in later updates: a new feature flag, a rotated API key or an expired demo account. Add this test plan to your release routine alongside the App Store submission checklist. For updates, a phased release limits how many users a missed bug reaches. To get a second opinion on a rejected build, email yagyeshsrbobde@gmail.com with the rejection message.