Rejected: Reviewer Can't Access a Gated Feature (2026)

Apple rejected under Guideline 2.1 because the reviewer couldn't get past a paywall, region lock, role gate, or invite gate. Fix it with notes plus server config, usually no new build.

Your submission gets rejected under Guideline 2.1 (App Completeness) with language like “We were unable to evaluate the [team sharing / AI chat / Pro analytics] feature because it appears to require [a paid subscription / an admin role / an invite].” Your app is technically working; the reviewer simply hit a real gate (paywall, role, invite, region) that the demo credentials you provided didn’t let them pass. They tapped around, couldn’t unlock the feature in their review window, and rejected. Guideline 2.1 is the single most common rejection bucket — Apple has repeatedly said it accounts for over 40% of unresolved review issues — and access-to-gated-features is a big slice of it.

Fastest fix (usually no new build): give the reviewer one “reviewer profile” account with every entitlement pre-granted server-side, then paste a per-feature, tap-by-tap walkthrough into App Store Connect → your app version → App Review Information → Notes, and resubmit. Reviewers will not pay for your subscription, request an invite from your back office, disable their own 2FA, or VPN into another country to test your features. Remove every gate for that one account and hand them a map straight to the feature.

Which bucket are you in?

Symptom in the rejectionLikely gateFastest fix
”appears to require a paid subscription” / paywall shownFree-tier demo accountServer-side upgrade demo user to top tier
”could not access admin / team settings”Role gate (member vs owner)Set demo user role = owner
”feature did not appear” / blank screenRegion lockregion_override server-side, or demo mode
”requires an invite / code”Invite or beta gatePre-consume invite for demo user
Login or SSO fails for the reviewerBackend unreachable from Apple’s networkMock the integration in a reviewer mode
Worked last release, broke this oneNew gate added without updating notesDiff the gating code; re-seed demo account

Common causes

Ordered by hit rate.

1. Demo account is on the free tier; rejected feature is paid

You created a sandbox account and documented it in App Review notes, but server-side that user is on the Free plan. The reviewer logs in, tries to use the Pro feature, hits the paywall. They don’t have a sandbox card to subscribe, and Apple’s reviewers will not create their own account or buy a subscription to test yours. They reject.

How to spot it: Look up the demo account in your database. Check subscription_status or plan. If it’s not the highest tier, this is the cause.

2. Feature requires an admin or team-owner role

Your collaboration feature only shows for users with role = admin or role = owner. The demo account is a regular member of a sample workspace. Reviewer can’t get to admin settings, can’t see the feature.

How to spot it: In your role / permissions table, find the demo user’s role. If it’s not the highest, the reviewer is locked out.

3. Region-locked feature invisible from Apple’s review location

Reviews can route through several Apple offices (Cupertino, Cork, and others; China-distributed builds may be reviewed from China). If your feature is gated to, say, region == "JP", the feature doesn’t even render its UI for the reviewer, so it looks missing rather than locked.

How to spot it: Check your feature gating logic for any if region in ['US', 'JP', ...] checks. If the reviewer’s IP / device region doesn’t match the allow list, you need a server-side region override, a VPN-friendly path, or a reviewer-mode bypass.

4. Invite-only feature accidentally requires an invite for reviewers

You shipped a “beta program” feature behind an invite code. The reviewer doesn’t have a code, so they can’t try the feature. Even when the feature is documented in your release notes, Apple still has to be able to actually open and use it — describing it is not enough.

How to spot it: Search your code for any invite-code or feature-flag check that the demo account doesn’t pass. List every such gate; the reviewer must pass all of them with one account.

5. Required external service unreachable from reviewer environment

Your B2B app needs to talk to a customer’s on-prem SSO provider, a corporate VPN, or a partner API that’s IP-whitelisted. The reviewer’s network can’t reach it; the SSO redirect fails, login dies. This also covers the classic 2.1 trap: a demo account protected by SMS or app-based 2FA that the reviewer can’t satisfy.

