CRT
ae58948abd
Detects the stack (native iOS / Android, React Native, Expo, Capacitor, Cordova, Flutter, Unity, Godot) and the SDKs from a maintained table with versions, file:line and each vendor's disclosure page, then reports App Store and Google Play rejection risks with guideline, evidence, fix, severity and skill: 2.1(a) demo account and placeholder text, 5.1.1(v) account deletion, 4.8 login services, 3.1.1 restore and outside payments, 3.1.2 subscription info, 5.1.2(i) ATT, purpose strings, privacy link, privacy manifest, 2.3.10, 2.3.7, 2.3.8, 4.2 web wrappers, 2.5.1, 2.5.5, ATS, export compliance, 1.3 kids ads, review prompts, privacy labels vs SDKs; Play target SDK 36, delete-account URL, App access, foreground services, exact alarms, QUERY_ALL_PACKAGES, SMS / call log, com.example package name. Proposes Data safety / App Privacy / ATT / privacy manifest answers (detected file:line or ask owner) as a diff against the config; --write adds only the detected ones. scan.ignore records owner-accepted findings. MCP tool scan (read-only), validate includes open findings, desktop Checks tab shows them. Fixtures for iOS, Android, Capacitor, Unity, Flutter, clean and teaser.
42 lines
3.3 KiB
Markdown
42 lines
3.3 KiB
Markdown
---
|
|
name: review-access
|
|
description: 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.
|