Agentic mobile CI/CD with EAS Workflows and Expo Simulators

Quick answer

A team on Expo describes its pipeline in YAML files in .eas/workflows, and EAS Workflows builds, tests, submits, and updates the app on EAS-hosted macOS and Linux workers. Agentic mobile CI/CD puts an agent to work in that same pipeline. The agent writes and fixes the workflow files, reads what failed, checks its change on a cloud simulator, and brings the proof to the pull request. The person who approves the release starts from that evidence.

Before, every change waited on a person at each step of the pipeline. Someone read the failed build log, fixed the workflow, pulled the branch, and opened the app to check it. Now the agent can do that work inside the pipeline. Then the person reviews the proof and approves the release, so their time goes to the decision.

A mobile pipeline has more steps than most, such as native builds for each platform, code signing, store submission, and over-the-air updates. For the basics, see What is mobile CI/CD?

What does a mobile pipeline look like on EAS Workflows?

Say a teammate merges to main. On EAS Workflows, a YAML file in .eas/workflows decides what happens next: which events start the workflow, and which jobs run. A workflow can start on a push, a pull request, a label, a pull request comment, a cron schedule, an App Store Connect event, a REST API call, or eas workflow:run. The builds, updates, test results, artifacts, and logs all show on expo.dev, so the whole team sees the same run.

You build most stages from pre-packaged jobs, and custom jobs run any command you need:

Here is that teammate's merge as a workflow. When the native code has not changed, it ships the JavaScript as an update. When the native code changed, it builds, waits for a person to approve, and submits:

For how EAS Workflows compares with Bitrise, Codemagic, and GitHub Actions, see How to set up CI/CD for a mobile app.

Where does the agent work in the pipeline?

You can put the agent to work in three places: before the pipeline runs, while it checks a change, and after the results come back. Each one takes a step that used to wait on a person.

1. The agent writes and fixes the workflow

Workflow files break like any other code, and the agent can fix them. The eas-workflows skill teaches an agent the workflow syntax. With it, the agent can write a new workflow or repair one that fails. Through the Expo MCP Server, the agent can create a workflow file, validate it, run it, list recent runs, and read the logs of a failed job or build. A prompt can read like this:

Add a workflow that makes an iOS Simulator build on every pull request and posts the build on the pull request. Validate it before you commit it.

The workflow change then goes through review like any other pull request. You still approve the pipeline itself, the same way you approve app code.

2. The agent checks its change on a running app

Maestro checks the flows you know to test, and the agent checks the change it just made. For that, the agent needs the app running, and a CI machine or a cloud agent's sandbox usually has no iOS Simulator. Expo Simulators gives it one on EAS. A CI job can start a session, install a build, run checks, and stop the session, with no macOS on the CI machine.

In EAS Workflows, a get-build or build job finds or makes the iOS Simulator build. A later custom job starts the session with the commands from the Expo Simulators CI docs:

The stop command goes in a step that runs even when an earlier step fails. In EAS Workflows, that means adding if: ${{ always() }} to the step:

A CI job that ends does not stop the session, so always set --max-duration-minutes. For a full CI example, see How to run an iOS Simulator in GitHub Actions with Expo Simulators.

3. The pipeline sends results back to the agent

Once a run finishes, the results have to reach the agent where it can read them. On the pull request, the github-comment job posts each build and update. The agent, or your CI job, adds its screenshots and recordings from the simulator session.

App Store Connect can start the next step too. You connect your App Store Connect app in the EAS dashboard, and the app_store_connect trigger starts a workflow on its events. A workflow can start when the app version is rejected or waits for your release, when a build upload finishes, when an external beta is approved, or when a tester sends TestFlight feedback. The Expo MCP Server also lets an agent read TestFlight crashes and TestFlight feedback.

From production, EAS Observe reports the errors that real users hit, and an agent can read them with the eas observe commands. See Build an agent loop that fixes mobile bugs and proves each fix.

What stays with a person?

At the end of every run, a person makes the call. They merge the pull request and approve the release, and a require-approval job holds the workflow until someone approves or rejects. For more on where to keep a person in the loop, see What is an agentic workflow for mobile development?

Let an agent set it up

Have the agent load these Expo Skills first:

• expo-overview: the entry point that routes the agent to the right Expo skill.
• eas-workflows: writes and debugs EAS Workflows YAML.
• 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-update: publishes over-the-air updates.

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. Start with Introduction to EAS Workflows and Run Expo Simulators sessions in CI.

Try Expo Simulators

Verified on 29 October 2026.