Will my app pass App Store review? Check it the way a reviewer will

Quick answer

App Review looks for an app that is complete, works with the demo account you provide, and follows the App Review Guidelines. You can check all three yourself before you submit. Install a simulator build of the exact release, walk it the way a reviewer will on iPhone and iPad, and fix what you find. Then submit with a manual release, so you pick the launch day.

Before, you found out what App Review wanted when the rejection came in. You read the message, fixed the app or the listing, made a new build, and waited in the queue again. Now you can run that review yourself first. An agent walks every screen of the exact release on an iPhone and an iPad simulator. Then you submit an app you have already seen work.

What does App Review check first?

A reviewer opens your app for the first time on a clean install. They sign in with the demo account you gave them and start using it.

Apple lists what they need from you under "Before You Submit" in the App Review Guidelines. You test the app for crashes and bugs, and you make the metadata complete and accurate. You give full access through an active demo account or a full demo mode, and you keep backend services live during review. In the review notes, you explain features that are not obvious, and in-app purchases.

A few guidelines are worth a check before every submission:

Most of these only show up when someone uses the build. A crash, a placeholder screen, a demo account that fails, a broken iPad layout, or a delete account button that does nothing waits for the first person who taps through. The best time to find them is before the reviewer does.

For the full list of rejection reasons, and how to answer one, see Why apps get rejected from the App Store and how to avoid it. If an agent wrote most of your app, also read How to get an AI-built app through App Store review.

What is the path from first build to the App Store?

A release reaches the App Store in four stages, and each one puts the build in front of more people.

It starts with your team. You put the build on your own phones with TestFlight internal testing or Google Play internal testing, which each take up to 100 testers. You test, fix, make a new build, and test again, and a few rounds of this is normal.

Next, the build goes to people outside your team. Before they can install it, Apple runs Beta App Review on the first build of every app version. On Google Play, a personal developer account created after November 13, 2023 first runs a closed test. It needs at least 12 testers, opted in for 14 days in a row, before it can apply for production access.

Then a few real testers try it, such as friends and family. They find the small things your team stopped seeing, like a button they expected somewhere else or a screen that looks wrong on their phone. See How to get app feedback from people who are not developers.

Last, you submit the version for App Review. The reviewer can ask for changes, and you make them, upload a new build if the fix needs one, and submit again. The best moment for your own rehearsal is right before this last stage, on the exact release you plan to submit.

How do you check your app the way a reviewer will?

The reviewer has none of your shortcuts. They see a clean install, the demo account from your App Review Information, and nothing that only your team knows. Your rehearsal starts from the same place:

1. Make a simulator build of the release commit. A simulator cannot install the .ipa that you upload to App Store Connect, so build the same commit with a profile that sets ios.simulator: true. Use a release build, because it carries the JavaScript bundle from build time, the same as the app you submit.
2. Start from a clean install. Use a new simulator, or delete the app first, so no saved login or cached data hides a problem.
3. Sign in with the demo account. Type the exact credentials that you give Apple. If sign-in fails, the reviewer cannot see the rest of the app.
4. Open every screen and tap every button. Look for placeholder text, empty screens with no message, buttons that do nothing, and links that go nowhere.
5. Check the flows Apple names. Check that each in-app purchase shows and works, then create an account and delete it in the app.
6. Decline each permission once. The app should keep working, with another way to do the task where it can.
7. Open the app on an iPad simulator. Walk the same screens and look for layouts that break.

Last, hold the listing up against the app. The screenshots should show the app in use, and the What's New text should name the new features. Features that need phone hardware still need a real iPhone, through TestFlight.

Can an agent run the rehearsal for you?

Walking every screen on two simulators by hand takes a while, and an agent can do it for you on Expo Simulators. You install Expo Skills, ask the agent to use the eas-simulator skill, and describe the rehearsal and the proof you want back:

Use Expo Simulators to install the iOS Simulator build of release 2.4.0 on an iPhone 17 and on an iPad mini (A17 Pro). Sign in with the App Review demo account, open every tab, try each purchase screen, and delete the account. Return a screenshot of each screen and a recording of the delete account flow. Stop each session when you finish.

The agent starts a session for each simulator, drives the app with agent-device, and brings back the screenshots and recordings. You review the proof and decide what to fix. The simulators run on EAS, so the rehearsal does not need a Mac.

If a teammate wants to walk the same build, you can start a session with --type web-preview-only and send them the link. See Share a new build with a simulator link.

How do you control when the app goes live?

Once the rehearsal passes, you upload the build and submit it. With EAS, eas build --platform ios --auto-submit builds and submits in one step, and eas submit --platform ios submits a build you already have.

Then you pick the release moment yourself, so the launch lands on the day your team planned. In App Store Connect, you select "Manually release this version," and after approval the version waits in Pending Developer Release until you release it. On Google Play, you turn on managed publishing, and approved changes wait until you publish them.

While you wait, your team can hear about the review in the channel where they already talk. EAS Workflows can start a workflow when App Store Connect reports a new state for the app version. First, connect your App Store Connect app in the EAS dashboard. This workflow posts to Slack when the version is rejected, or approved and waiting for you:

What if the reviewer sends it back?

Reviewers often come back with a question or a change, and a few rounds is part of shipping an app. You read the message, answer in App Store Connect, make the change, and submit again. A fix to the listing or the metadata may not need a new build, while a fix to the app does.

If you build apps for clients, agree on who does what before you submit, so nobody waits on the other side. The developer owns the build and every fix, and the account owner owns the listing, the privacy details, and the submit button.

Let an agent set it up

If an agent runs the rehearsal or writes the workflow, have it load these Expo Skills first:

• expo-overview: the entry point that routes the agent to the right Expo skill.
• eas-simulator: starts a cloud simulator session, drives the app, returns screenshots and recordings, and stops the session.
• eas-app-stores: builds, signing, TestFlight, and store submission.
• eas-workflows: writes the workflow that reacts to App Store Connect events.

Install them:

• Claude Code: claude plugin install expo@claude-plugins-official
• Codex: codex plugin add expo@openai-curated
• Cursor and other agents: npx skills add expo/skills

The full list is at docs.expo.dev/skills.

Try it

Expo Simulators is in a limited beta release. The docs page on letting an agent verify a change covers the prompt, access, and limits.

Try Expo Simulators

Verified on 29 October 2026.