When a reviewer cannot test your app
These apps are rejected for being untestable, not for being wrong, and the fix is a route rather than a redesign.
The pattern: the reviewer opens the app, cannot reach the thing it is for, and files it under Guideline 2.1 App Completeness with a screenshot of an empty screen.
Five shapes, one answer each:
Needs hardware. A demo mode with simulated device data, plus recorded footage of the real thing.
Needs a real customer or job. A demo account seeded with realistic data, so every screen has content. The empty screen is the failure, not the missing customer.
Needs a paid account or a subscription. Provide credentials with the entitlement already granted. A reviewer cannot evaluate what is behind a paywall they cannot pass.
Needs a specific country or region. Say so, and provide a way to see it anyway.
Needs another person. Two accounts, or a demo mode that simulates the other side.
And the self-inflicted version that is more common than all five: a demo account that expired, hit a rate limit, or had its data reset between submission and review. Verify it on the day you submit, and again if the review runs long.
Seeding a demo account properly
This is the part teams do badly. A demo account with an empty dashboard is worse than no demo account, because it demonstrates an app that appears to do nothing.
Seed every screen:
- Several records, not one, so lists look like lists.
- Data spread over recent dates, so charts and history render.
- At least one item in every state your UI can show.
- Realistic names and values. Not "Test 1", "Test 2", "asdf".
- Any entitlement or role needed to see the full app.Then open the app with that account yourself, on a fresh install, and look at every screen. The screens that look broken to you look broken to a reviewer, and they are the ones the rejection will be about.
The review notes
Specific, numbered, and honest about what cannot be done:
This app schedules and invoices in-person jobs, so parts of the
flow correspond to work that happens off-device.
Demo account: [email protected] / [password] (verified working
today). It is seeded with 12 jobs across the last 3 weeks,
2 quotes and 1 paid invoice.
To see the main flow:
1. Sign in. The Today tab lists scheduled jobs.
2. Open the job on [date] and tap "On my way" — this sends the
customer an SMS in production; on this account it is stubbed
and shows a confirmation instead.
3. Tap "Mark complete" to reach the invoice screen.
4. The payment step uses Stripe test mode on this account; card
4242 4242 4242 4242 will succeed.
What cannot be tested here: the physical job itself, and live
SMS delivery, which requires a registered business number.
Screen recording of both attached.Naming what cannot be tested is the part that works. A reviewer told plainly which steps are off-device stops trying to find them and evaluates what is there. A reviewer left to discover it concludes the app is incomplete. Review notes that work.
Demo modes worth building
A stubbed integration. Third-party services that cost money, need registration or require a real counterparty. Stub them for the demo account and show a clear confirmation.
Simulated hardware data. Recorded or synthesised readings, so the whole flow renders.
A guided tour. Optional, and genuinely useful for a complicated app.
A test-mode payment path. So a reviewer can complete a purchase flow without a real charge.
All four are also useful for your own testing, which is why they are worth building rather than being a compliance tax.
Video, and its limits
A screen recording of the full flow helps a great deal, particularly for hardware.
It rarely substitutes for a reachable flow, because a reviewer who can see it working in front of them is answering a different question from one being told it works. Provide both where you can.
Keep it short, show the whole path end to end, and do not narrate the marketing.
Verify on the day
The most common failure in this whole category is preventable in sixty seconds:
1. Fresh install of the exact build you submitted.
2. Sign in with the demo credentials from the review notes.
3. Walk the numbered steps you wrote.
4. Do it again the day the review starts if it has been a while.A demo account that worked in the sprint and not on review day is a full cycle, and it is the version that feels worst because nothing was wrong with the app. What a rejection actually costs. · After a rejection.
shipcheck reports whether review notes and demo credentials are present in your submission metadata, and flags features behind an entitlement with no test path. It cannot log in for you, which is why the sixty-second verification stays yours. What it checks. · The first-submission checklist.
More in this section
- When a dependency is blocking your release
- Writing store copy that survives review
- The annual OS release: what actually changes for a React Native app
- Universal links: the setup that fails without an error
- TestFlight beta review: what it actually checks
- Submitting an AI app: what applies, all at the same time
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
What happens if App Review cannot test my app's main feature?
It is usually rejected under Guideline 2.1 as incomplete, because a reviewer who cannot reach the feature cannot evaluate it. The rejection is about testability rather than about the app being wrong, which is why the fix is providing a route rather than changing the product.
How do you demo an app that needs hardware?
Provide a demo mode, a simulator or recorded footage that shows the full flow, and say in the review notes exactly how to reach it. Apple can also be sent hardware in some cases, and a demo path is faster and usually sufficient.
What about an app for a service that has to happen in person?
Give a demo account seeded with realistic data so every screen has content, and explain in the notes which parts represent real-world steps the reviewer cannot perform. Empty screens are the actual failure, not the missing service.
Does a demo account need to be permanent?
It needs to work on the day and to keep working through the review, including after a rate limit or a data reset. A demo account that expired between submission and review is one of the most common self-inflicted rejections.
What if the app only works in one country or region?
Say so in the notes and provide a way to see the experience anyway, whether that is a demo mode, a test account provisioned for that region, or a recording. A geographic restriction the reviewer discovers on their own looks like a broken app.
Is a video enough on its own?
It helps a great deal and it rarely substitutes for a reachable flow. Provide both where you can, because a reviewer who can see it working is answering a different question from one being told it works.
shipcheck. “When a reviewer cannot test your app.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/guides/when-a-reviewer-cannot-test-your-app/