Guideline 2.1 App Completeness: fix the crash, the login or the missing purchase

2.1 is less about quality and more about completeness from a stranger's point of view. The reviewer has none of your context: no account, no test data, no idea which screen matters. Everything they need has to work on a fresh install.

"Works on my phone" is the most common story behind a 2.1 crash, because your phone isn't a fresh install of the Release build. Reproduce the reviewer's conditions instead:

If any core feature sits behind a login, the reviewer needs credentials that work on the first try, days after you submit, from a device and region you don't control.

• Make it permanent. No expiry, no trial clock, no inactivity lockout.
• Skip the second factor. SMS codes, email magic links and authenticator apps all fail for a reviewer. Allow-list the demo account to bypass them.
• Pre-populate it. An empty account makes a finished app look unfinished. Seed it with realistic data so every screen has something to show.
• Keep the backend up. Apple's own wording: "turn on your back-end service!" Staging servers that sleep or rotate credentials cause a large share of these rejections.
• Demo mode needs permission. If legal or security rules prevent a demo account, Apple allows a built-in demo mode only "with prior approval by Apple".

2.1(b) is where subscription apps get caught. The reviewer has to be able to see your products, buy them in the sandbox, and get what they paid for.

1. 01

   Submit the products with the build

   New in-app purchases go to review attached to an app version. If you submit the binary without them, Apple returns the products — the forum example in Sources says exactly that.

2. 02

   Check your agreements

   StoreKit returns no products while the Paid Apps agreement, tax and banking details are incomplete in App Store Connect's Business section. An empty paywall is a 2.1 rejection waiting to happen.

3. 03

   Validate receipts production-first

   Apple's own guidance in these rejections: validate against the production environment first, and fall back to sandbox when you get the sandbox error. Reviewers purchase in sandbox against a production-signed build.

4. 04

   Make every product reachable

   If a configured product can't be reached in the app — say, a legacy plan kept for existing subscribers — explain why in the review notes, as 2.1(b) asks.

5. 05

   Test restore and entitlement

   Buy, delete the app, reinstall, restore. If the premium state doesn't come back, a reviewer will find it.

Review notes are free and most developers leave them empty. For anything with a login, purchases or non-obvious setup, they save a rejection cycle.

Demo account (permanent, no 2FA, pre-populated):
  Email: review@yourapp.com
  Password: ********

How to reach the main features:
  1. Sign in with the account above.
  2. [Feature] is on the Home tab; tap [button].

In-app purchases:
  - [Monthly], [Annual] are on the paywall shown after onboarding step 3.
  - [Legacy plan] is configured for existing subscribers only and is not purchasable by new users.

Hardware / location requirements: none.
Contact during review: [name, phone]

Fix the issue, then reply in App Store Connect describing precisely what changed and how to verify it. Apple reviews most submissions within a day, so a clean fix is cheaper than an argument.

• Bug-fix updates get some slack. Apple says that when it finds other issues while reviewing a bug-fix submission, you can usually address them in your next submission unless there are legal or safety concerns — accept by replying to that message.
• Expedited review is for real emergencies. Apple's expedite request covers critical bug fixes (include steps to reproduce) and releases tied to a dated event. Overusing it can get future requests declined.
• Appeal only if the reviewer was wrong. If the app works and the reviewer hit a problem you can't reproduce, reply with evidence first; the App Review Board is the last step, one appeal per submission.