You uploaded the build, the App Review Notes field had something in it, and the Resolution Center reply still cites Guideline 2.1 with a line about a required login that the reviewer could not get past. The rejection sounds like a policy problem. It almost never is. Guideline 2.1 is App Completeness, and the rejection means the reviewer hit a closed door that they were not supposed to need a key for.
Short answer
The short answer is that Guideline 2.1 rejections for login-gated features fall into three buckets: missing demo credentials in App Review Notes, broken or expired credentials that fail authentication during the review pass, and a back-end service that was off, region-blocked, or rate-limited at the moment the reviewer tried to sign in. According to the App Review Guidelines, Apple expects submitters to include demo account info and to keep the back-end service running through the review window. For a genuinely private community, the login is allowed; the obligation is to give the reviewer a path inside, not to remove the wall.
What you should know
- Guideline 2.1 is App Completeness, not access policy. The rejection means the reviewer could not finish the test pass, regardless of whether the login is justified.
- Demo credentials live in App Review Notes. App Store Connect has a dedicated field. The reviewer reads it before opening the binary.
- The credentials have to work on the submitted build. A staging-only account, an expired token, or a back-end that requires manual approval all count as failed authentication.
- A demo mode can replace a demo account, with prior approval. Apple permits an in-binary demo path for fintech, health, or regulated apps where real credentials cannot be shared.
- Private communities are a recognized use case. Closed networks, member-only services, and invite-gated apps can require login, as long as the justification is clear and a review path exists.
- Guideline 5.1.1(v) is a separate concern. It only applies when login is required for features that are not account-based. For a private community, the entire experience is account-based.
What does a Guideline 2.1 rejection for login actually mean?
The short answer is that Guideline 2.1 covers App Completeness, and the reviewer can only verify completeness by reaching the screens that ship in the binary. When a login wall sits between the reviewer and the rest of the app, the reviewer needs working credentials or a demo path. Without one, the review pass ends at the sign-in screen, and the build comes back marked incomplete.
The mechanism is the App Review Information section of App Store Connect. The reviewer opens the submission, reads the demo account and notes, and then exercises the binary. If the credentials fail, the reviewer is not expected to email the developer for new ones inside the standard review window. The default response is a 2.1 rejection with a line about the failed login. According to Apple's App Review page, the reviewer's goal is to evaluate the user experience the customer will see, and any gate that blocks the test pass interrupts that goal.
The consequence is that the rejection text usually quotes a specific failure. Common phrasings include "we were unable to sign in with the provided demo account," "the app required a sign-in but no credentials were provided in App Review Notes," and "we were unable to access core functionality of your app." Each of those sentences maps to a different fix. Read the exact wording before drafting the resubmission.
The limit is that this rejection does not by itself say the login is illegal. A separate citation under Guideline 5.1.1(v) is needed for that, and the two rejections can coexist on the same build when the login is unjustified and unreachable at the same time.
How do I provide working demo credentials in App Store Connect?
The short answer is to enter a dedicated review username and password in the Demo Account fields of the App Review Information section, mark the credentials as required, and confirm they sign in successfully on the exact build version uploaded. The fields sit inside App Store Connect, in the version-level App Review Information block, alongside the contact info and notes fields.
The mechanism has a few moving parts. The credentials should belong to a long-lived account that does not auto-expire, does not require email verification on first login, and does not depend on a one-time code sent to a phone or external email. If the account uses two-factor authentication, the second factor has to be either bypassed for the review account or delivered through a channel the reviewer can read inside the notes field. A reviewer who receives an SMS code on a phone number the developer controls cannot complete the login.
In practice, three patterns generate repeat rejections. The first is a credential that works in staging but not on the build uploaded to App Store Connect, because the developer pointed the production binary at a different back-end. The second is an account that the developer manually approves through an admin queue, where the approval lag is longer than the review attempt. The third is a region-locked back-end that returns a 403 to Apple's review IP ranges, which sit in the United States by default.
The limit is that the demo account can only test the role the credentials carry. If the app has multiple roles (admin, member, guest), supply credentials for the role the reviewer needs to reach gated features. Stating in the notes that all features are visible to this role saves a clarification round.
How do I justify mandatory login for a private community?
The honest answer is that Apple has no objection to private communities as a category. Closed professional networks, paid membership sites, employee-only apps, and invite-gated communities are all permitted. The justification has to appear in two places: the App Review Notes field, and the App Privacy and metadata declarations that describe the product to users before download.
The mechanism inside App Review Notes is simple. Name the membership criterion in plain language. Examples that have worked in practice: members must hold a current paid subscription purchased on the marketing site; access is limited to verified employees of partner hospitals; the community is invite-only and runs on a referral model; users are vetted real-estate agents with an active license number on file. The reviewer reads the criterion, sees the demo credentials immediately below, and treats the gated experience as the intended product.
The evidence layer matters too. The App Store listing, the support URL, and any in-app onboarding screens should describe the community as private. A listing that promises broad public access while the binary gates everything behind a paid login produces a Guideline 2.3 or 2.3.1 rejection for metadata accuracy on top of the original 2.1 issue. Per Apple's metadata guidance inside the App Review Guidelines, the listing has to match the experience the user will receive.
The limit is that membership criteria the reviewer cannot independently verify, such as private vetting or off-platform approvals, still need a demo path. A reviewer cannot wait days for a manual admit. Either pre-provision the review account inside the system, or supply a demo mode with prior approval.
When is a built-in demo mode the right answer?
The short answer is when sharing real credentials is impractical, illegal, or unsafe. Fintech apps with KYC, health apps with HIPAA-bound data, identity apps with government ID workflows, and corporate apps tied to active employment all fall in this category. A demo mode lets the reviewer reach every screen without crossing the legal or security boundary. The switch is a known entry point inside the binary (a hidden tap pattern, a specific code in a settings screen, a build flag named in the notes) that loads scripted data mirroring production: a fake account balance, a sample patient record, a placeholder identity result.
Apple's wording inside the App Review Guidelines on App Completeness is explicit: the demo mode has to exhibit the full features and functionality of the app. The Resolution Center is the right place to start the conversation, well before submission. A demo-mode-only build with no prior approval still risks a 2.1 rejection, and a demo that hides part of the feature set fails the same check the original login wall failed.
How does Guideline 5.1.1(v) interact with the login wall?
The short answer is that Guideline 5.1.1(v) is about whether the login is allowed in the first place, while Guideline 2.1 is about whether the reviewer could test it. The two rejections come from different parts of the review pass and require different fixes. According to the Privacy section of the App Review Guidelines, apps may not require users to enter personal information except when the information is directly relevant to core functionality or required by law.
The mechanism is a substance check. A meditation app that requires email and password to play a guided session, where the session itself does not depend on account state, fails 5.1.1(v). A private community where membership and identity are part of the product itself does not fail 5.1.1(v), because the account is the core functionality, not an obstacle to it.
In practice, the test that separates the two cases is whether removing the account would still leave a usable app. If yes, the login is non-essential and the app needs a guest path or has to remove the gate. If no (the entire product is the community, the messaging, the directory, the private feed), the account is the product and 5.1.1(v) does not apply.
The limit is the documentation around the login. Even when the gating is justified, the App Privacy questionnaire still has to declare what the account flow collects (email, name, payment data, employer), and the privacy policy still has to disclose the recipients and the retention behavior. A 2.1 fix that ignores those declarations risks a follow-up 5.1.1 rejection on the same submission cycle.
| Reviewer line in the rejection | What it usually means | Where to look first |
|---|---|---|
| Demo account credentials were not provided | The App Review Notes field is empty or only has a comment | App Store Connect: App Review Information |
| We were unable to sign in with the credentials provided | Account expired, password rotated, or back-end pointing to staging | Production database; binary build config |
| We were unable to access core functionality of your app | Demo account works but lacks the role needed to reach the gated features | Role and permission settings on the demo account |
| The app required a sign-in to access features | Login gates content Apple considers non-account-based | Audit which features need an account vs. which do not |
| Two-factor code was required and could not be retrieved | Review account has 2FA enabled with no inbox the reviewer can read | Disable 2FA for the review account or supply codes in notes |
What to watch out for
The first trap is treating the rejection as a permission problem. Guideline 2.1 does not say the login is forbidden. It says the build is incomplete because the reviewer could not test it. Rewriting the app to remove the login is the wrong fix when the gating is part of the product.
The second trap is the credential rotation. Many back-end teams enforce password expiry policies that apply to every account, including the demo one. A 90-day rotation that ages out the review credentials between submissions silently breaks the next update. Set a calendar reminder to verify the credentials before each new version submission, and exempt the review account from the rotation policy where possible.
The third trap is the SSO trap. Apps that use enterprise SSO (Okta, Azure AD, Google Workspace) often have no path for an external reviewer to authenticate. The fix is either a parallel local account flow with its own credentials for review use, or a built-in demo mode that the reviewer can activate without touching the SSO provider. Stating in the notes that the reviewer can use any Okta account does not work when the reviewer has no Okta account.
The fourth trap is the back-end-off problem. Developers sometimes upload a new build, then take the staging back-end offline before realizing the build still points at staging. The reviewer hits a network error on login and returns a 2.1 rejection. The cleanest verification is to install the App Store Connect build on a fresh device, on cellular, and confirm the sign-in works end to end before nudging the submission into the review queue.
For builders who want an external automated read of their build before resubmission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS. The scan looks at network endpoints, declared SDKs, and the points where the binary expects the back-end to respond, which surfaces the gap between staging and production configuration before the reviewer sees it.
Key takeaways
- Read the exact rejection wording; Guideline 2.1 for login-gated features always names what the reviewer tried to do and what failed, and the fix follows from that specific sentence.
- Treat the demo account as a production artifact: long-lived, role-appropriate, exempt from password rotation, and verified on the binary uploaded to App Store Connect.
- Justify private community gating in App Review Notes by naming the membership criterion and supplying a reviewer-ready account that carries member access rights.
- Use a built-in demo mode when sharing real credentials is impractical, but get prior approval through the Resolution Center before submitting the build.
- Some teams running pre-submission audits use platforms like PTKD.com (https://ptkd.com) to catch back-end configuration drift and broken demo paths before App Store Connect runs its own review pass.
