Detox: gray box E2E for React Native, and the iOS gap inside its own README

Synchronization comes from watching the app, not from retrying the test

Every feature bullet hangs off one argument: the hardest part of mobile end-to-end testing is the tip of the pyramid, and the cause of its failures is flakiness, which the project traces to tests that are not deterministic. A black box cannot show why a test failed, a gray box can, and gray box is the term in the repository description. The mechanism claimed for it is monitoring the asynchronous operations in your app so the test does not outrun the interface, and the README does not name a single option, configuration key or native module for that hook. Debuggability comes from the same choice, because the async-await API lets a breakpoint inside an asynchronous test behave the way it does in ordinary code. What that gap costs you is concrete: the repository lists examples/demo-native-android, examples/demo-native-ios, examples/demo-pure-native-android and examples/SwiftExample, so targets outside React Native exist in the tree, while the compatibility table covers only React Native versions and says nothing about how those native demos synchronize.

One bullet promises iOS, the next one says iOS device runs are not supported yet

Two feature bullets cannot both hold as written. The cross platform bullet says you write end-to-end tests in JavaScript for React Native apps on Android and iOS. Six lines later, the runs on devices bullet ends with the parenthetical "not yet supported on iOS" while claiming you gain confidence by testing on a device or simulator just like a real user. A team planning a device matrix has to pick which sentence governs, and the file gives no date, no tracking issue and no platform page for the gap. The rest of the repository suggests the iOS path exists somewhere without settling the question: ci:ios runs sh ./scripts/ci.ios.sh and test:e2e:ios runs yarn e2e:ios in detox/test, so iOS runs are scripted in the repository. A CI script for iOS is not the same as a documented test run on an iOS device, so treat the bullet as unresolved until the Getting Started guide says which one it means.

React Native v0.77.x to v0.84.x is the official window

The compatibility table covers a single range. RN v0.77.x to v0.84.x is stated as fully compatible with React Native's New Architecture. Above that range, the README says newer versions might work with Detox but have not been thoroughly tested by the team, and below it, older versions are not officially supported, with help offered on a best effort basis by opening an issue or writing to the Discord server. That middle sentence is the one to plan around: a green run on an untested React Native version carries little information, because a red one could be your app, the version gap or the framework. One concrete failure is named and traced elsewhere, a visibility edge case on Android, which the README links to an issue in the React Native repository. If that assertion breaks on your version, the fix belongs upstream, and nothing in this project will change it.

Selectors are by id, text and label, and the test runner stays yours

Matchers in the login example are declarative: by.id for the email and password fields, by.text to find the Login button, by.label for the Welcome text. Actions are method calls, tap and typeText, and assertions go through expect, which can state that something is visible and that something no longer exists. The body of the test reads like this:

await element(by.id('email')).typeText('[email protected]');
await element(by.id('password')).typeText('123456');

const loginButton = element(by.text('Login'));
await loginButton.tap();

await expect(loginButton).not.toExist();
await expect(element(by.label('Welcome'))).toBeVisible();

Resetting between tests is a single device call that the example puts in a beforeEach hook:

await device.reloadReactNative();

Nothing binds you to one runner. The README describes Detox as test runner agnostic, a set of APIs to use with any runner, with Jest integration out of the box. Where that API ends and the Jest adapter begins is not in the README, and the repository's own package.json gives no hint of the boundary either, so a team on another runner has to find it on the docs site.

The repository root is a private yarn 4 monorepo, not an install target

Cloning the repository is not the path a consumer takes. The root package.json is named root, is marked private, and declares [email protected] as its package manager, with workspaces for detox, detox-cli, detox/test, examples/*, generation and website. Consumers take the framework from the npm package the README links; contributors need a workspace-aware checkout, and .nvmrc pins the Node version the project expects while .gitmodules and .xcoderc also sit at the root. There is no install command anywhere in the README, so an evaluation starts from the Getting Started guide. Because the root manifest holds no runtime dependency of its own, it also tells you nothing about peer dependencies, engine requirements or the minimum React Native version of the published package. Version questions get answered by the docs site, not by the file you can read in the repository.

Android and iOS run through separate scripts on Buildkite

The CI story is visible in scripts and badges rather than in prose. The badge in the README points at Buildkite, on the wix-mobile-oss/detox pipeline, and coverage is reported to Coveralls for the master branch. Running the suites is split by platform at the root, and both script values are one line each:

cd detox/test && yarn e2e:ios
cd detox/test && yarn e2e:android

The pipelines themselves are driven by two scripts, one per platform:

sh ./scripts/ci.ios.sh
sh ./scripts/ci.android.sh

Two platform pipelines means a regression is caught by a pipeline you chose, not by one command, and the two will not take the same wall clock time on your runners. prepare runs husky, so a fresh clone installs a pre-commit hook before you write a line of code, with the configuration in .husky/ at the root.

Docs get a remark and retext gate while the root exposes no unit test script

Reading the root manifest tells you what this project enforces. There is no framework runtime dependency there at all. devDependencies are husky plus a documentation pipeline built on remark, remark-cli, markdownlint-cli and a run of retext plugins, among them retext-passive, retext-profanities, retext-equality, retext-intensify, retext-readability, retext-repeated-words, retext-english and dictionary-en. The docs:lint script chains the markdownlint and remark checks over the markdown files:

yarn docs:markdownlint && yarn docs:remark

Prose in this repository is machine checked for passive voice and readability, and the root scripts list contains no unit test command at all. test:e2e:ios and test:e2e:android are the only test entry points visible from the root, so a contributor cannot tell from the manifest where the framework's own unit tests run or which React Native version detox/test is pinned to. The git history and the detox/test package are where those answers are, not the root package.json.

Three releases in spring 2026, a push to master in September, no nightly channel named

Version numbers sit in the twenties: 20.50.2 published 2026-04-21, 20.51.1 on 2026-05-03, and 20.51.3 on 2026-05-30. The repository is not archived and the last push landed on 2026-11-02, about five months after that newest tag, so the tip of master sits ahead of what npm shows. Nothing in the README explains the gap. No nightly or prerelease channel is named, no release cadence is promised, and no version support window is stated, so a team pinning a version has no documented way to learn whether master carries a fix it needs. The licence is MIT, and the README notes the project has been open source since the first commit, with an issue label for people looking for work on the roadmap and a Contribution Guide for the internals. A Getting Started guide in Brazilian Portuguese is linked as a community resource, which tells you more about the audience than the English file does.

Editorial conclusion

Adopt Detox for a React Native app on Android when end-to-end flakiness is the problem and you are willing to instrument the app so the test synchronizes with it. Do not adopt it from the README alone if iOS device runs sit on your critical path, because the same file carries the note that iOS is not yet supported there, and stay off it when your app runs outside RN v0.77.x to v0.84.x unless you plan to open an issue. Check the Getting Started guide at wix.github.io/Detox for the synchronization setup your app version needs, and read your React Native version against the compatibility table before wiring up the first test.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wix/Detox on GitHub