Expo Simulators: Give Your AI Coding Agent a Cloud iPhone and Make It Prove Its Fix

Expo Simulators gives an AI coding agent a remote iOS Simulator or Android Emulator, so it can run your app, click through it and send back screenshots and recordings as proof that its change works. Expo documents the flow in a verify-a-change guide. The agent needs no Mac, and a human can open the same session in a browser to check the evidence. Access is early, so read the limits section before you plan around it.

The problem it targets is familiar. Coding agents write mobile code faster than teams can review it, and a diff does not show whether a screen still renders or a crash is gone. Recorded evidence from a real simulator closes part of that gap.

TL;DR

How the workflow runs

Expo's guide lists six steps for the agent:

1. Check availability with eas simulator:availability --json. If Expo Simulators is not enabled for the account, the agent tells you and falls back to a local simulator or emulator.
2. Choose a build. Live edits use a development build with Metro. A fixed screenshot uses a build that matches the current source.
3. Start a named session and confirm its status is IN_PROGRESS.
4. Install and open the app, then drive it with agent-device commands such as snapshot -i, press and fill.
5. Capture evidence: screenshots for still states and recordings for motion.
6. Stop the session and reset .env.eas-simulator.

Expo advises using the skill, not individual commands, because the simulator:* commands are new. The skill carries the steps for the access check, build choice, session, controller, evidence and cleanup, and tells the agent to check --help when a command fails. We covered the skills package in our Expo Skills install guide.

Setup

The guide lists three requirements:

• Install Expo Skills, then ask your agent to use the eas-simulator skill.
• Authenticate EAS CLI and link the project to Expo Services. On your computer, run eas login. In a cloud sandbox, CI job or background agent, set the EXPO_TOKEN environment variable to an Expo access token.
• Confirm the setup with npx --yes eas-cli@latest whoami and npx --yes eas-cli@latest simulator:availability --json.

Treat the access token like any secret. A token in a background agent can start billable sessions, so keep it scoped and out of logs.

What to ask the agent for

Expo suggests describing the result and the evidence you want. Its examples:

• Verify a feature: open the app on iOS, test a new checkout flow, and return a screenshot of the confirmation screen.
• Reproduce a bug: reproduce an issue on an Android session, record the steps, and stop the session afterward.
• Check an animation: record a sheet transition on an iPhone session and check the frames for visible jank.
• Iterate live: start a development build with Metro, fix a layout, and show the preview link.

Watching the agent work

The start command prints a browser preview URL. You can open it in a desktop browser, or in Cursor or VS Code's Simple Browser panel, though you may need to sign in to expo.dev with project access. The session page has an Open preview button. To follow controller actions live, run eas simulator:events --follow in another terminal. That live view is what makes the evidence trustworthy: you can see the agent drive the device instead of taking its word.

A bug-to-pull-request example from Expo

Expo engineer Rami Maalouf published a worked example on September 22, 2026 in What if your app could fix itself?. The bug report says "Settings crashes when I scroll to the bottom," with no reproduction steps. The sample app is a habit tracker. The flow:

1. A maintainer adds the repro label to the GitHub issue.
2. A GitHub Action forwards the issue number to EAS Workflows.
3. The workflow checks out the repo, installs dependencies and starts Claude Code.
4. The agent installs the app on EAS Simulator and opens Settings. The app crashes immediately, before any scrolling.
5. The agent posts reproduction steps, observed behavior and a session link on the issue.
6. It finds the cause, applies a fix, rebuilds and installs the app in a second session.
7. In that session it opens Settings and scrolls to the bottom, and the screen loads without crashing.
8. It opens a pull request with the cause, the change, before and after screenshots and links to both sessions.
9. A person reviews the diff and decides whether to merge.

Expo reports that all 22 Settings tests pass, and lint and typecheck pass. The setup uses Callstack's agent-device CLI, the eas-simulator skill, a GitHub Action file, an EAS Workflow file and an agent prompt file. The prompt requires a reproduction session URL, a verification session URL, before and after screenshots, and logs or tests for nonvisual behavior.

Expo describes safeguards. If the agent cannot reproduce the bug, it reports what it tried and stops. If the fix fails verification, it reports that and opens no PR. It does not merge, and Expo says to enforce that with repository permissions and branch protection. This is a vendor demo on a small sample app, so treat the result as a pattern and not a measured success rate.

Limits and cost control

The guide states these limits:

• A session runs until it is stopped, reaches its maximum duration, or hits its idle limit.
• Ask the agent to stop each session when it finishes or fails, and to run no more than one at a time unless the task needs more.
• Add --max-duration-minutes so a forgotten session stops on its own.

Billing sits on a separate usage page that we did not read. The Expo blog says EAS Simulator is in early access with a waitlist, and a search of Expo's pages showed the product named differently in places, so check the current name and your account's access before you build a pipeline on it.

A prompt you can adapt

Expo's examples share a shape: name the platform, name the action, name the evidence, and say when to stop. Adapting that for your own app gives a prompt like this one, which is our paraphrase and not Expo's text:

Use the eas-simulator skill. Check availability first. Start one iOS session with a maximum duration of 20 minutes. Install the current build, open Settings, scroll to the bottom, and record the whole sequence. Return the recording and a screenshot of the final screen, then stop the session. If you cannot reproduce the problem, say what you tried and stop.

Each clause maps to a rule in the docs. The skill name triggers the right steps. The availability check avoids a failed run. The duration flag limits cost. The recording is the evidence. The last sentence mirrors the demo's behavior of stopping without a pull request when nothing reproduces.

Cloud simulator or local simulator

A local simulator is free and fast for one developer, but it needs a Mac for iOS and ties up your machine. Expo's cloud option removes the Mac requirement and gives reviewers a shareable link, which matters for background agents that run in CI or a sandbox where no simulator exists. The trade is cost, a session limit and early-access status. For many teams the sensible split is local simulators for interactive work and the cloud for unattended agent runs where a recording is the deliverable. Expo's own guide takes this view in one place: if Expo Simulators is not available for the account, the agent falls back to a local simulator or emulator.

Why it matters

Agents that write code but cannot run it produce unverified diffs. Agents that can run it on a real device produce evidence a reviewer can check in seconds. That shifts review from reading code to watching a clip. It also fits the trend toward background agents that work from issues, as in our post on agent autoloop with GitHub issues and approval cards, and the practice of running several agents in parallel with Worktrunk. For Expo's other agent-oriented work, see Expo Exact.

What to check before you adopt it

1. Access. Run eas simulator:availability --json on your account first.
2. Secrets. Give the agent a scoped token, not a personal one.
3. Review rules. Block agent merges with branch protection, as Expo advises.
4. Cost. Read the usage and billing page and set a maximum duration on every session.
5. Evidence quality. Make the prompt demand both a before and an after recording, so a clip proves a change and not just a state.
6. Fallback. Keep a local simulator path for when the cloud service is unavailable.

Related reading

• Expo Skills: official agent skills and install guide
• Expo Exact: agent-native cross-platform runtime
• Worktrunk: git worktrees for parallel AI agents
• Agent autoloop with GitHub issues and approval cards
• Claude Code token efficiency and prompt cache guide
• AWS Bedrock cost per task for agents

This post reflects Expo documentation available on November 12, 2026. Product names and access may change.