--- title: "How to Test an Expo or React Native App End to End Without Appium or Detox" description: "Test an Expo or React Native app end to end without Appium or Detox. Compare Detox, Appium, Maestro and Momentic, then run one suite on iOS, Android and web in CI." canonical: "https://momentic.ai/blog/expo-react-native-end-to-end-testing" last-updated: "2026-09-11T17:03:13Z" --- # How to Test an Expo or React Native App End to End Without Appium or Detox URL: https://momentic.ai/blog/expo-react-native-end-to-end-testing [blog](/blog) [/ resources](/blog/category/resources) / expo-react-native-end-to-end-testing Resources How to run end-to-end tests on an Expo or React Native build without Appium or Detox: what Maestro covers, where it strains, and how one Momentic YAML suite runs on hosted iOS simulators, Android emulators and web. Wei-Wei Wu CEO, Momentic ## 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](https://docs.expo.dev/eas/workflows/examples/e2e-tests/) uses an installable iOS `.app` or 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](https://docs.expo.dev/eas/workflows/examples/e2e-tests/) 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](https://wix.github.io/Detox/docs/introduction/how-detox-works/) 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](https://appium.io/docs/en/latest/intro/), 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](https://docs.maestro.dev/getting-started/writing-your-first-flow) 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](https://docs.expo.dev/eas/workflows/examples/e2e-tests/) 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](https://docs.expo.dev/eas/workflows/examples/e2e-tests/) 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 1. **Create an E2E build profile.** Create an installable `.app` for an iOS simulator and an `.apk` for an Android emulator. An `e2e-test` profile in `eas.json` can enable `ios.simulator` and set the Android build type to `apk`, following [Expo’s documented setup](https://docs.expo.dev/eas/workflows/examples/e2e-tests/). 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. 1. **Upload each binary to Momentic.** Add the iOS `.app` and Android `.apk` to your Momentic project. Momentic installs them on hosted iOS simulators and Android emulators. It does not run these tests on physical devices. 2. **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. 1. **Run the test through the mobile CLI.** Install and authenticate `momentic-mobile` according 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. 1. **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](https://momentic.ai) 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. ## Expo and React Native E2E testing, answered. Can I test an Expo app end to end without Appium? Yes. Build an installable iOS .app or Android .apk with EAS Build or expo prebuild, then drive that binary with a black-box tool such as Maestro or Momentic. Neither needs a native test SDK in the app. Can one suite cover iOS, Android and web for a React Native app? With Momentic, the same plain-English YAML test format and hosted runner cover the iOS simulator build, the Android emulator build and the web build, so one repository holds the tests for all three. Maestro flows run on iOS and Android but often need platform-specific branches. Can I keep my Appium tests and add AI tests beside them? Yes. Momentic tests are YAML files in your repository and run from the momentic-mobile CLI, so they can sit next to an existing Appium suite in the same CI workflow while you migrate flow by flow. Does Momentic run on physical devices? No. Momentic runs mobile tests on hosted iOS simulators and Android emulators. It does not test Expo Go or over-the-air updates; it tests the installable build you upload. Still have additional questions? ## Keep reading. [Resources Best Visual Regression Testing Tools: 10 Compared for 2026 Ten visual regression testing tools compared for 2026: Applitools, Percy, Chromatic, BackstopJS, Argos, Storybook test runner, Playwright toHaveScreenshot, Lost Pixel, Meticulous and Momentic, with pricing model, CI integration and diffing method for each. Wei-Wei Wu 12 min read](/blog/best-visual-regression-testing-tools)[Resources QA Release Checklist: 12 Steps Before Every Release A 12-step QA release checklist with an owner and a piece of evidence for each step, and a clear answer to who owns the checklist: engineering or QA. Wei-Wei Wu 13 min read](/blog/qa-release-checklist)[Resources Best Puppeteer Alternatives for Browser Automation Compare the best Puppeteer alternatives for browser automation, E2E testing, and web scraping. Explore Playwright, Selenium, Cypress, Momentic, and more. Wei-Wei Wu 8 min read](/blog/puppeteer-alternatives) ## Close the feedback loop. Point Momentic at your app. Free to start, no credit card. [Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)