Web, mobile, and desktop on one API
allwright v0.1.25 puts web, Android, iOS, macOS, and Windows behind one client shape, one locator model, and the same retrying assertions.
Six weeks ago allwright was a web automation tool with a promising Android story. As of v0.1.25, one install drives the places most software actually lives: web browsers, Android, iOS, macOS apps, and Windows apps — from Rust, Go, Java, Python, and TypeScript, with the same locators, actions, and retrying assertions everywhere.
It took three releases to get here, and this one is the one that finishes the job.
The road to five surfaces
- v0.1.16 – v0.1.18 — iOS on Simulators and registered iPhones, joining Web and Android.
- v0.1.21 — native macOS desktop automation through a headless XCUITest runner.
- v0.1.24 — native Windows desktop automation through a self-contained UI Automation agent. No Appium, no WinAppDriver, no Developer Mode, no separate .NET install.
- v0.1.25 — the parity release: the small, unglamorous work that makes the five surfaces feel like one.
What "one API" means in practice
The point was never five separate tools in a trench coat. A test for a desktop app looks like a test for a web page:
import { expect, test } from "@allwright.dev/vitest";
test("edits a note", async ({ windowsApp }) => {
await windowsApp.getByRole("textbox").fill("hello from allwright");
await expect(windowsApp.getByRole("textbox")).toContainText("hello");
});Swap windowsApp for macosApp, androidApp, iosApp, or page and the shape
holds: lazy fixtures, auto-waiting actions, semantic locators, and expect
assertions that retry until they pass or time out. Web, Android, iOS, macOS, and
Windows can all appear in the same test file, the same config, and the same
npm test.
What v0.1.25 filled in
The capability table on Availability is the source of truth, but the headline changes are:
- State reads everywhere. Input values, checked state, attributes, and on-screen bounding boxes now work on Android, iOS, macOS, and Windows — not just the web.
- The same assertions, five surfaces.
@allwright.dev/vitestvalue, checked-state, attribute, bounding-box, attached/hidden, enabled/disabled, focused, and editable matchers work across web, mobile, and desktop, with the page/app form taking a selector first. - Deep links on desktop.
app.goto(...)opens universal links and custom URL schemes on macOS and Windows, the same helper mobile already had. - Web clicks grew up. Left, middle, and right buttons, one-to-three click
sequences, and a
dblclickhelper on every client. allwright update. Update an installed CLI in place from the latest GitHub release, or pin one withallwright update --version vX.Y.Z. The new binary is verified before it replaces the running one, and on Windows the swap completes right after the command exits.- Simpler installs. The installers now use one predictable, sudo-free
default location, and
ALLWRIGHT_VERSIONacceptslatest.
Getting started on your platform
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/allwright-dev/allwright/main/scripts/install.sh | bash
# Windows (PowerShell)
irm https://raw.githubusercontent.com/allwright-dev/allwright/main/scripts/install.ps1 | iexThen scaffold a project for the surfaces you care about:
npm init allwright@latest my-tests -- --typescript --allUse --ios, --windows, and the other surface flags to pick just what you
need. Plugins install themselves the first time a surface is used.
What each surface needs
| Surface | You need |
|---|---|
| Web | Chromium or Firefox |
| Android | adb and an emulator or device |
| iOS | A Mac with Xcode, and a Simulator or registered iPhone |
| macOS apps | macOS 14+ with Xcode and Accessibility permission |
| Windows apps | Windows x64 — nothing extra |
The honest status line
Parity does not mean identical. Still not available:
- Linux desktop and API testing remain planned.
- Windows on ARM and 32-bit Windows.
- Hover, highlight, and pointer gestures outside the web.
- File-chooser, download, and dialog hooks on macOS and Windows.
- Full-page screenshots on macOS and Windows.
- Web-only features such as DOM access, network mocking, and cookies.
The Availability page lists every gap, surface by surface, and the Changelog tracks each release.
Where to go next
- Read the Availability parity table to see exactly what each surface supports.
- Browse the client calls for your language in the Reference.
- Run
allwright updateif you already have it installed. - Star or watch the repo and tell us what breaks.
Try it in your own project
Scaffold a project with one command and run your first test, or keep reading the rest of the blog.