App Review readiness

Apple rejects about a quarter of submissions, and over 40% of the unresolved issues are guideline 2.1: the app was incomplete, crashed, or the reviewer could not get in. Almost none of that is about the idea. It is about a reviewer with a few minutes, a clean device and no context, hitting something that does not work or is not explained. This skill finds those things first.

references/review-reference.md is the sourced reference (checked October 2026): the ranked rejection table, every check with its guideline and Apple link, what the App Store Connect API can and cannot set, demo account and demo video rules, and how the review process works. Its tags matter: [dev report] and [unverified] items are not Apple's word. Read the section for each step below as you reach it.

Work in the app's launch folder: findings go to store/review/audit.md, the notes for Apple to store/review/notes.txt. Paths such as ../app-store-connect/scripts/asc.mjs are relative to this skill's folder; run commands from the app's repository root with the script's absolute path.

1. The owner's part

The owner's inputs, how to check which already exist, and how to ask are all in ../app-launch/references/owner-inputs.md. The ones this skill depends on:

• Agreements, bank and tax; EU trader status. Needed unless the owner profile or a check shows them done. They are the slowest items, so they go in the day-one message.
• A demo account that works against production, with sample data, that will not expire or ask for a code the reviewer cannot receive. For features between two people: two accounts already linked. For a subscription app: one with an expired subscription. Read the sign-in code to see what kind of login it is: with a password the account is enough; with an emailed code or magic link the reviewer cannot get in, and the fix is a fixed code that works for the demo account only, which is a server change to raise with the owner early.
• A screen recording on a real iPhone, from a cold launch through the main flow, including sign-up and account deletion if they exist. Apple's own rule requires video for apps with hardware or features a reviewer cannot reproduce (a second person or device, Siri, widgets). Beyond that, developers report in 2026 that new apps, mostly on accounts with little history, get an "Information Needed" request for one before review starts; Apple publishes no such rule, and an account with approved apps is less likely to see it. So: required in the first case, cheap insurance in the second. It can only be made once a test build is on the owner's phone. Give a shot list and where to save the file; then attach it (asc.mjs attach <file>).
• Privacy label answers: you draft them from the code and the SDKs' manifests; the owner enters and attests them (no API).
• Confirmation of the age-rating answers you propose.

2. Audit the code

Go through section 3 of the reference against the repository. The reliable evidence is the resolved native config (npx expo config --type introspect for Expo), not the source alone. For each finding record the guideline, the file and line, and the fix. The checks that catch real apps most often:

• Sign-in the reviewer can pass, and the production backend the build points at is live. A staging URL in a store build is an instant 2.1.
• Account deletion inside the app wherever an account can be created (5.1.1(v)), finishing in the app, not "email us".
• An equivalent private login next to any third-party login (4.8): Sign in with Apple beside Google or Facebook.
• Permission strings that name the actual feature; no strings or background modes left by libraries the app does not use. Plugin defaults like "Allow $(PRODUCT_NAME) to access your photos" get rejected.
• The paywall (apps that sell anything): name, duration, full price as the most prominent price, what the user gets, restore purchases, working links to Terms of Use and Privacy Policy, no trial toggle, prices read from the store at runtime. The list is section 3.5.
• A privacy policy link inside the app, reachable without signing in if sign-in is optional.
• User content between people (chat, shared posts, public profiles): filter, report, block, contact (1.2).
• Personal data sent to an AI provider: disclosed, with consent before the first send (5.1.2(i), added November 2025).
• The rating prompt is the system one, never gated on a "do you like the app?" question.
• Privacy manifest: required-reason APIs declared; for Expo, reasons from libraries copied into ios.privacyManifests.
• iPad: an iPhone-only app is still run on an iPad during review. If the app declares tablet support, iPad screenshots are required and the layout is judged as an iPad app; turn tablet support off unless the app is designed for it.

