App Store guideline 2.1 app completeness rejection: how to fix it

A guideline 2.1 rejection means App Review couldn't treat your submission as a finished, working app: it crashed, showed placeholder content, had a broken link, or the reviewer couldn't get past a login or find an in-app purchase. Read the message for the exact item, fix it or add the missing review information in App Store Connect, and resubmit. If you think the reviewer missed something, reply to App Review first.

As of November 3, 2026, the rules below come from Apple's App Review Guidelines and App Review pages, listed at the end. Apple's App Review page says that on average over 40% of unresolved issues relate to guideline 2.1, so it's worth getting right before you submit.

What does guideline 2.1 say?

Guideline 2.1 is called App Completeness and has two parts.

Part	What Apple asks for
2.1(a)	Submit a final version with all necessary metadata and fully functional URLs. Remove placeholder text, empty websites and other temporary content. Test on a device for bugs and stability. If the app has a login, include demo account info and turn on your back-end service. Apple will reject incomplete app bundles and binaries that crash or show obvious technical problems.
2.1(b)	If you offer in-app purchases, make sure they're complete, up to date, visible to the reviewer and functional. If a configured in-app purchase can't be found or reviewed in the app, explain why in your review notes.

The same rule covers apps you make available for pre-order. And if you can't give a demo account for legal or security reasons, 2.1(a) allows a built-in demo mode instead, with prior approval from Apple, as long as it shows the app's full features.

What does Apple want in the review information?

Apple's help page Provide information for a complete review says to add everything App Review needs in the App Review Information section of App Store Connect, and that incomplete submissions will be rejected. This is the part where I'd slow down:

What to give	Apple's detail	What I'd double-check
Demo account	A username and password that work at the time of submission. Credentials that expire or change before review starts may get the submission rejected.	A test account that was reset, deleted or locked after you submitted.
Other account types	If the app has several account types, such as admin and general user, add credentials for each in the Notes field.	Only the regular user login is given, so the reviewer can't reach admin features.
Sign-in codes	If the app needs an authentication code in addition to or instead of a password, put it in the Notes field in advance. Without it, a call may be needed, and Apple says calls are typically completed within three to five business days.	A one-time code is sent to your own phone during review.
Subscriptions	For auto-renewable subscriptions, provide a demo account with an expired subscription so the whole purchase flow can be reviewed.	The demo account is already subscribed, so the paywall never shows.
Back end	Guideline 2.1(a) and the Before You Submit list both ask for back-end services to be live during review.	A staging server was turned off, or the app points at an expired test API.
App overview	The app's concept and business model, what changed in an update and where to find it, purpose and audience, devices and OS versions you tested, external services the app relies on, and any regional differences.	Notes left empty, so the reviewer has to guess how the app is meant to work.
Hardware	Apps that need hardware must provide a video, not a screen recording, of the app on a physical Apple device pairing and working with it.	A screen recording only, or no video at all.

Apps in regulated fields, such as medical, financial or gambling apps, also need documentation showing they're qualified and authorized, and the same page lists examples per field.

The Before You Submit list

At the top of the guidelines, Apple has a short checklist. These lines are the ones that map to 2.1:

• Test your app for crashes and bugs.
• Ensure that all app information and metadata is complete and accurate.
• Update your contact information in case App Review needs to reach you.
• Provide App Review with full access to your app, with an active demo account or a fully featured demo mode, plus anything else needed, such as login credentials or a sample QR code.
• Enable backend services so they're live and accessible during review.
• Include detailed explanations of non-obvious features and in-app purchases in the App Review notes.

Reply or resubmit?

When the message names a concrete problem, like a crash or a login that failed, the route is to fix it and resubmit. If you think the reviewer missed something, for example the login worked and the feature was behind a menu they didn't open, reply to App Review in App Store Connect. Apple's Contact App Review page asks you to be specific about the feature, guideline or step you want clarified, and says you can ask for a call in the same message window if you need more help after they answer.

Apple's contact page also says the reply isn't the place to appeal. If you believe the app follows the guidelines and the reply didn't settle it, appeals go to the App Review Board through Apple's appeal form.

One more thing I noticed while researching: several threads on Apple's Developer Forums are titled "Guideline 2.1 - Information Needed." That's not a separate rule on Apple's pages. My read is that the reviewer has a question, so I'd answer it directly in the reply, with screenshots where they help.

What I'd do

Before resubmitting, sign out, then sign in with the exact demo account you're giving Apple on a real device, on a fresh install. Walk through every feature the rejection names and every in-app purchase you configured. Then fill the Notes field as if the reviewer has never heard of the app: what it does, how to reach the main features, and any codes they'll need. If you want an outside read on whether your store page explains the app clearly, I'll check it for free.