App rejected under Apple Guideline 2.1 (App Completeness): how to fix it

What does Apple Guideline 2.1 say?

You hit Submit, and the note in App Store Connect says Guideline 2.1, App Completeness. On your laptop the app works. On the reviewer's phone, the login failed, a screen crashed or the content was still lorem ipsum. Guideline 2.1 asks for a final version, not a draft. Part (a) covers the app and its metadata. Part (b) covers in-app purchases.

In plain words, 2.1(a) asks for four things: complete metadata and working URLs, no placeholder text or empty websites, testing on a real device for bugs and stability, and a demo account if the app has a login. Apple says it will reject incomplete bundles and binaries that crash or show obvious technical problems. Read the full wording on Apple's guidelines page.

Part (b) says any in-app purchases must be complete, current, visible to the reviewer and working. If a purchase you set up can't be found in the app, explain why in your review notes.

What causes a 2.1 rejection, and how do you fix each one?

Each thing the reviewer hit comes from 2.1 or Apple's pre-submission list. The middle column is our view of how it can happen. Start with whichever one the review note names, then check the rest, so you don't lose another review round.

The iPad row is easy to miss. Apple says an app designed for iPhone can run on iPad in compatibility mode, and that removing iPad as a destination in Xcode doesn't stop that if the app has no iPhone-only dependency. So look at your layouts there too. TestFlight allows up to 100 internal testers and 10,000 external ones.

The backend row catches Supabase users in particular. Supabase's pricing page says free projects are paused after 1 week of inactivity. If your project has been quiet while the app waits for review, the reviewer can meet a dead backend. Check the project status before you submit, and again if the review runs long. Supabase's production guide says moving to Pro guarantees it won't pause your project for inactivity, if you'd rather not check by hand.

How do you give App Review a demo account in App Store Connect?

Put a working username and password in the App Review Information section of the version you're submitting. Apple keeps this section private from customers, and you can edit it at any time.

1. Create a real account in your production backend, with realistic data on every screen the reviewer needs to see.
2. Sign in with it on the release build, on a device, and walk through the main flow.
3. In App Store Connect, open your app and the version you're submitting, then find App Review Information.
4. Enter the username and password in the sign-in fields.
5. Use the Notes field, which holds up to 4,000 bytes, for setup steps and anything the reviewer needs to find.
6. Check that the contact name, email and phone number are correct. The phone number needs a plus sign and country code.

Apple's complete review page and App Review information reference add these rules. Missing them can get the submission rejected or slow the review down:

• The credentials must work at submission and must not expire. Changing the password before review starts can get the submission rejected.
• If people sign in through a single sign-on service, include demo login details for that service too.
• If your app has several account types, such as admin and regular user, add the extra credentials in Notes.
• If you sell auto-renewable subscriptions, provide a demo account with an expired subscription, so the reviewer can see the whole purchase flow.
• If sign-in needs an authentication code, put it in Notes in advance. Otherwise a call may be needed, and Apple says calls typically happen within 3 to 5 business days.

A demo mode can replace the account in limited cases. Guideline 2.1(a) allows it when legal or security obligations stop you giving a demo account, with Apple's prior approval, and it must show the app's full features. Apple's review help also mentions apps that handle sensitive information or operate in highly regulated industries. For most AI-built apps, the demo account is the simpler route.

Should you reply to App Review or resubmit?

Reply if the fix didn't need a new build, and resubmit if it did. Apple's review status page draws this line, and it matters: resubmitting starts a new review, after which App Review can no longer reply to your earlier message.

When you write, be specific. Say what was wrong, what you changed and where to check it. Here's the shape of a useful reply, for a hypothetical app whose backend was paused:

• What was wrong: the database was paused during review, so sign-in failed.
• What changed: the backend is live, and the demo account in App Review Information works on the current build.
• Where to look: sign in, open Plans, then tap any plan to see the feature that failed.

Use the same detail in the Notes field for a new build. Apple asks you to say what changed and where reviewers can find it, along with the app's purpose and audience, devices and OS versions tested, and external services it depends on, such as authentication, payment or AI services.

How long will it take? Apple states a goal of reviewing at least 50% of submissions in under 24 hours and 90% in under 48 hours, and says apps with little review history can take longer.

Can you appeal a 2.1 rejection?

Yes, but only after replying, and only if you believe the app already follows the guidelines. Apple asks you to reply to the rejection message first and to appeal if that doesn't resolve it. A reply can clear up a misunderstanding, and a real crash can't be appealed away.

Apple's App Review Board page allows one appeal per rejected or removed app. Cite the guideline and explain point by point how the app meets it. Don't appeal if you've already resubmitted, since resubmitting closes the appeal, and don't appeal a request for more information.

Can you fix a 2.1 rejection yourself?

For some causes, yes. Adding a demo account and waking a backend need no developer and no new build. Replacing placeholder text in the listing or your database is just as simple, but text inside the app needs a new build. A crash takes more, because you need to reproduce it on a device, fix it and upload a build. If the rejection also cites Guideline 4.2, the problem is bigger than completeness: see the Guideline 4.2 guide. And if you offer social login, check Guideline 4.8 before you resubmit.