storebound/skills/review-access/SKILL.md

name

description

review-access

Give App Store and Google Play reviewers working access to an app behind a sign-in - a demo account that never expires and needs no 2FA, App Review demoAccountName / demoAccountPassword through storebound apple review-details (credentials only in .storebound/credentials.json or env, masked in logs), the Play App content "App access" declaration (console only), and notes that say where every feature is. Use when the app needs a login, after a Guideline 2.1 "we were unable to sign in" rejection, or a Play "App access" policy issue.

Review access (demo account)

storebound scan flags a sign-in (config, auth SDKs, sign-in code) without reviewAccess or without the demo account (2.1(a), Play App access).

Sources: App Store Review Guideline 2.1 (https://developer.apple.com/app-store/review/guidelines/), App Review Information (https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information), Google Play sign-in details (https://support.google.com/googleplay/android-developer/answer/15748846 and https://support.google.com/googleplay/android-developer/answer/9859455).

Rules from the stores

• The account must work for the whole review, must not expire, needs no 2FA / one-time code (or give a bypass), and must reach every feature, paid ones included (sandbox purchases work on Apple's side).
• Apple: sign-in required + user name + password in App Review Information, plus notes (up to 4000 bytes). Keep your backend live. A demo mode instead of an account is possible only when Apple approves it.
• Google Play: Policy and programs > App content > App access: "All or some functionality is restricted", then the credentials and steps (in English). There is no API for it.

Never commit credentials

The demo account lives only in the project's gitignored .storebound/credentials.json: "reviewDemoAccount": { "username": "demo@example.com", "password": "..." }, or in REVIEW_DEMO_USER / REVIEW_DEMO_PASSWORD. Never ask for it in chat, never write it into the config, docs, issues or commits. The owner creates the account and pastes it into that file. storebound prints it masked (d***@example.com / ********).

Steps

1. Create a dedicated demo account with realistic sample data (no real user data), on production.
2. Config: reviewAccess: { signInRequired: true, instructions: 'Sign in with the demo account, then ...' }. storebound check errors while the demo account is missing.
3. storebound apple review-details --dry, then without --dry: sets demoAccountRequired, demoAccountName, demoAccountPassword, the contact and the notes (review notes + instructions + where account deletion is).
4. Play: App content > App access with the same credentials and steps (agent with browser tools or the owner).
5. storebound validate: blocker when sign-in is required and App Review has no demo account.
6. Before each submission sign in with it on a clean device; reset its data if a test changed it.

Gotchas

• A password change or an expired trial on the demo account means a rejection: tell the owner to keep it stable.
• Region locks, IP allow-lists or SMS checks block reviewers; switch them off for the demo account.
• If sign-in is optional (everything works signed out), set signInRequired: false; the demo fields are cleared.
• No sign-in but a first screen that can look like one (a name to type before Continue, an "I have a code" link, in-app purchases): keep signInRequired: false and write guest steps into reviewAccess.instructions (English, at most 500 characters). Play's Sign in details then gets one entry "Guest play (no account needed)" without credentials (storebound console plan play-sign-in-details); a guest-play game declared "no restrictions" was rejected as a login wall (store-pitfalls 73). Pre-fill the name so Continue is enabled at once.