Guideline 2.1 App Completeness: why apps fail and the fix

Guideline 2.1 App Completeness is the App Review rule that a submission must be a final version, with working URLs and no placeholder content, tested on a device, and with demo account details if the app has a login. A rejection under it usually means the reviewer hit a crash, a broken link, an empty screen, or a login they couldn't get past. Read the message for the specific problem, because the fix may not need a new build.

We did not test these steps on a live submission. Guideline wording can change, so read Apple's current text when you reply.

What guideline 2.1 App Completeness says

Section 2.1 has two parts. Part (a) covers the submission itself. Apple asks for final versions with all necessary metadata and fully functional URLs, and says to clear out placeholder text, empty websites, and other temporary content. It asks you to test on a device for bugs and stability. It asks for demo account info if the app includes a login, and tells you, with an exclamation mark, to turn on your back-end service.

If you can't provide a demo account because of legal or security obligations, Apple allows a built-in demo mode.

Part (b) covers in-app purchases. They must be complete, up to date, visible to the reviewer, and functional. If a configured item can't be found or reviewed in the app, explain why in your review notes.

Common causes and fixes

What the reviewer saw	Likely cause	Fix
Crash on launch or during a flow	A bug on Apple's device or OS version, or a release-only problem	Reproduce it on that OS. Ask for the crash log if one was attached. New build
Can't sign in	Expired demo account, IP restriction, or staging server down	Fix the account and reply. Usually no new build
Blank screen or spinner	Backend unavailable or a region restriction	Fix the server and reply
Dead link	Privacy, support, or marketing URL is broken	Fix the page or metadata and reply
Placeholder content	Lorem ipsum, test data, or a "coming soon" screen	Remove it. Often needs a new build
In-app purchase not found	Product not submitted or not visible in the build	Check the product's status and add notes

Many of these are server or metadata problems, and those don't need a new build. Apple's guidance on when to resubmit says that issues in metadata or on your server can be fixed and answered with a reply. Uploading a new build starts a new review without fixing a thing, if the build was fine.

How to reply to App Review

Find the message in the app's App Review section in App Store Connect. A helpful reply says what happened, what you changed, and how to confirm it.

A hypothetical example:

The demo account had expired. We have reactivated it, and it won't expire before the end of the year. Please sign in with the details in App Review Information. The home screen should load within a few seconds on any network. This was a server-side fix, so the build is unchanged.

Keep it short and specific. If the reviewer's report doesn't match what you see, ask for the device, OS version, and the steps they took. Apple's guidance on contacting App Review says to name the exact feature or step you need clarified.

Why crashes appear only in review

It's frustrating to get a crash report for a build that worked on your desk. Some usual reasons:

• You tested a debug build, while Apple tested a release build. Test the same archive through TestFlight.
• Apple may review on an OS version or device you didn't try, including iPad for an iPhone app that also runs on iPad.
• The reviewer has a fresh install with no cached data and a different locale or network.
• Your backend rejected traffic, since an IP allowlist or a geofence can block the reviewer's location.
• A feature flag or remote configuration differs from what you saw.

Install from TestFlight on a clean device with a new account, on mobile data, before you submit. Add crash reporting to the build so a crash in review gives you a stack trace, as long as you upload debug symbols.

A pre-submission check for 2.1

Go through this list before each submission. It takes about 15 minutes, and a rejection costs far more than that.

1. Install the exact build from TestFlight on a clean device.
2. Sign in with the demo account in App Review Information, from a phone on mobile data.
3. Confirm that the account's expiry date is well past the review window.
4. Walk through every screen in the metadata and screenshots.
5. Open the privacy, support, and marketing URLs.
6. Search the app for "lorem", "test", "TODO", and "coming soon".
7. Buy each in-app purchase in the sandbox, and confirm that it's visible.
8. Add notes for anything a reviewer can't reach on their own, such as hardware or a location.

The longer version belongs in your app release checklist.

For agencies

Demo access is a common failure on client projects. The client's staging system may sit behind a VPN, or the test account may belong to someone who has left. Assign an owner for the demo account. Put a check on the calendar before each submission. If the client can't give reviewers a login, ask early about a demo mode, because building one takes planning.

If you're stuck on a rejection, the routes are in our guide to App Store review status, including the appeal to the App Review Board.

Specita keeps source changes and delivery history together for each release, so whoever handles a rejection can see what changed in the build. Set it up with the App Store Connect guide.

Apple guidance checked on November 4, 2026.