On its own App Review page, Apple publishes the failure mode in one sentence: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more."
Read the sentence carefully, because most summaries get it wrong. It is not "40% of rejections." It is over 40% of unresolved issues: the things that stall a submission in review. And they stall for reasons that have almost nothing to do with engineering. This post is about what guideline 2.1 actually asks for, where submissions trip on it, and how to make the rule boring.
What 2.1 actually requires
The App Review Guidelines give App Completeness two clauses. The first is a checklist disguised as a sentence: submissions "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission." It also tells you to test on-device for bugs and stability, to "include demo account info (and turn on your back-end service!)" if the app has a login, and ends without ambiguity: "We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems."
The second clause is about in-app purchases: they must be "complete, up-to-date, visible to the reviewer and functional," and if a configured item cannot be found or reviewed in the build, you explain why in the review notes.
That parenthetical in the first clause is doing more work than any other line in the guidelines. "(and turn on your back-end service!)" is the sound of a rule written by people who have watched a thousand reviews fail because staging was down.
The issues behind the 40%
Apple lists the common ones on the same App Review page. Four of them are 2.1 territory:
- Crashes and bugs. "Submit items for review only when they're complete and ready to be published," tested on devices running the latest software.
- Broken links. Every link in the app must work, and a support link and a privacy policy link are required for all apps. Apple tags this one 2.1 and 5.1 together.
- Placeholder content. "Items that are still in progress and contain placeholder content are not ready to be distributed and cannot be approved."
- Incomplete information. Everything the reviewer needs goes in the App Review Information section: a valid demo account for sign-in features, specifics for unusual configurations, a demo video or the hardware itself for features that need it.
Two more items on Apple's list, inaccurate screenshots and misleading users, belong to guideline 2.3 on metadata. Same lesson, different rule: what the store listing promises is what the reviewer must find.
The mechanics that actually catch people
The failures inside "incomplete information" are more specific than a forgotten password field. Apple's complete-review help page spells them out: enter "a username and password that work at the time of submission," because "credentials that expire or change before your review starts may result in the submission being rejected." An app with multiple account types needs working credentials for each one. An app that requires hardware needs a video, not a screen recording, "that shows your app running on a physical Apple device as it pairs and interacts with the hardware."
There is one legitimate escape: if legal or security obligations make a demo account impossible, the guidelines allow a built-in demo mode instead, with Apple's prior approval, and it has to show the app's full features.
Timing matters too. Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48. A completeness failure does not just lose that slot; it starts the clock over.
When a review stalls anyway
If the reviewer flags something, the reply path is inside App Store Connect, and resubmitting is the wrong first move: it starts a new review and Apple can no longer reply to the previous message. Their guidance on resubmission is one line: "Don't resubmit until you've resolved every issue identified by App Review. Resubmitting with unresolved issues delays review and results in the same outcome."
If you believe the review got it wrong, the App Review Board takes appeals, one per rejected submission, after you have first replied to the rejection message with clarification. Expedited review exists for genuine urgency: a critical bug fix, or a release tied to an event you are directly associated with, and only for a submission already sent to App Review.
Our position
Guideline 2.1 failures are submission chores, not engineering problems. They happen when nobody owns the act of submitting: the demo account expired, the privacy policy link 404s, the back end redeployed Sunday night, the screenshots are from two versions ago. The fix is a named person and a checklist that runs before every submission, not after a rejection. The reviewer cannot evaluate what they cannot reach, and access is the cheapest thing to get right in the entire process.
A rejected 2.1 submission is not a verdict on the app. It is a to-do list written by Apple, and it is shorter than the time it costs you.
The takeaway
Run this before every App Store Connect submission:
credentials still valid when review starts, not just at submit
hardware-dependent apps: video of the device pairing
The ACCESS lines are where 2.1 problems tend to live in our experience. Getting them right is the kind of unglamorous process our custom software work treats as part of shipping, and it is the standard CashTaq submits under. If you want a second pair of eyes on a submission before it goes in, send us the build.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
