allwright
← All posts
3 min readThe allwright team

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.

releasedesktopwindowsmacosiosandroidweb testingchangelog
TSone test fileallwrightcoreWebChromium · FirefoxAndroidemulator · deviceiOSSimulator · iPhonemacOSXCUITestWindowsUI Automation

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/vitest value, 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 dblclick helper on every client.
  • allwright update. Update an installed CLI in place from the latest GitHub release, or pin one with allwright 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_VERSION accepts latest.

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 | iex

Then scaffold a project for the surfaces you care about:

npm init allwright@latest my-tests -- --typescript --all

Use --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

SurfaceYou need
WebChromium or Firefox
Androidadb and an emulator or device
iOSA Mac with Xcode, and a Simulator or registered iPhone
macOS appsmacOS 14+ with Xcode and Accessibility permission
Windows appsWindows 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 update if 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.