How it works

À la carte, not a buffet.

Allwright isn't a separate tool for every surface wearing one brand — and it isn't one giant program trying to do everything either. It's a small core plus a plugin per surface: install the plugin for what you're testing, and the core knows how to drive it. Leave a plugin uninstalled, and the core simply doesn't attempt that surface yet.

One core, as many plugins as it needs

Every plugin is built from the ground up on allwright's own engine — not a wrapper around someone else's driver. Here's today's catalog; it grows as new surfaces ship.

Web, Mobile — Android, Mobile — iOS, Desktop — macOS, and Desktop — Windows are installed and ready. Desktop — Linux remains reserved, waiting on a real runtime build.

$ allwright plugin list

$ allwright plugin install web

$ allwright plugin install mobile-android

$ allwright plugin install mobile-ios

Without one engine: four unrelated tools, four things to learn, four ways to maintain.

With allwright: one core, one set of commands — solid for the plugin that's installed, dashed for the ones still to come.

From your test code to the core

Pick the client library for your stack, describe automation once, and the same core carries it to whichever plugin is installed.

Bring your own language

Rust, Go, Java, Python, and TypeScript clients are all published and ready to install from their usual package registries.

Rust

Published

The engine itself, plus a high-level client.

View example →

Go

Published

A Playwright-style Browser and Page API.

View example →

Java

Published

A Gradle-based client for JVM test suites.

View example →

Python

Published

A client that feels at home in pytest.

View example →

TypeScript

Published

Core client plus Vitest fixtures, for TypeScript or plain JavaScript.

View example →

Every client above speaks the same command set — nothing is language-exclusive. See exactly what that command set covers today →

No drivers to babysit

Once you install the web plugin, allwright drives a real, current Chromium or Firefox browser directly instead of going through a separate driver binary you have to download and version-match by hand. That means fewer “works on my machine” surprises, and tests that behave the way an actual person clicking through your app would.

Android works the same way already: install the mobile-android plugin and the same client code taps, types, and reads a real app over adb — no Appium, no separate driver server. iOS automatically provisions its Simulator runtime or locally re-signs its prebuilt physical-device agent, then installs the app under test from a local path or URL. Desktop works the same way: the macOS plugin drives native apps through a bundled XCUITest runner, and the Windows plugin drives Win32, WinForms, WPF, UWP, and WinUI apps through an isolated UI Automation agent — still no Appium or WinAppDriver. Linux desktop and API testing will follow the same model once their plugins ship — no new tool to learn, just one more plugin install for whichever surface you need next.

Try it in your own project

Web, Android, and iOS are ready today. Scaffold a project with one command and run your first test against a real target.

Get started Star on GitHub