TL;DR
- A black-box driver can test a compiled Expo or React Native binary without adding a native test SDK or ejecting from Expo’s managed workflow. Expo’s EAS end-to-end testing workflow uses an installable iOS
.appor Android.apk. - Detox uses gray-box access and requires native build configuration. Appium uses WebDriver and requires you to configure platform drivers and maintain locators.
- Maestro uses readable YAML flows. Platform differences may require separate flows, and selectors based on visible text can break when interface copy changes.
- Momentic stores plain-English YAML tests in your repository and uses the same test format and hosted runner for iOS, Android, and web. Momentic executes mobile tests on hosted simulators and emulators and can update a test when an interface change invalidates an existing step.
- The Momentic CLI and MCP server let coding agents run tests and inspect failures through screenshots and traces.
How Appium and Detox fit an Expo workflow
End-to-end testing of an Expo app should exercise an installable build rather than the shared Expo Go client. Expo’s EAS testing guide uses an Android .apk or iOS simulator .app that EAS can install on an emulator or simulator. Expo Go runs your JavaScript inside a shared development client, so it does not exercise your app’s standalone native build.
Detox uses a gray-box architecture that coordinates test actions with activity inside the app, which requires native test configuration. An Expo project therefore needs a Detox-compatible build and platform-specific configuration before tests can run. Detox can provide useful synchronization for React Native apps, but that native integration adds work for a project that otherwise stays within Expo’s managed workflow.
Appium drives apps through its WebDriver-based automation architecture , using platform drivers such as XCUITest or UiAutomator2. You must install and configure the Appium server, the relevant drivers, and the simulator or emulator environment. Tests commonly locate React Native elements through accessibility identifiers derived from testID props. XPath remains available, but selectors tied to the rendered accessibility hierarchy can break when a component or layout changes.
Both approaches create maintenance beyond writing user flows. Detox adds native build configuration that must keep working across Expo and React Native upgrades. Appium adds driver management and locator repair, especially when tests depend on structural XPath expressions. CI failures then require someone who understands the runner, device state, and selector strategy. A small engineering group may assign that responsibility to one engineer, which can concentrate maintenance knowledge.
Detox and Appium remain reasonable choices when you need their architecture, integrations, or existing ecosystem. For an Expo managed project, an external driver can test an installable binary without adding a native test SDK. This approach also avoids maintaining a WebDriver installation when the selected tool does not use one.
The four ways to drive a built Expo binary
The four tools differ in how they access a built app, what native configuration they require, and whether a test can cover multiple platforms. Detox uses a grey-box model and requires native build configuration. Appium drives each binary externally through WebDriver but requires you to maintain drivers and selectors. Maestro defines tests as YAML flows against built binaries, and may need platform-specific flows when the interfaces or behavior differ. Momentic drives binaries externally with plain-English YAML tests, and the same format covers iOS, Android, and web. Maestro defines tests as YAML flows against built binaries, and may need platform-specific flows when the interfaces or behavior differ. Momentic drives binaries externally using one plain-English YAML suite for iOS, Android, and web.
Detox, Appium, Maestro and Momentic compared
| Tool | Architecture | Native requirement | Coverage per suite | Authoring | Maintenance | Device target |
|---|---|---|---|---|---|---|
| Detox | Gray-box | Detox-compatible native build and configuration | iOS and Android | JavaScript or TypeScript | Manual configuration, selectors, and upgrades | Simulators, emulators, and supported physical devices |
| Appium | Black-box WebDriver | External drivers, but no app SDK | iOS and Android with platform-specific capabilities | WebDriver client code | Manual driver, wait, and locator upkeep | Simulators, emulators, and physical devices |
| Maestro | Black-box | No app SDK | Shared flows where behavior matches, with platform-specific flows as needed | YAML commands | Manual flow and selector updates | Simulators, emulators, and physical devices |
| Momentic | Black-box | No native test SDK or framework-specific native test configuration | Same YAML format for iOS, Android, and web | Plain-English YAML | AI-assisted test updates when UI changes invalidate steps | Hosted simulators and emulators only |
Detox coordinates with the app through native integration. Appium, Maestro, and Momentic drive an installed app externally, and Momentic uses the same test format for mobile and web. Physical-device testing still requires another tool because Momentic runs only on hosted simulators and emulators.
Maestro on EAS and its maintenance tradeoffs
Expo’s first-party EAS guidance uses Maestro to test compiled apps on an Android emulator or iOS Simulator. An E2E build profile produces an Android .apk or an iOS simulator .app. Maestro then drives the installed binary as a user would.
Maestro expresses test flows as concise YAML command sequences. You store YAML flows under .maestro and express actions such as launchApp, tapOn, and assertVisible. A workflow file under .eas/workflows chains the EAS build job into a Maestro job through its build_id, then selects tests through flow_path. You can trigger that workflow on pull requests or run Maestro locally against an installed build.
Platform differences create the main maintenance burden. Android and iOS require different binaries and EAS build jobs. Differences in controls or timing may also require platform-specific Maestro flows. That duplication grows when application behavior diverges across platforms.
Text-based selectors can also become brittle as the interface changes. A tapOn step that targets visible copy may fail after a wording change, localization update, or when a duplicate label appears elsewhere on the screen. Stable accessibility identifiers reduce that risk, but you must add and maintain them in the application. Maestro remains a practical choice when you want readable YAML and direct EAS integration, provided you accept the platform-specific suite work and selector maintenance.
Momentic supports one suite and agent-driven test runs
Momentic lets you write end-to-end flows for iOS, Android, and web in the same plain-English YAML format. You store the test steps beside the application code. Momentic drives the compiled mobile binaries externally, so you do not add a native test SDK or maintain framework-specific native test configuration.
Momentic runs mobile tests on hosted iOS simulators and Android emulators. It does not run tests on physical devices. Because the runner interacts with the built application, you can keep an Expo managed project and use the .app and .apk artifacts produced by EAS or local builds.
Momentic can update a test when an interface change invalidates an existing step, reducing manual selector and flow repairs. Momentic can revise the shared test definition instead of requiring you to repair each affected text selector or platform-specific flow manually. You can review those YAML changes in the repository with the rest of the commit.
The momentic-mobile CLI can start hosted test runs from a developer workstation or CI. Momentic also provides an MCP server that lets a coding agent trigger a test and inspect the resulting failure evidence. When a run fails, the agent can read the screenshot and trace before modifying the code or reporting the regression. After a coding agent produces a change, it can use Momentic to run the relevant test against each configured target.
Expo and React Native E2E testing questions
How do I test an Expo app end to end without Appium?
Build a standalone .app or .apk with EAS or locally, then use a black-box tool that drives the compiled binary from outside the app. Momentic runs the binary on hosted iOS simulators and Android emulators without adding a native test SDK or requiring you to eject from Expo’s managed workflow.
Can one suite cover iOS, Android, and web for a React Native app?
Yes. Momentic uses the same plain-English YAML test format and hosted runner for all three targets. You keep the tests in one repository and run them against each platform rather than maintaining separate tooling per platform.
Can I keep my Appium tests and add AI-maintained tests beside them?
Yes. Run Appium and Momentic as separate CI jobs, then migrate individual flows when the Momentic versions provide the coverage you need. You do not need to rewrite the full Appium suite before adopting Momentic.
Can I test through Expo Go?
Use an installable test binary for end-to-end coverage of your app’s native build rather than relying on Expo Go. Expo’s EAS testing guide uses an Android .apk or iOS simulator .app that the test runner can install. The binary captures native configuration and build-specific behavior that an Expo Go session does not represent.
Setting up your first E2E run with Momentic on an Expo app
- Create an E2E build profile. Create an installable
.appfor an iOS simulator and an.apkfor an Android emulator. Ane2e-testprofile ineas.jsoncan enableios.simulatorand set the Android build type toapk, following Expo’s documented setup .
You can produce the same artifacts locally if your CI already handles native builds. Momentic drives the compiled binary externally, so you do not add a native test SDK or eject from the Expo managed workflow.
- Upload each binary to Momentic. Add the iOS
.appand Android.apkto your Momentic project. Momentic installs them on hosted iOS simulators and Android emulators. It does not run these tests on physical devices. - Store the first test with your application code. Create a YAML file such as
tests/mobile/sign-in.yaml. The steps describe user-visible behavior in plain English, and the same test can target both uploaded builds.
Store credentials in CI secrets rather than committing them. Add more assertions around navigation, validation, and persisted state after the first path passes.
- Run the test through the mobile CLI. Install and authenticate
momentic-mobileaccording to your Momentic project settings. Then invoke the checked-in test from the CI job to start a hosted run.
Configure separate iOS and Android jobs when you want both binaries checked on every pull request. Both jobs can reference the same YAML file.
- Make the CI job a required check. Configure branch protection so the pull request cannot merge when the Momentic job fails. When the check fails, an engineer or coding agent can inspect the screenshot and trace. After addressing the failure, they can rerun the same command before requesting another review.
Choose an E2E testing approach
Choose a tool based on how much platform-specific test code and ongoing repair you are prepared to own. Maintenance costs rise when platform flows diverge or interface changes repeatedly break selectors. Consider maintenance effort alongside initial setup and CI runtime.
You can change approaches incrementally. You can keep existing Appium, Detox, or Maestro tests in CI while evaluating Momentic on one important user flow. Compare cross-platform consistency and time spent fixing tests over several releases. Migrate additional flows only when the results support it.