allwright

Changelog

What shipped, release by release.

allwright cuts a lot of small releases — most are packaging fixes or internal hardening nobody needs to read about. This page groups the ones that actually changed what you can build, newest first. For the full, unfiltered commit history, see the tags on GitHub.

Latest is v0.1.7, which rounds out typed hooks with file choosers and downloads. Read how hooks catch popups, uploads, and downloads.

  1. v0.1.28 – v0.1.34Oct 17, 2026

    Allwright Inspector: find locators visually

    • New allwright inspector command opens a local browser UI for a live application and shows its screenshot, accessibility hierarchy, element details, and ready-to-paste locator code. Click an element in the screenshot or the tree to select it. It works for desktop-windows, desktop-mac, mobile-android, and mobile-ios.
    • Locator code is generated for all five clients at once: TypeScript, Python, Java, Go, and Rust. Elements with an accessibility id suggest getByTestId; everything else suggests getByRole with its accessible name. Copy with one click.
    • Inspect and Interact are separate modes. Inspect captures the hierarchy and selects elements without activating them. Interact switches to a continuous live screen feed and forwards click/tap, double-click, drag/swipe, wheel scrolling, typing, special keys, and paste straight to the app. Selected elements can also be clicked, double-clicked, scrolled, filled, or sent a key press to confirm a locator works before it goes into a test.
    • Pass an application path or bundle identifier (Windows, macOS), or a local or downloadable APK / iOS app artifact (Android, iOS). --device picks an emulator, Simulator, or device, --url opens a URL in the app, and --no-open prints the address instead of launching a browser. The inspector listens on loopback only.
  2. v0.1.26 – v0.1.27Oct 15, 2026

    Windows scaffolding and home-directory fixes

    • npm init allwright installs dependencies correctly on Windows, where package managers are exposed as .cmd shims.
    • allwright finds its home directory on Windows through USERPROFILE or HOMEDRIVE/HOMEPATH when HOME is not set, and ALLWRIGHT_HOME overrides the location everywhere.
    • macOS and Windows apps can capture a full scroll-and-stitch screenshot of their primary scrollable region, matching web and mobile.
  3. v0.1.25Oct 6, 2026

    One API across web, mobile, and desktop

    • Input values, checked state, attributes, and on-screen bounding boxes now read the same way on Android, iOS, macOS, and Windows as they do on the web, across all five clients. Locators expose inputValue, isChecked, getAttribute, and boundingBox on native apps too.
    • @allwright.dev/vitest value, checked-state, attribute, bounding-box, attached/hidden, enabled/disabled, focused, and editable matchers now work across web, Android, iOS, macOS, and Windows, with a page/app form that takes the selector first. URL, selected-option, and selected-text matchers remain web-only.
    • app.goto / app.navigate opens universal links and custom URL schemes on macOS and Windows desktop apps, matching the helper mobile already had.
    • Web clicks accept left, middle, and right mouse buttons and one-to-three click sequences, and every client gains dblclick (Go: DblClick) on pages and locators.
    • allwright update replaces an installed CLI in place from the latest GitHub release, or from a pinned release with --version vX.Y.Z. The staged binary is verified before it replaces the running one; on Windows the swap completes as soon as the command exits. Restart any running allwright serve process afterwards.
    • The shell and PowerShell installers now share one sudo-free default location (~/.local/bin on Linux and macOS, %LOCALAPPDATA%\Microsoft\WindowsApps on Windows), and ALLWRIGHT_VERSION accepts latest.
  4. v0.1.24Oct 6, 2026

    Native Windows desktop automation arrives

    • Desktop Windows (x64) is available across the Rust, Go, Java, Python, and TypeScript clients. Connect through desktop.windows, launch an application by executable path, a command like notepad.exe, or a packaged-app ID, and use the same app-and-locator shape as macOS and mobile.
    • The desktop-windows plugin ships a self-contained UI Automation agent and starts it automatically — no Appium, WinAppDriver, Developer Mode, or separate .NET install. It automates Win32, WinForms, WPF, UWP, and WinUI apps with click, fill, focus, key input, count, text reads, waits, screenshots, and JSON/YAML accessibility snapshots.
    • @allwright.dev/vitest adds windows and windowsApp fixtures, configured through the desktop.windows section of allwright.config.yaml, and npm init allwright can scaffold a Windows project with --windows. The PowerShell installer sets up the CLI on Windows. Linux desktop remains planned.
  5. v0.1.21Oct 4, 2026

    Native macOS desktop automation arrives

    • Desktop macOS is available across the Rust, Go, Java, Python, and TypeScript clients. Connect through desktop.mac, launch an installed application by bundle identifier, and use the same app-and-locator shape as native mobile automation.
    • The desktop-mac plugin ships with a headless XCUITest runner and starts it automatically on macOS 14 or newer. Native click, fill, focus, key input, count, text reads, waits, screenshots, and JSON/YAML accessibility snapshots all remain owned by the plugin and runner.
    • The core stays surface-neutral: clients send desktop session commands to the shared server, core lazily installs and loads desktop-mac, and opaque handles route each operation back to XCUITest. Linux desktop remains planned.
  6. v0.1.16 – v0.1.18Oct 2, 2026

    iOS automation arrives

    • Mobile iOS is now available across all five clients: connect to an iOS Simulator or a registered physical iPhone, then launch an app from a local .app, a .zip/.ipa, or a URL. allwright installs the runtime and the app for you — there is no separate driver to set up and no manual install step.
    • iOS apps use the same locator and action set as Android: click, fill, focus, press, count, text reads, selector waits, and screenshots. Both mobile surfaces now support Playwright-style getByRole, getByText, getByLabel, and getByTestId alongside their raw native selectors. Actions wait for their target automatically, so tests don't need polling loops.
    • @allwright.dev/vitest adds ios and iosApp fixtures, configured through the mobile.ios section of allwright.config.yaml, and npm init allwright can now scaffold an iOS project with --ios. The public Flights-simulator.ipa sample works out of the box.
    • iOS now includes app-level file chooser and download hooks, goto/navigate deep-link helpers, full-page screenshots, and JSON/YAML accessibility snapshots with reusable AI references. WebView accessibility content is available through native locators; arbitrary JavaScript and general CSS/DOM sessions remain outside the native surface.
    • Web and mobile clients now unwrap internal command acknowledgements at the API boundary: actions and waits return void, count returns a number, text reads return strings, and screenshots return raw bytes across TypeScript, Python, Go, Java, and Rust.
  7. v0.1.14Sep 24, 2026

    Read page and element state

    • Web pages and locators can now read state directly across all five clients: the current URL, an input's live value, selected options and selected text, checkbox/radio checked state, attributes, and bounding boxes. Each read uses the first match, accepts a per-call timeout, and works inside frame pages too.
    • The reads handle ARIA controls as well as native ones: selectedOptions covers native selects (including multiple selection) and ARIA listbox/combobox options marked aria-selected, and isChecked covers native and ARIA checkboxes and radios. Missing attributes and unsupported text selections return null rather than an empty string, and hidden or zero-area elements have no bounding box.
    • @allwright.dev/vitest adds retrying, negatable web matchers built on these reads: toHaveURL, toHaveValue, toHaveSelectedOptions, toHaveSelectedText, toBeChecked, toHaveAttribute, and toHaveBoundingBox. Each element matcher also has a page form that takes a selector first.
    • Every page, app, and locator expectation now fits each read inside its remaining assertion budget, and timeoutMs: 0 makes exactly one observation. Android keeps its text, count, and visibility matchers; the new state matchers are web-only.
  8. v0.1.13Sep 23, 2026

    Iframes as pages

    • locator.frame() resolves an iframe to a normal Page across all five clients (TypeScript also accepts Frame(), Go spells it Frame(ctx, ...)) — the same locators, actions, and retrying assertions as any top-level page, and it can resolve nested frames the same way.
    • Cross-origin frames work without reading the child DOM from the parent: the frame is resolved to its own WebDriver BiDi browsing context, over the existing Chromium mapper or Firefox's native BiDi.
    • Resolution waits for exactly one matching iframe whose document has reached readyState complete and gone 200 ms without DOM mutations, retrying within the command timeout (default 10 seconds, configurable per call). This is a document readiness check, not a network-idle guarantee.
    • Closing a frame page releases its session without closing the parent tab or removing the iframe; a detached frame fails clearly, so resolve the locator again after the iframe is replaced.
  9. v0.1.12Sep 19, 2026

    No native dialogs, and every Chromium operation over BiDi

    • File-chooser sessions now tell the browser to dismiss its file prompt, and download hooks set an explicit download destination before the triggering action, so neither an OS file picker nor a native Save As dialog can ever appear during a run.
    • Chromium tab discovery, creation, and closing moved from CDP onto WebDriver BiDi, joining navigation, input, screenshots, and hooks — CDP is now used only to bootstrap and carry messages for the BiDi mapper.
  10. v0.1.10 – v0.1.11Sep 18, 2026

    Clearer installs and plugin versions

    • The CLI installer verifies the downloaded binary's version and, if an older package-manager-installed allwright appears earlier on PATH, names the exact executable shadowing it.
    • allwright plugin list now reports outdated@<version> (expected@<version>) for a surface plugin that doesn't match the engine, and plugin installs print download and unpack progress.
  11. v0.1.8 – v0.1.9Sep 17, 2026

    File hooks reach Android, and paths stay client-local

    • Android apps gained the same fileChooser and download hooks as web, registered on the app instead of a page — the system DocumentsUI picker with a single file, and downloads written to the device's public Downloads directory. newPage is web-only.
    • Upload and download paths are always resolved on the machine running the test: files stream through the engine in chunks, so setFiles and saveAs work the same when the allwright server runs on another machine.
  12. v0.1.7Sep 17, 2026

    File chooser and download hooks

    • Two new typed hooks join newPage on the same register-then-wait lifecycle: fileChooser intercepts the native file picker (no OS dialog ever renders) and resolves to a typed chooser whose setFiles/set_files/SetFiles hands it one or more paths.
    • download resolves as soon as a download starts, exposing url and suggestedFilename immediately; its saveAs/save_as/SaveAs waits for the download to finish and copies it to the given path.
    • Shipped across all five clients at once, reusing the same generic RegisterHookCommand/WaitForHookCommand engine primitives newPage already used.
  13. v0.1.6Sep 16, 2026

    New-page hook made page-scoped, and correctly attributed

    • Fixed a real correctness bug: registering the new-page hook on the browser and resolving to "the first new page since registration" could hand back an unrelated tab if more than one could plausibly open around the same time.
    • Hooks now register on the page that triggers the event, not the browser, and resolve to the new page whose opener is specifically that page — page.registerHook(...) replaces browser.registerHook(...) across all five clients.
  14. v0.1.5Sep 16, 2026

    Hooks arrive: coordinating browser-native events

    • Introduced typed hooks — a generic register-then-wait lifecycle for browser-native events that fire asynchronously outside any direct call, so a test can start listening before the triggering action instead of racing it.
    • The first hook type: newPage, for tabs opened by a click — hook.wait() resolves to a normal Page, with the same actions and retrying assertions as any other.
  15. v0.1.4Sep 7, 2026

    Accessibility snapshots reach Android

    • Android gained accessibility_snapshot, sharing the same versioned JSON/YAML document structure web already had — one accessibility model across both surfaces instead of two.
  16. v0.1.3Sep 6, 2026

    Semantic web locators, and excluding matches

    • Web pages and locators gained Playwright-style semantic builders across all five clients — getByRole, getByText, getByLabel, getByPlaceholder, getByAltText, getByTitle, and getByTestId — chainable with CSS/XPath and filterable by has, hasNot, hasText, hasNotText, and visible.
    • locator.not(otherLocator) excludes matching elements, and Vitest assertions gained matching negation for both web and Android — expect(locator).not.toHaveText(...) and expect(locator).not().toBeVisible() — with the same retrying behavior as every other assertion.
  17. v0.1.2Sep 6, 2026

    Snapshot modes, including an AI-ready one

    • Accessibility snapshots gained a mode alongside format: default (accessible content), ai (adds a stable aria-ref to every rendered, clickable element so it can be located by reference), autoexpect, and codegen.
  18. v0.1.1Sep 6, 2026

    Web accessibility snapshots

    • Web pages in all five clients gained accessibility_snapshot / AccessibilitySnapshot / accessibilitySnapshot, returning a structured document of every node's role, name, states, properties, and children — including cross-origin iframes — as JSON (default) or YAML.
    • Accessible-name and role computation is Allwright-owned code informed by the W3C accessibility specs and by studying Playwright's behavior as a reference — no vendored Playwright code, no dom-accessibility-api dependency.
  19. v0.1.0Sep 4, 2026

    First minor version: a real milestone

    • allwright's first minor release after more than sixty 0.0.x patch releases — the point where what had already landed (web and Android automation, five client languages, one API shape, project scaffolding) added up to a real milestone instead of another patch bump.
    • No new surfaces shipped in the tag itself; see the entries below for what landed in the days right after.
  20. v0.0.61Sep 4, 2026

    Web actions hardened onto WebDriver BiDi

    • Fixed web element actions — click, count, and highlight — that were still going through raw CDP script evaluation instead of WebDriver BiDi, which could make them inconsistent with allwright's driverless automation model.
    • Chromium's DevTools Protocol is now used strictly for browser/tab lifecycle and bootstrapping the BiDi mapper; every element interaction runs over BiDi.
  21. v0.0.59 – v0.0.60Sep 3, 2026

    npm init allwright: a project initializer

    • New create-allwright package: run npm init allwright@latest (or npm create allwright@latest) to scaffold a working TypeScript or JavaScript project — config, starter tests for the surfaces you pick, and dependencies installed — in one command.
    • Auto-detects your package manager from an existing lockfile, or falls back to whichever manager invoked it.
    • Fully scriptable for CI: every prompt has a matching flag (--yes, --typescript/--javascript, --web/--mobile/--both, --package-manager, --no-install, --force).
  22. v0.0.57 – v0.0.58Sep 1, 2026

    Android automation reaches parity with web

    • Android locators gained count, focus, press-key, read-text, and wait-for-selector — the same actions already available on web, now available on mobile too.
    • Full-page Android screenshots now stitch several scrolled captures into one seamless image instead of cropping at the visible screen.
    • The Vitest integration gained a config helper that starts the engine once for a whole test run and shuts it down when the suite finishes, instead of every test bootstrapping its own.
  23. v0.0.54 – v0.0.55Sep 1, 2026

    Screenshots, everywhere

    • Screenshot capture shipped for every client language, on both web pages and Android apps.
    • Added full-page capture and the option to save a screenshot straight to a file.
  24. v0.0.53Aug 29, 2026

    One shared automation model for web and mobile

    • Unified the underlying session model so web and Android automation describe "what to act on" the same way, instead of two separate mental models.
    • Added a consistent, matching getting-started example for every client language, for both the web and Android surfaces.
    • Started early groundwork toward iOS support.
  25. v0.0.45 – v0.0.52Aug 29, 2026

    Mobile automation debuts: Android

    • Android joined web as a real automation surface: connect to a device or emulator, install and launch an app, and drive it with the same locator model already used for the browser.
    • Android selector support expanded to match common testing patterns — by visible text, resource id, class name, or state (like whether an element is clickable).
    • Apps can now be installed straight from a URL, not just a local file.
    • Web automation got more reliable: actions now wait for an element to be visible and settled before clicking or filling it, cutting down on flaky failures.
  26. v0.0.35Aug 27, 2026

    Zero-install experience

    • Client libraries now download and manage the engine and the surface plugin automatically the first time they're used — no separate CLI install step required before writing a test.
  27. v0.0.33Aug 26, 2026

    Firefox support, and a Playwright-style API redesign

    • Every client — Rust, Go, Java, Python, and TypeScript — gained a proper Browser / Page / Locator object model.
    • Firefox joined Chromium as a fully supported browser.
  28. v0.0.27 – v0.0.30Aug 26, 2026

    Config-file driven setup

    • Introduced allwright.config.yaml for describing how to launch a browser — binary, timeouts, named profiles — without writing it in code.
    • Wired the config file into every client so it's picked up automatically.
  29. v0.0.31Aug 26, 2026

    Java client published

    • The Java client became a real, installable Maven Central package, with its own test suite.
  30. v0.0.24Aug 26, 2026

    Python client, and first-class Vitest support

    • The Python client was published to PyPI.
    • Launched a dedicated Vitest integration package for TypeScript/JavaScript teams, with retrying, Playwright-style assertions.
  31. v0.0.19Aug 25, 2026

    TypeScript client published to npm

    • The TypeScript client became a normal npm install.
  32. v0.0.16Aug 25, 2026

    Rust crates published to crates.io

    • The Rust engine and client became a normal cargo install.
  33. v0.0.14Aug 24, 2026

    First real browser actions ship

    • Launch a browser, open/navigate a page, click, fill, hover, focus, press a key, highlight, count, read text, and wait for an element to appear — allwright's first real automation commands.
    • These actions retry automatically until they succeed or time out, instead of failing on the first attempt.
  34. v0.0.11Aug 24, 2026

    Plugin architecture

    • Automation surfaces became installable plugins loaded on demand — starting with web — instead of one fixed, all-or-nothing engine.
    • This is the architectural foundation every later surface (Android, and eventually iOS, desktop, and API) builds on.
  35. v0.0.7Aug 24, 2026

    Initial public release

    • allwright launched with an installable CLI, a plugin system for automation surfaces, and client libraries for five languages at once: Rust, Go, Java, Python, and TypeScript.

See what's real today

The changelog is history. For the current, continuously updated picture of what each surface can and can't do yet, see Availability.