End to end testing a mobile app comes down to three tools, and setup cost picks the one you keep.
Three end to end testing tools are actively maintained for React Native: Maestro, Detox and Appium. Those are the three React Native's own testing overview names, and all three shipped a release in the last four months. Maestro runs YAML flows against the finished binary and puts nothing in your project. Detox runs JavaScript tests that can see inside the app, and wants a native build and a test runner first. Appium is a server plus a driver per platform. All three drive a simulator or an emulator. Only Appium documents a real iPhone, and it charges you a signed WebDriverAgent to get there. Every version, command and limit below comes from each tool's own documentation, read on 10 October 2026. If you have not decided what to cover yet, start with testing before launch.
What follows is the maintenance picture with dates, what each tool asks of your machine and your repository, where each one can and cannot run, and the part most comparisons leave out: on a small app the setup can cost more than the bugs it finds. None of this needs a device farm.
See which tools are still maintainedThe short version
All three can tap the same button. The difference is what they make you build first.
Maestro installs as one tool, needs Java 17 or higher on the path, reads YAML flows out of a folder, and assumes the app is already installed on the device. Detox installs as two dev dependencies, writes a config file and a Jest config into your repository, and will not run until you have built the app with its own build command. Appium installs as a server, plus a driver for the platform, plus a client library for the language you write in. That ordering is most of the decision for a small app. Maestro reaches a passing flow fastest. Detox gives the steadiest assertions once you are through the setup. Appium reaches hardware the other two do not.
The second thing that decides it is where the test is allowed to run. Maestro and Detox both stop at the iOS Simulator. Detox says so on its own front page, in brackets, next to the feature it is advertising. Maestro documents iOS only through simulators that Xcode manages. Both handle a plugged in Android phone without ceremony. So if a real iPhone is a hard requirement, because you are testing a camera, Bluetooth or anything measured against real hardware, that single requirement picks Appium before any question of taste comes up.
Which end to end testing tools are maintained for React Native right now?
Three, and none of them is coasting. Checked on 10 October 2026: Maestro's command line tool is at cli-2.11.0, published 29 September 2026. Detox is at 20.51.4 on npm, published 16 June 2026, with commits on its repository as recent as 5 October 2026. Appium is at 3.8.0 on npm, published 24 September 2026. That is worth stating plainly, because most comparison articles you will find are arguing about a field that has changed, and a maintenance scare is the usual reason someone picks the wrong tool.
Detox is the one that publishes its React Native compatibility as a range, which is useful and slightly uncomfortable. Version 20.x is documented as fully compatible with React Native 0.77.x through 0.84.x, including the New Architecture, and the docs add that newer React Native versions might work but have not been thoroughly tested by the Detox team. There is a second limit on the same page: Detox says it does not currently support non React Native apps on Android. If you are sitting on a very new React Native, read that range before you spend an afternoon on the setup.
One line in Detox's own documentation matters more than any benchmark if your app is an Expo app. Expo integration with Detox is entirely a community driven effort, there is no special support for Expo projects in Detox, and the team does not maintain Expo specific code or documentation. It points Expo users at Expo's site and at the Expo community for support. Expo, meanwhile, documents Maestro: its end to end testing reference walks through running Maestro flows on EAS Workflows, with a build profile that sets simulator to true for iOS and an apk build type for Android, and flows kept in a .maestro directory alongside eas.json.
That is not a quality verdict on Detox. It is a statement about who answers the issue when your setup breaks at eleven at night. On an Expo project, Maestro has a first party guide and Detox has a community one. On a bare React Native project the asymmetry mostly disappears, and Detox is the tool with the deeper assertion story.
Detox documentation, environment setup, read 10 October 2026
Narrow it down
Which tool survives your requirements
Tick what you actually need. Every claim behind a tick comes from that tool's own documentation.
Nothing ticked. With no constraints at all, any of the three will tap the button, so pick on setup cost and start with Maestro.
What does each one need before the first test runs?
Maestro asks for the least. The command line tool needs Java 17 or higher, with JAVA_HOME pointing at it. On macOS you install it with a curl script or a Homebrew tap, on Windows from a zip on the releases page, and there is a desktop app, Maestro Studio, shipped as an exe, a dmg and an AppImage. For iOS work you need Xcode and the Xcode Command Line Tools. For Android you need an emulator or a phone reachable over ADB. Nothing lands in your app: Maestro's React Native page says you do not need to install any npm packages inside your app, because it tests the final bundled binary. A flow is a YAML file with an appId line and a list of commands, and it maps a React Native testID straight onto its id selector.
Detox asks for more, and every item is written down. You install Jest and Detox as dev dependencies, then run detox init, which writes a .detoxrc.js, an e2e Jest config and a starter test. On macOS you also install applesimutils through Homebrew, which Detox requires in order to work with iOS simulators. Then the part people underestimate. Each app configuration in .detoxrc.js carries a binaryPath and a build command, and you run detox build before detox test. The iOS build is an xcodebuild invocation against the iphonesimulator SDK. The Android build is gradlew assembleDebug plus assembleAndroidTest with a test build type, and that second task is the tell: Detox compiles a test APK next to your app.
Appium is a server, and its documentation is direct about installing three things rather than one: Appium itself, a driver for your target platform, and a client library for the language you write tests in. The drivers are UiAutomator2 for Android and XCUITest for iOS, with plugins as an optional fourth layer. That modularity is why Appium covers platforms the other two do not, and it is also why its first run takes the longest of the three.
Put plainly: a first passing Maestro flow is an install, a booted simulator and a five line YAML file. A first passing Detox test is a config file, a native build and a test runner. A first passing Appium test is a server, a driver, a client library and a capabilities object. Every step is documented and none is hard. There are simply more of them as you go down that list, and on a small app the number of steps is the thing that decides whether the suite still exists in three months.
Maestro documentation, React Native support, read 10 October 2026
Can these run on a simulator, or do you need a real phone?
Simulators and emulators cover nearly all of it, and the one real gap is iOS hardware. Maestro's iOS page says you run tests on any iOS Simulator managed by Xcode, and that you test the same .app bundle, the Simulator version, that runs on the virtual device. There is no physical iPhone path anywhere in its iOS documentation, and its cloud service is the same shape, where the instructions are to build an Android APK or an iOS .app bundle for Simulator. Detox is blunter still. Its front page advertises running on devices and then puts not yet supported on iOS in brackets beside it, and the device configuration reference agrees: the types are ios.simulator, android.emulator, android.attached and android.genycloud. There is no iOS device type at all.
Android is the easy half. Maestro connects over ADB and automatically detects running emulators and physical devices, asking only that USB debugging is on in Developer Options. It also assumes the app is already installed on the target before the test begins, which is the single most common first run surprise. Detox's android.attached type takes an adbName pattern and drives a plugged in handset, and its emulator type can boot headless for CI. One Maestro detail to check before you create an emulator: its QuickStart lists the supported Android API levels as 29, 30, 31, 33 and 34, and says support for 35 and 36 was arriving in the second quarter of 2026. That note was still on the page when it was read on 10 October 2026, so pick an image from the supported list rather than the newest one Android Studio offers you.
If a real iPhone is non negotiable, Appium's XCUITest driver documents exactly what it costs. The device has to be trusted so that it shows up as a run destination in Xcode. Developer Mode has to be turned on, which from iOS 16 lives under Settings, then Privacy and Security. Enable UI Automation has to be switched on under Settings, then Developer. And the WebDriverAgent app that the driver installs must carry a valid provisioning profile in order to be installable on the target device. In other words an Apple Developer account and a working signing setup, before a single assertion runs.
None of this replaces testing on your own phone before you ship, because a simulator hides a different class of problem: a layout that only breaks at a real screen size, a permission prompt in the wrong language, a cold start that feels slow on a four year old handset. Automated flows tell you the journey still works. A phone in your hand tells you whether it feels like an app.
Maestro documentation, React Native support, read 10 October 2026
The three maintained tools, side by side
| What you are asking | Maestro | Detox | Appium |
|---|---|---|---|
| Tests are written in | YAML flows | JavaScript, with Jest | Your language, through a client library |
| Runs on the iOS Simulator | Yes | Yes | Yes |
| Runs on a real iPhone | No | No | Yes |
| Runs on an Android emulator or a plugged in phone | Yes | Yes | Yes |
| Has a build command of its own you run first | No | Yes | No |
| Needs a test runner configured in your repo | No | Yes | Your client library decides |
| Also drives web browsers | Yes | No | Yes |
| Latest release, read 10 October 2026 | cli-2.11.0, 29 September 2026 | 20.51.4 on npm, 16 June 2026 | 3.8.0 on npm, 24 September 2026 |
Is end to end testing worth the setup cost on a small app?
Often not, and the candid version of that answer is in React Native's own documentation. It says end to end tests give you the highest possible confidence that part of your app is working, and in the same breath that they are more time consuming to write, slower to run and more prone to flakiness than the alternatives. Its advice is to spend them on the vital parts, naming authentication, core functionality and payments, and to leave the rest to faster JavaScript tests. That is a recommendation to write few of them, not many.
Work out your own break even instead of taking anyone's word for it. The setup is bounded: an afternoon for Maestro, closer to a day for Detox if the native build fights you, longer for Appium if you are signing WebDriverAgent for the first time. Each flow after that is twenty minutes or so. Against that, count how many times you will repeat the same manual pass by hand. A single screen app with no login, no server and no paywall will not repeat it often enough to pay for the suite. A sign up, a checkout and a sync get repeated every release, and somewhere around the fourth release the suite has paid for itself and keeps paying.
Two things these tests will not do for you. They are not a substitute for unit testing, which runs in a second and tells you which function broke rather than which screen looked wrong. And when a flow fails on CI, what you get is a screenshot and a step name, not a cause. You still go to the native log to find out why the app died, which is why debugging crashes is the skill worth having before the suite exists rather than after.
Once you are past setup, flakiness is the real tiebreaker, and the two leading tools answer it from opposite sides. Detox exists partly because of it: it takes a gray box approach, with access to the internals of the app under test, so it knows about network requests and animations still in flight instead of guessing at them. Maestro answers from the outside, advertising built in tolerance for UI settling and automatic waiting in place of sleep calls. Both work. What they have in common is that neither sells you manual waits any more, so a flaky suite in 2026 is usually a suite with bad selectors. Assert on testIDs, which Maestro maps to its id selector and Detox matches with by.id. Text selectors break the first time somebody translates the app.
Detox documentation, environment setup, read 10 October 2026
Where this lands if a builder generated your app
Nothing in the setup changes because an AI wrote the first version, as long as you own the project. Newly is an AI app builder. You describe an app in plain English and it generates a real React Native and Expo project that belongs to you, with two way GitHub sync, so the repository the flows live in is a repository you can clone and run locally. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store on your behalf, because Apple requires the owner of the content to submit. Pricing starts at $25 a month and there is no free tier.
In practice that puts you on the Expo path described above, which is the better supported of the two. A .maestro folder at the root of the generated project, flows in YAML next to the app code, and a build profile that produces the simulator app bundle and the APK those flows run against. Because the project is genuinely yours in Git, nothing stops you wiring up Detox instead. You will simply be on the community side of Detox's Expo support while you do it.
The honest limit: generating an app does not write its tests, and a generated screen can move the next time you ask for a change. Two habits make that survivable. Ask for testIDs on the elements you intend to assert on, so the selectors stop depending on wording. And keep each flow to one user journey, so a regenerated screen costs you one file to fix instead of the whole suite.
Questions people ask about end to end testing a mobile app
It is a test that drives the installed app the way a person would, on a device or a simulator, and checks what appears on screen. React Native's own testing overview defines it as verifying your app works as expected from the user perspective on a device, a simulator or an emulator. The test taps, types and swipes through a whole journey, for example sign in, add an item, pay, rather than calling a function and checking its return value. That is what makes it slow and what makes it convincing: if the flow passes, the screens, the navigation, the network layer and the native build all worked together.
Write one flow for the journey that earns the money
Launch the app, sign in, reach the screen that matters, assert on a testID. One flow that runs on every build beats a suite you abandon in week two.
Start building