Guideline 2.1, and what reviewers actually test
Guideline 2.1 is the most common rejection and the most self-inflicted, because it is almost never about the app being incomplete. It is about the reviewer being unable to see that it is complete.
Five things get tested, every time, and each is checkable in minutes:
- Can they sign in? With the credentials you actually submitted.
- Does it crash? Particularly on the oldest OS version you claim to support.
- Do the links work? Privacy policy, terms, support, from inside the built app.
- Does it work if permissions are declined? They will decline them.
- Is there anything obviously unfinished? Placeholder text, empty states with no explanation, a feature that does nothing.
Rehearse it. Fresh install, a device that is not yours, the credentials from the submission form, decline everything. Twenty minutes, and it removes the most common rejection in the store.
1. The demo account
The single most common self-inflicted rejection.
Test it the morning you submit, from a device that is not yours, in a private session, using the exact string you typed into App Store Connect. Not the account you use daily. Not the one you think you created.
Failure modes that all look identical to a reviewer: the password was rotated after you filled in the form, the account was rate-limited by testing, the email verification expired, or sign-in requires an SMS code sent to a phone the reviewer does not have.
If your login requires a one-time code, provide a path that does not. A bypass account, a fixed test code, a demo mode. A reviewer who cannot receive your SMS has not seen your app, and no amount of explanation in the notes changes that.
Seed it with data. An empty account looks like a broken app, and an empty first screen is how a completeness rejection becomes a minimum functionality conversation as well.
2. Crashes, on the oldest OS you support
Rejections name the device and OS version, and it is frequently the oldest one you claim to support — which is rarely where developers test.
Check what you actually claim. minimumOsVersion in the built app is a promise. If you have not run on it, either test it or raise it.
For React Native specifically, the crashes that appear only on older OS versions usually come from a native dependency rather than your code, which makes them invisible in a simulator on current hardware.
3. The links, from inside the built app
Privacy policy, terms, support URL. Open each one from the shipped app on a device, not from your browser on your machine.
They fail for boring reasons: a staging domain, a redirect that drops the path, a trailing slash, a page behind an auth wall you are already signed into. A privacy policy that 404s is both a 2.1 problem and a 5.1.1 problem.
4. Declining permissions
A reviewer will decline them. What happens next is the whole test.
| If they decline | What the reviewer concludes |
|---|---|
| Blank screen | Non-functional without the permission |
| A modal that cannot be dismissed | Same, worse |
| Crash | 2.1, and probably a second finding |
| A usable app offering a manual alternative | Fine |
Build the declined path deliberately and test it with the permission actually denied on a device. Guideline 5.1.5 on location specifically.
5. Anything obviously unfinished
Placeholder text. Lorem ipsum, TODO, example.com, a [DATE — fill in at publish] that shipped. That last one is not hypothetical: a live legal page in this studio's own portfolio was serving exactly that string.
Empty states with no guidance. A tab that is blank until something happens reads as broken. Either seed it or say what to do.
Features that do nothing. A button wired to nothing is worse than an absent button.
grep -rniE 'lorem ipsum|\bTODO\b|example\.com|fill in at publish|placeholder' \
src/ app/ ios/*/Info.plist 2>/dev/null | head -20Then write it down for them
Review notes are where you pre-empt the questions the five checks cannot: where the non-obvious features live, what a permission is for, what looks wrong but is not.
DEMO ACCOUNT
[email protected] / ******** (verified working 7 Sep)
WHERE TO FIND THINGS
1. Sign in with the account above; it already has three saved sessions.
2. The scoring screen is under Profile > History; it needs one session,
and the demo account has them.
THINGS THAT LOOK WRONG AND ARE NOT
- The second tab is empty until a session completes.What a pre-submission scan covers
Placeholder strings, unresolvable URLs in the app and in metadata, permission strings with no corresponding code path, and demo credentials present in the submission but never verified. All deterministic, all local.
What it cannot do is sign in as a reviewer and try your app. That part is twenty minutes of your time and it is the best-value twenty minutes in the whole submission. The full first-submission checklist. · What shipcheck checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
What is App Store Guideline 2.1?
App Completeness. Submissions must be final versions with all necessary metadata and working URLs, and apps that crash, contain obvious bugs, or cannot be fully reviewed because of a login the reviewer cannot pass are rejected under it.
Why do apps get rejected for a demo account?
Because a reviewer who cannot sign in cannot review the app. Expired credentials, a password rotated since submission, rate limiting, or an SMS code the reviewer cannot receive all produce the same outcome, and all of them are entirely preventable.
Does a reviewer really test every feature?
Not every feature, but they will sign in, move through the main flows, decline permissions, and try the links. Those four are where completeness rejections come from, and all four can be rehearsed before submitting.
What happens if my app crashes during review?
It is rejected under 2.1, and the rejection usually names the device and OS version. Test on the oldest OS version you claim to support, because that is frequently where the crash is and rarely where developers test.
How do I avoid a 2.1 rejection?
Rehearse the review. Fresh install on a device that is not yours, sign in with the demo credentials you submitted, decline every permission, open every link, and use the app the way someone who has never seen it would. It takes twenty minutes.
shipcheck. “Guideline 2.1, and what reviewers actually test.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/rejections/guideline-2-1-what-reviewers-actually-test/