How to spot it: Try your full login flow on a public Wi-Fi network from outside your corporate IP range, on a fresh device. If SSO, 2FA, or any backend call fails, the reviewer hit the same wall.

6. New gate added in this release without updating reviewer notes

Last release the demo account worked. This release you added an entitlement check that the demo account fails. Reviewer notes weren’t updated to match, and now you have a regression on access.

How to spot it: Diff this release’s feature-gating code against the previous version’s. Any new check that the demo user’s data doesn’t satisfy is the regression.

Information to collect

  • The reviewer’s rejection text including the cited feature (copy it verbatim from Resolution Center).
  • A list of every gate in your code: subscription, role, region, invite, A/B test cohort, feature flag, 2FA.
  • The demo account’s current state in each gate’s relevant table.
  • Whether your app has the concept of a “reviewer mode” or special override.
  • Whether the demo account has any expiry, rate limit, or 2FA that could trip a reviewer (Apple requires the demo account must not expire).

Shortest path to fix

Step 1: Build a “reviewer profile” account

Create a single account with every entitlement pre-granted server-side. Standard recipe:

UPDATE users SET
  plan = 'pro_plus',
  role = 'owner',
  region_override = 'US',
  invite_codes_consumed = ARRAY['*'],
  two_factor_enabled = false,
  is_internal = true
WHERE email = 'apple-review@yourdomain.com';

UPDATE workspaces SET
  plan = 'enterprise',
  feature_flags = ARRAY['*']
WHERE owner_id = (SELECT id FROM users WHERE email = 'apple-review@yourdomain.com');

Pre-seed sample data so the home screen lands on a populated workspace, not an empty-state onboarding flow. Make sure the account has no expiry — Apple’s docs state the demo account “must not expire.”

Step 2: Write per-feature reviewer walkthroughs

For each gated feature, write a numbered step list. This goes in the Notes field (up to 4,000 characters, any language) under App Review Information:

DEMO ACCOUNT
User: apple-review@yourdomain.com
Pass: <strong-password>
(Pre-set to the highest tier and team owner. No 2FA. No code needed.)

TO TEST PRO ANALYTICS
1. Sign in with the demo account above.
2. Tap "Analytics" in the bottom navigation.
3. Tap "Pro Dashboard" — this is paid, but pre-unlocked for this account.
4. Expected: a chart with sample data from the last 7 days.

