LaunchLint Academy
The short answer
- App Review notes explain review-specific context only: access, navigation, prerequisites, non-obvious features, digital purchases, and changes after a prior rejection. Do not repeat the store description.
- Provide a durable demo account or approved fully featured demo mode, keep the backend available during review, and test the documented route on a fresh device with the exact submitted build.
- Write briefly and verifiably. Name the build, menu path, expected state, and special conditions. Never place production API keys, internal admin access, or real customer data in the notes.
1. What App Review notes are for
Apple asks for detailed explanations of non-obvious features and in-app purchases. Notes are part of the non-public review details alongside contact information, demo credentials, and optional attachments. Their job is to prevent avoidable questions and blocked test paths.
They are not a second product description. ‘Our app uses advanced AI and works completely’ is useless to a reviewer. ‘The PDF export appears after selecting Demo Project under Projects > Demo Project > Export; no purchase is required’ is testable.
2. Minimum information for every submission
Review details include a contact name, phone, email, and whether a demo account is required. Keep them current and monitored. An unreachable contact can delay review. Prefer a durable team address over a personal disposable inbox.
Start notes with version and build, then state only changes and prerequisites relevant to that artifact. Do not invent explanations for self-evident features. Review the text every release and remove stale paths.
Minimum:
- Version and build number
- One factual sentence about the main change
- Current demo account or demo mode
- Shortest navigation to the core feature
- Any role, region, QR code, or hardware
- IAP visibility and prerequisites
- Monitored review contact
3. Build a demo account that survives review
Apple expects an active demo account or fully featured demo mode for account-based features. It should not depend on your phone, short-lived email, manual admin approval, or expiring magic link. Keep the backend and required media online during review.
Seed safe fictional data that exposes relevant states. An empty dashboard can look incomplete. Decide whether one account can show every role or whether clearly labeled accounts are needed. Test credentials outside your company network immediately before submission.
- No personal user account
- No production customer data
- Stable password and monitored recovery
- Documented route through any 2FA
- Seeded empty and filled states
- No automatic cleanup during review
- Backend monitoring and owner
4. Describe non-obvious flows precisely
A reviewer should not guess when a feature flag activates, which role sees a control, or why a feature requires a QR code, location, Bluetooth device, or approved content. State prerequisite, navigation, action, and expected result in that order. Attach a fictional sample file or QR code when needed.
For permissions, name the user feature rather than only the system prompt. For account deletion, provide the path. For user-generated content, show reporting and blocking. For regional behavior, name the active demo region. Keep the critical step visible.
| Vague | Testable note |
|---|---|
| Login works | Sign in with the demo account; Projects opens with two samples |
| Camera required | Project > Scan receipt opens the camera to capture a receipt |
| Deletion exists | Settings > Account > Delete account; confirm with password |
| Premium is testable | Demo account has a test subscription; export is in Demo Project > Export |
5. Make purchases and subscriptions reviewable
In-app purchases submitted for review must be complete, current, visible, and functional. If a configured product cannot be found, explain why. This applies to paywalls shown after a usage limit, region-specific products, or purchases requiring a role.
Name the visible product and path, not only an internal identifier. Test restore, active subscription, failed purchase, and reinstall. If the demo account already owns premium, explain how the reviewer can still see paywall and restore without altering production data.
- Products ready with the build
- Agreements and tax state active
- Paywall reachable in demo flow
- Visible terms match configuration
- Restore testable
- Sandbox state verified
- Special condition explained in one sentence
6. A practical review-notes template
Use a repeatable structure without shipping unchanged boilerplate. Remove irrelevant sections and update the build, paths, and accounts. Simple English is often the clearest common language for an international team; precision matters more than polish.
BUILD
- Version / build: [1.0.0 / 42]
- Main change: [one factual sentence]
REVIEW ACCESS
- Demo account: [dedicated review account]
- Path: Launch app > Sign in > [feature]
- Required role or setup: [only if applicable]
NON-OBVIOUS FLOWS
- Purchase appears when: [condition]
- Account deletion: Settings > Account > Delete account
- Permission purpose: [feature and user value]
CONTACT
- Name: [responsible person]
- Email / phone: [monitored during review]Keep the template in the release process, not as a hard-coded secret. Internal checklists may list fields, but live credentials belong in a secure controlled workflow and only in the intended App Store Connect field. Check for stale build numbers after pasting.
7. Reply after rejection with facts and evidence
After rejection, you can reply and attach supporting material before resubmission. Read the cited guideline and test path, then reproduce it with the rejected build. A metadata-only issue may allow the same build; code and native configuration changes require a new binary.
Reply with cause, change, and verification. Example: ‘The account in the notes had expired. We replaced it and tested build 42 on a fresh device. After sign-in, Projects > Demo Project opens Export without another invitation.’ Ask for exact steps when the message cannot be reproduced.
- Save the complete reviewer message
- Reproduce in the named build
- Finish fix or metadata update
- Run regression on a fresh device
- Update notes and credentials
- Name build and navigation
- Attach only relevant evidence
- Never promise guaranteed approval
Frequently asked questions
Should review notes be in English?
Apple does not impose one universal language. Clear, simple English is usually robust for international review teams. Exact paths, current credentials, and understandable prerequisites matter most.
May I put test credentials in the notes?
Yes when needed for a controlled demo account. Never include API keys, admin tokens, production data, database access, or other infrastructure secrets.
Do I need notes when the app has no login?
Not necessarily long notes. Still describe non-obvious features, purchases, hardware or regional prerequisites, and relevant changes. Concise accurate text beats irrelevant boilerplate.
Can a screenshot replace a new build?
It can support context, not replace a required code or native configuration fix. Metadata-only issues may sometimes be resubmitted with the same build after correction.