Zeno Mobile Runner

Zeno Mobile Runner

Did your AI agent's last change break the app? ZMR gives you a deterministic yes or no — on a real iOS or Android device, with replayable evidence, and no LLM in the loop.

Mobile UI automation built for AI coding agents.

AI coding agents change mobile apps fast, but nothing tells them whether the UI still works. Zeno Mobile Runner (ZMR) is that check: one small Zig binary that installs and launches your app on a real device or simulator, runs a saved scenario, and returns a typed pass/fail plus a replayable trace — screenshots, UI trees, timings, assertion results.

Because there is no LLM inside ZMR, the same check costs nothing per run and gives the same answer every time. Run it in your agent's loop and in CI. ZMR drives native UI beneath the JavaScript and Dart layers, so React Native, Expo, Flutter, and fully native apps share one runner — over MCP, JSON-RPC, a JSON-output CLI, or committed JSON scenarios.

On-device screenshots from ZMR traces: the same demo flow driven on an iOS simulator and an Android emulator.

Why This Exists

• Agents need structured mobile state, not terminal scrapings. ZMR returns semantic UI trees, stable selectors, screenshots, and typed action results, so an agent reasons from product state instead of guessing.
• Product claims need evidence. Every traced session can produce events, screenshots, UI hierarchies, timings, assertion results, HTML and JUnit reports, and a redacted bundle safe to share.
• Exploration should become tests. After a live agent session, zmr discover / draft turn trace evidence into reviewable JSON scenarios that replay in CI with no LLM in the loop — and no per-run LLM cost.
• One model below the framework layer. ZMR drives native UI beneath the JavaScript and Dart layers, so React Native, Expo, Flutter, and fully native apps share the same runner, selectors, and traces.

How it works

flowchart LR
    A["AI coding agent<br/>AI IDE · Cursor · custom MCP harness"]
    subgraph zmr["ZMR — one small Zig binary"]
        MCP["MCP server<br/><code>zmr mcp</code>"]
        RPC["JSON-RPC stdio/TCP<br/><code>zmr serve</code>"]
        CLI["CLI + JSON scenarios<br/><code>zmr run</code>"]
        CORE["Core engine<br/>selectors · waits · assertions<br/>scenario runner · trace writer"]
        MCP --> CORE
        RPC --> CORE
        CLI --> CORE
    end
    subgraph devices["Devices"]
        AND["Android emulator/device<br/>ADB · UI Automator · optional shim"]
        IOS["iOS simulator/device<br/>simctl · devicectl · XCTest shim"]
    end
    TRACE["Trace bundle<br/>events.jsonl · screenshots · UI trees<br/>report.html · junit.xml · .zmrtrace"]
    A -- "MCP tools" --> MCP
    A -- "JSON-RPC" --> RPC
    A -- "CLI JSON" --> CLI
    CORE --> AND
    CORE --> IOS
    CORE --> TRACE

One core engine, four driver surfaces, two device backends:

• Core engine (Zig). Selector resolution, waits, assertions, the scenario runner, and the trace writer live in one place and behave identically no matter which surface invoked them.
• Four surfaces, one contract. The MCP server (zmr mcp), JSON-RPC over stdio/TCP (zmr serve), the JSON-output CLI (zmr run / validate / explain / discover), and committed JSON scenarios all map onto the same engine and the same versioned schemas.
• Android backend. Real ADB and UI Automator (exec-out uiautomator dump, screencap) with no app instrumentation required; an optional app-local Java instrumentation shim speeds up native actions when you build it in.
• iOS / iPadOS backend. xcrun simctl and devicectl handle lifecycle; a generated XCTest / XCUIAutomation Swift shim, scaffolded into your app, performs native selector actions.