TO TEST TEAM SHARING
1. Sign in with the demo account (this account is the team owner).
2. Tap "Team" in Settings.
3. Tap "Invite Member" — copy the invite link (don't send).
4. Open the link in another browser; expected: invite acceptance screen.

If your app has multiple account types (admin vs general user), Apple’s guidance is to put the credentials for the extra accounts in the Notes field too — the Sign-In Required fields only hold one username/password.

Step 3: Add a reviewer-mode bypass for features that can’t be entitled

Some features (real bank connection, real hardware, third-party SaaS that requires a real customer) cannot be granted via entitlement. For these, gate a mock integration behind detection of the reviewer profile:

let isReviewerAccount = currentUser.email.hasPrefix("apple-review")
let bankClient = isReviewerAccount ? MockBankClient() : RealBankClient()

If you genuinely cannot provide any working demo account due to legal or security obligations, Guideline 2.1(a) lets you ship a built-in demo mode “in lieu of a demo account” — but only with prior approval by Apple, and the demo mode must exhibit the app’s full features. Don’t rely on this as your default; it needs sign-off and the full-functionality bar is strict.

In notes:

REVIEWER MODE
Bank connection uses mock data when signed in as apple-review@yourdomain.com.
Tap "Connect Bank" — sample transactions appear immediately.

Step 4: Handle region-locked features

For features gated by region, either:

  • Override the demo account’s region server-side (recommended): region_override = 'US'.
  • Or provide explicit device-region guidance in notes: “Set device region to United States in Settings → General → Language & Region for the live scores feature.”
REGION REQUIREMENTS
Live scores feature is available only in US/CA/UK.
Demo account has region_override='US' set server-side; no VPN needed.

Server-side override is far more reliable — you can’t count on a reviewer changing device region.

Step 5: Resubmit with the new notes

In App Store Connect, open your app, select the version, scroll to App Review Information, and paste the per-feature walkthroughs from Steps 2-4 into Notes. Confirm the Sign-In Required toggle is on and the Username/Password are correct. Then Add for Review / Submit for Review on the version.

Most reviewer-access fixes are notes + server config only; no new build is required, because the binary didn’t change — only the account’s server-side entitlements and the notes did.

Step 6: Reply in Resolution Center

Quote the reviewer’s question and point at the new walkthrough:

“Thank you for the feedback. We’ve updated the App Review Information notes with a step-by-step walkthrough for the Pro Analytics feature. The demo account is now pre-set to the highest tier with no 2FA; please tap ‘Analytics’ on launch and ‘Pro Dashboard’ to see the gated feature.”

Keep it specific and short. A reply that just says “please re-test” without naming the exact taps invites a second rejection.

How to confirm the fix

  • A cold install plus sign-in with the demo account lands on a populated workspace with all features unlocked.
  • Each gated feature in the App Review notes walkthrough is reachable in under 60 seconds with no paywall, code, or role wall.
  • A non-developer teammate following only the notes (no insider knowledge) can reach every gated feature.
  • The submission moves from Rejected back to Waiting for Review, typically within a day of resubmission.

If it still fails

  1. Reply in Resolution Center with a short screen recording (QuickTime, under ~50 MB) of you signing in as the demo account and reaching the cited feature.
  2. Verify the demo account’s entitlement in your database — a deploy or seed-script revert can silently downgrade it between submission and review.
  3. Add a second demo account at a different entitlement tier (e.g., free + pro) in the Notes field, in case the reviewer wants to see the paywall flow specifically.
  4. As a last resort, use the Contact Information you supplied and request a call from App Review to walk the reviewer through it live.

FAQ

Will Apple subscribe or pay to test my paid feature? No. Reviewers will not enter payment details, buy a subscription, or create their own account. Anything behind a paywall must be pre-unlocked on the demo account or shown via a reviewer/demo mode.

Do I have to upload a new build to fix this? Usually not. If the fix is purely server-side entitlements plus clearer notes, you can resubmit the same build. You only need a new build if the bypass requires a code change (e.g., a reviewer-mode mock you didn’t ship).

Can I just describe the feature in the release notes instead of unlocking it? No. Apple has to be able to actually open and use the feature during review. A description is not a substitute for access; an inaccessible feature reads as incomplete under 2.1.

My demo account has SMS or app 2FA — what do I do? Disable 2FA for that one account, or provide the current code in the Notes field in advance. Apple’s docs are explicit that an unreachable verification step will stall the review and may force a call.

Is “demo mode” an easier path than a demo account? Only if you truly can’t provide a demo account for legal/security reasons, and even then it requires prior approval by Apple and must show the app’s full functionality. For most apps, a pre-entitled demo account is faster and safer.

How long until the resubmission is back in review? After you resubmit, the status typically returns to Waiting for Review within hours to a day. If it’s time-sensitive, you can request an expedited review via Resolution Center.

Prevention

  • Maintain a “reviewer profile” seed script that runs on every release, granting every entitlement to a known email.
  • When adding any new feature gate, update the seed script and App Review notes in the same PR.
  • Add a release-checklist item: “non-dev tester signs in as reviewer profile and reaches every release-cited feature in under 2 minutes.”
  • Avoid pairing a new feature gate with a tight release deadline; gating is the top cause of preventable rejections.
  • Tag the reviewer profile account is_internal = true so it doesn’t pollute analytics or billing, and make sure it never expires.

External references: Apple’s App Review Guidelines, Guideline 2.1 (App Completeness) and the App Review Information reference in App Store Connect Help.

Tags: #Troubleshooting #App Store #App review #App review