A user files a bug report that says "Settings crashes when I scroll to the bottom." No stack trace, no reproduction steps, no screen recording. You're now the one who has to reproduce it, guess at the cause, and hope you got the right fix before you ship it.
EAS Workflows and EAS Simulator let an agent do that investigation instead. It reproduces the bug on a cloud simulator, proposes a fix, and opens a pull request with recordings showing the app crashing before the fix and working after it. You review the evidence and decide whether to merge.
The payoff in the example below: a labeled GitHub issue turns into a PR where all 22 Settings tests pass, with two simulator sessions attached so you can watch the before and after yourself.
EAS Simulator is in early access. Here's how the two pieces fit together on a real Settings crash.
What's actually happening here
EAS Workflows runs the agent on Expo's infrastructure, the same way it runs your builds and submissions. EAS Simulator gives that agent an actual device to install the app on, tap through screens, and confirm whether a fix works, all in the cloud, without anyone needing a local iOS Simulator.
Put together, a bug report stops being a description someone has to interpret. It becomes a task an agent can execute and prove it executed correctly.
Start with the bug report
Adding the repro label to a GitHub issue kicks off a workflow that hands the report to Claude Code. The agent's job: reproduce the failure, find the cause, verify a fix on the simulator, and only then open a PR.
You can look at the real example in issue #9 and PR #10 of the sample repo.
Watch the agent reproduce it on a real device
The agent installs the app on EAS Simulator and opens Settings. It crashes immediately, before any scrolling happens, which is more precise than the original report suggested. The agent posts its steps, what it observed, and a link to the session recording directly on the issue.
That interaction runs through agent-device, Callstack's CLI for device automation. It's what lets the agent inspect screens, tap through the app, and capture screenshots on EAS Simulator, and the session replay is what lets you check its work afterward instead of taking it on faith.
Get proof the fix actually works
Once the agent finds the cause and applies a fix, it rebuilds the app and installs it in a fresh simulator session. Same steps: open Settings, scroll to the bottom. This time nothing crashes.
The resulting PR bundles all of it: the root cause, the code change, before-and-after screenshots, and links to both simulator sessions. It also reports that all 22 Settings tests pass, plus lint and typecheck. You get to trace the whole path, from the original report through the fix, and watch the patched app take the same steps that used to crash it. That review happens in a browser, on macOS, Windows, or Linux.
Wiring it up to your own repo
Three pieces make this work. A GitHub Action forwards the labeled issue number to EAS Workflows. An EAS Workflow checks out the repo, installs dependencies, and starts the agent. And an agent prompt tells it what to investigate and, just as important, what evidence to bring back: a reproduction session URL, a verification session URL, and before/after screenshots.
The prompt also covers failure paths. If the agent can't reproduce the bug, it reports what it tried and stops there, no PR. If its fix doesn't hold up on the simulator, it reports the failed verification instead of pretending everything's fine. For bugs that aren't visual, the prompt asks for logs or regression tests alongside the screenshots.
To adapt this to your own app, you'll need your build profile, navigation context, and credentials for Expo, GitHub, and whichever agent you're running. The eas-simulator skill gives the agent the operating instructions it needs for simulator sessions.
One boundary worth keeping: the prompt tells the agent to leave merging to a human. Back that up with repository permissions and branch protection, not just good intentions in a prompt file.
This pattern was inspired by Nathan Schroeder's post on X.
Limitations
EAS Simulator is in early access, so expect rough edges and access gated behind a waitlist. The agent's ability to reproduce and fix bugs depends heavily on how well your prompt describes the app and what "done" looks like. This isn't a replacement for triage on ambiguous or intermittent bugs, it's built for cases where a clear failure can be reproduced and checked on a device.
Where to start
Pick a bug you can reliably recognize when it happens, and confirm your app builds and runs on the simulator. Decide what a useful reproduction should show before you wire anything up. Then use the example repository as a template to connect your own issue tracker to an agent.
You don't have to go all the way to auto-generated fixes on day one. Start with reproduction alone, and add the fix-and-verify step once you trust the evidence it's producing.
Request access to EAS Simulator by joining the waitlist. If you want to run cloud simulators from your own machine outside of this workflow, read You don't need a Mac to develop iOS apps.
This post is based on content from the Expo blog. Follow @expo for more React Native content.
Top comments (0)