E2E testing for Flutter,
powered by AI.

End-to-end test automation built for Flutter. You describe a test in plain English, an AI drives your real app on a real device to carry it out, and what worked is saved as a test you can replay on every build — on Android and iOS.

Three pieces work together. The flutternaut package runs a small bridge inside your app that sees the real widget tree and acts on real widgets. An engine on your Mac drives the device and talks to that bridge. The desktop app is where you author, run and review tests. To author, pick a device and type a goal like "sign up with a new account and check the welcome screen": the AI reads the widgets on screen, performs one step, looks at the result and decides the next, keeping only the steps that worked. The result is saved as a readable test, a list of steps such as tap "Sign up", type into the email field, expect "Welcome". Replays run those saved steps directly and report pass or fail step by step, with a screenshot when a step fails.

Deterministic. The AI is only used while you author a test. A saved test replays with no AI at all, so the same steps run the same way every time. Each step finds a real widget by its text or key through the bridge, not by pixel coordinates or image matching. Before a tap or a type, Flutternaut checks that the widget can actually be hit, so it never taps something hidden behind a dialog or off screen. There are no fixed sleeps: a step waits only for its own target, up to a set timeout, and moves on the instant it's ready, and an assertion re-checks until it holds or times out. By default the run stops at the first failed step and tells you exactly why. So when a test that passed starts failing, something in your app or its data changed, not the test runner.

Yes, and it's free. Flutternaut includes a free MCP server, so Claude Code or any MCP-compatible agent can check the feature it just built on a real emulator or simulator: launch your debug app, read the visible widgets, tap and type one step at a time, and assert the result. A passing tap proves nothing; a passing assertion does. It uses the same engine and bridge as the desktop app, the steps it ran can be kept as a regression test, and a ready-made agent skill shows the agent how to use it.

No wrappers and no Semantics annotations. Most widgets are found by their visible text. You add a ValueKey only for widgets that have no text, like an icon-only button or a row in a long list.

Android emulators and phones, iOS simulators, and physical iPhones. The desktop app runs on macOS today, with Windows on the way.

No. The bridge works in debug, profile and release builds so you can test what you ship, and you leave it out of the build you publish to the App Store or Google Play.

Yes. Run a whole set of tests across a pool of devices at once: each device takes the next test from a shared queue, the app is reset between tests, and a crashed app is told apart from a lost device.

Covered. Flutter widgets are driven through the in-app bridge, and native OS dialogs, in-app browsers and other non-Flutter screens through the device's own automation layer.

We're sending early-access invites in waves. Join the list and you'll get an email when your invite is ready. We only email you about access and launch.

We'll share pricing for the desktop app before launch, and the waitlist hears first. The MCP server is free.