A launch includes building the small things the store requires and the app lacks: account deletion, a restore button, legal links, a privacy link in settings, tailored permission strings. Do them on a branch, test what you can, and tell the owner what you added. Things that change what the app is or how people sign in (adding Sign in with Apple, a demo login path, the paywall itself) go to the owner with a recommendation first.

3. Audit the listing

Section 4 of the reference, against store/copy/ and the screenshots:

• Every feature in the text and images exists in this build. Search the code for each one.
• More than half of each locale's screenshots show the app in use. A statement first image is fine; a set of marketing panels is not.
• No prices, no "free", no other platforms, no competitor names, no unverifiable claims in the name, subtitle, keywords or images.
• Subscription apps: Terms of Use and Privacy Policy links in every localized description.
• Support URL opens and shows a real way to reach the developer. Privacy URL opens. Open them; do not assume.

4. Audit App Store Connect

node ../app-store-connect/scripts/asc.mjs preflight

lists what the API can see is missing. What it cannot see, and you must confirm another way (section 5 of the reference): agreements, tax and banking, trader status, the privacy labels, and that in-app purchases are attached to the first version's submission. Those live in the web interface; reading them is a computer-use task (../app-launch/references/computer-use.md) in the owner's signed-in browser, or a question to the owner.

In-app purchases on a first release are a special case: the first product of each type must be submitted together with the app version, and products must be "Ready to Submit". A version approved without its products ships a paywall that sells nothing. See ../revenuecat-setup/SKILL.md.

5. Write the review notes

The reviewer reads the notes before opening the app. Write store/review/notes.txt (4000 bytes at most) in plain sentences. This list is complete; the reference's section 5.4 only adds Apple's sources for it:

1. What the app is, who it is for, and how it makes money, in two or three sentences.
2. How to sign in (the demo account is in its own fields), and any code needed.
3. Where each main feature is, as taps: "Home > Ready-lists card > pick a list".
4. Where the paywall is and how to reach it; which features need the purchase.
5. Anything that needs a second person, device or account, and how to see it anyway (a second demo account, or the attached recording).
6. Services the app relies on (sign-in provider, payments, AI), and that the backend is live.
7. Anything that looks like a rule problem but is not, explained before it is asked: a background mode, a permission, why login is required.
8. For an update: what is new in this version and where to find it. Generic notes are rejected.

Be specific and honest. If a feature cannot be exercised with one account, say so and say what the reviewer will see.

6. Before the owner says "submit"

Give the owner one short readiness report:

• Blocking: things that will be rejected as they stand.
• Risks: things that might be, with the guideline.
• Not verified: what no one has tested. Typically: the production build against the production backend, purchases in sandbox, anything needing a device. Do not round this down. "Never opened on a device" is a fact the owner needs before choosing to submit.
• Waiting on the owner: the inputs from step 1 still open.

The backend the build talks to must be deployed and healthy before submission, because review runs against production (../app-launch/references/release-sequencing.md). Submitting is asc.mjs submit --confirm <version>, and only after the owner says to, for that version.

7. After submitting

• Check state with asc.mjs submission. Apple's goal is half of submissions within 24 hours and 90% within 48; first submissions of new apps have taken much longer. Do not promise a date.
• Do not publish an over-the-air update to the reviewed channel, and do not change the demo account or the backend in ways the reviewer would notice, while it is in review.
• On a rejection: read the full message (Resolution Center; a computer-use read if you cannot see it), match it to the reference, and separate three cases. Information needed: reply with the answer or the recording, do not resubmit. Metadata: fix it and resubmit the same build. Binary: fix, new build, resubmit. Draft the reply for the owner: short, factual, saying what was changed or where the thing they could not find is. Appeals and phone calls are made in the owner's name; propose them, do not start them.
• On approval with manual release, the owner releases (asc.mjs release --confirm <version> on their word). If a backend deploy was waiting on approval, it goes out before the release.