# Skill: Prepare an app for store review by clearing every obstacle from the reviewer's path

> Enables an AI coding/design agent to run the final pre-submission pass — demo account, working features, scoped permissions, honest metadata, and a signed release build — so the human reviewer can complete their check without hitting a single barrier.

Source: sodigi·learn — publish/podgotovka-k-revyu · https://sodigi.io/learn/publish/podgotovka-k-revyu

## When to use
- A build is ready to submit and the developer wants to maximize first-try approval odds.
- The developer previously received a "reviewer could not log in" or "incomplete functionality" rejection.
- An AI-assisted (vibe-coded) app is being prepared for first submission — generated code often leaves excess permissions and placeholder screens.
- Finalizing a release build before the production publish step.

## Core rules
- A real human reviewer will open the app and navigate it by hand — every obstacle they hit becomes a rejection reason.
- The demo account is the single most common reason for a beginner rejection: if the app has a login screen, a ready-made account with full access MUST be placed in the reviewer credentials field.
- The demo account must work from a clean device with no captcha, no SMS code, and no email confirmation — the reviewer cannot receive a code sent to your phone.
- Every button and tab reachable from the first screen must lead to a working, real screen. "Coming soon" and empty states are rejection triggers.
- Request only permissions the current build actively uses; every sensitive permission needs a plain-language usage description.
- Metadata (name, description, screenshots, privacy policy link, data declarations) must match the submitted build exactly — the reviewer cross-checks the storefront against the running app.
- Submit a RELEASE build: signed, version-bumped, pointing at the production server, with debug logs and test buttons removed.
- Do not submit on a hard deadline — review times fluctuate from hours to several days; always build in a buffer.

## Procedure
1. Create or verify the demo account. It must have full access to every paid and gated feature. Log in with it from a completely clean device (fresh install, no cookies, no cached state). If third-party sign-in (Google, Apple) blocks the reviewer, add a separate username/password sign-in for review.
2. Place the demo account credentials (login + password) in the reviewer information field of the store console (App Store Connect: App Review Information; Google Play: reviewer access notes).
3. Walk every button and tab in the app from the demo account session. Confirm every tap leads to a real, functioning screen. Remove any "Coming soon" label, placeholder image, empty tab, or lorem-ipsum text from the release UI.
4. Confirm all in-app links (privacy policy, support, help) and all store listing links open the correct live pages. Fix any broken or localhost URL.
5. Open the permission manifest. Keep only permissions actively used in the current build. For each remaining permission, verify a plain-language usage description string is present.
6. Open the store listing. Check that the name, description, screenshots, privacy policy URL, and data-collection declarations all match what is in the submitted build. Fix any discrepancy.
7. Produce the release build: sign it with the correct certificate/keystore, bump the version and build number, confirm the app points at the production API (not localhost or a staging server), and strip debug flags and banners.
8. Write a short reviewer note in the same field as the demo credentials. Describe any non-obvious flow ("tap the home screen card, then tap Export to see the main feature"). Keep it to 3-5 lines.
9. Upload the release build to the store console, review all fields one final time, and submit. Do not set the release date to a hard deadline — leave buffer for at least one rejection cycle.

## Ready-to-use prompt
```
Prepare my app for store review submission. Walk through each point and tell me exactly what is missing or needs fixing:

1. Demo account:
   - Does the app have a login screen? If yes, confirm a demo account exists with full access to all paid and gated features.
   - Can the reviewer sign in with username and password only — no captcha, no SMS, no email confirmation?
   - Are the credentials entered in the App Review Information / reviewer access field in the store console?

2. Working features, no placeholders:
   - List every button, tab, and navigation item reachable from the first screen.
   - For each one, confirm it leads to a real working screen.
   - Flag any "Coming soon" labels, lorem ipsum text, gray placeholder images, or empty screens.

3. Permissions:
   - List every permission declared in the manifest or Info.plist.
   - For each one, confirm it is actively used in the current build.
   - Confirm each permission has a plain-language usage description.
   - Flag any permission that is declared but unused.

4. Metadata consistency:
   - Compare the store listing (name, description, screenshots) against the running build.
   - Flag any promise in the listing that the build does not fulfill.
   - Confirm the privacy policy URL opens without a login.
   - Confirm the App Privacy / Data Safety section matches actual data collection.

5. Release build:
   - Is the build signed with the production certificate/keystore?
   - Is the version number bumped from the last submission?
   - Is the app pointing at the production server (not localhost or staging)?
   - Are debug banners, test buttons, and console log outputs removed?

For each gap: exact location and the minimum fix required.
```

## Pitfalls
- No demo account, or the demo account requires SMS verification — the reviewer cannot receive a code to your phone and will bounce the build immediately.
- Using third-party sign-in (Sign in with Apple / Google) as the only login method — set up a plain username/password path specifically for reviewers.
- Submitting with placeholders left by an AI code generator — always walk the entire UI from the demo account on a clean device before submitting.
- Submitting a debug build instead of a release build — a test server address, debug logs, or a duplicate version number causes an automatic rejection.
- Submitting right up against a launch deadline — review times are unpredictable; one rejection cycle can cost several days; always leave buffer time.
- Writing vague or absent reviewer notes for non-obvious features — if the reviewer cannot find a feature, they cannot verify it; a short note in the reviewer field prevents guessing.