Kane CLI 0.9: Real Android and iOS Devices From Any Terminal

Real Devices With --target android and --target ios

Write the test the way you already write a web test: a natural language prompt that describes the flow and the outcome to check. Point it at your build and pick the target.

kane-cli login
kane-cli run "Sign in and open the account tab" --target android --app ./builds/app-release.apk
kane-cli run "Add the first item to the cart" --target ios --app ./builds/MyApp.ipa

Kane CLI asks the TestMu AI device hub for a device, installs your app, and drives it step by step. Before the first step runs, it prints exactly which phone it got:

Connecting to a real Android device...
Running on: Real device · Galaxy S24 · Android 14 · App APP1234567

• Any host OS - real-device runs work from macOS (Intel or Apple Silicon), Linux, and Windows. You do not need Xcode, Android Studio, or any local device setup.
• Local builds or app IDs - pass a local .apk, .aab, or .ipa and Kane CLI uploads it the first time, then skips the upload when your account already has that build. An existing APP id works too.
• Clean app state - every session installs the app fresh, so each run starts from the same state.
• Live view in the TUI - in the interactive TUI, /mobile lets you pick Android or iOS, a device, and an app. A view-only window of the device opens in Chrome so you can watch the test drive it.

If your team also runs manual or Appium sessions, the TestMu AI real device cloud covers 10,000+ real Android and iOS devices for those workflows.

Pick a Device or Let the Hub Pick

You do not have to choose a device at all. With nothing named, the hub gives you any free device for the platform. When a specific phone or OS matters, list what the cloud has (no login needed) and name it:

kane-cli devices list --target android --remote
kane-cli run "<objective>" --target android --device-name "Galaxy S24" --app ./app.apk
kane-cli run "<objective>" --target ios --os-version 17 --app ./MyApp.ipa

• Either half is enough - --os-version 17 alone means any iPhone on iOS 17. Versions match by major, so 17.5 still finds an iOS 17 device.
• Name patterns - device names accept patterns, so Pixel.* means any Pixel.
• Saved defaults - save your choices once with kane-cli config set-target, set-device-name, and set-os-version, and every run picks them up.

The Same Tests on Five Targets

Kane CLI 0.9 runs the same tests across every target your users touch:

Saved tests carry their device in the file, so a suite on real devices looks like any other suite:

---
target: android
app: ./builds/app-release.apk
device_name: Pixel.*
os_version: "15"
---

Run a folder of them in parallel from your laptop, or send the whole suite to the cloud grid with --remote. There it runs as a HyperExecute job on Linux runners and prints which device each test will use before dispatch. The Kane CLI remote execution docs cover the one-time plugin setup.

kane-cli testrun run --match '^tests/devices/' --parallel 2 < /dev/null

Smart Variables for Fresh Test Data on Every Run

The second part of this release fixes a common replay failure. A sign-up test that types test@example.com passes once and then fails forever, because the account already exists.

Kane CLI 0.9 resolves smart variables at the start of each objective. The saved test keeps the reference, so every replay gets a new value.

kane-cli run "Sign up with {{smart.random_email}} and verify the welcome screen shows" --agent
kane-cli run "Book a table for {{smart.next_day}} and verify the confirmation shows that date" --agent

• Dates - current_date, next_day, previous_day, start_of_week, end_of_month, and more.
• Random data - random_email, random_phone, random_int, and random_string_8.
• Session info - values such as user_name.

Two more namespaces arrived with them. {{global.*}} reads a Test Manager global variable, and {{environment.*}} reads the variables of the run's Test Manager environment, so one test runs against dev, staging, and production without edits.

One E2E Package: Generate, Execute, Prove

With this release, Kane CLI covers the whole test lifecycle in one tool. The lifecycle started with the Kane CLI 0.6 release from PRD to evidence, and 0.9 extends it to real hardware.

• Generate - give it a PRD, a spec, or a description. It proposes use cases (every claim cited to the source), then acceptance criteria, scenarios, and one runnable _test.md per scenario.
• Execute - run those tests on desktop web, emulators, simulators, and now real Android and iOS devices, locally, in CI, or on the cloud grid.
• Prove - every run seals an evidence pack with steps, screenshots, logs, and failures. kane-cli cover reports what each acceptance criterion has proven and what is still owed. Real-device runs record the device and the app build in the evidence, so the same test on two phones or two builds shows up as two entries.

Your Playwright, Selenium, and Appium suites still cover the baseline. When QA finds an edge case on a device that automation missed, it becomes a _test.md in the repo, runs in CI, and checks every future PR on a real phone.

Built for AI Coding Agents

The Kane CLI agent skill for Claude Code, Cursor, Codex, Gemini CLI, and Kiro is updated for 0.9. Agents now know how to run real-device tests and follow these rules:

• Mention the plan requirement once, before the first real-device run.
• Never retry when the hub refuses a session.
• Never run more than one parallel session on KaneAI Max.

When an agent finishes a change to your app, it can now check it on an actual iPhone or Android phone before it hands the work back. The Claude Code and Kane CLI verification walkthrough shows the same loop on web.

Plans and Limits for Real-Device Runs

Real-device runs need one of these on your TestMu AI account:

• KaneAI Max - one real device at a time.
• KaneAI credits plus Real Device Plus Automation Cloud - as many devices at once as the plan's parallel tests allow.

If you start more sessions than your plan allows, the extra session waits in a queue for up to 15 minutes and fails with the hub's reason if no device frees up. Running a suite with --remote also needs the remote-execution plugin and a HyperExecute plan.

A few things behave differently on real devices today:

• Adaptive heal is off - a replay step that fails is reported as a failure rather than repaired.
• No no_reset - every session installs the app fresh, so no_reset is not supported.
• Idle timeout - the hub ends sessions left idle too long.
• Chrome for live view - the live device view needs Google Chrome.

Get Started With Kane CLI 0.9

Update to Kane CLI 0.9 or later, log in, and point it at your build:

npm install -g @testmuai/kane-cli
kane-cli login
kane-cli run "Open the app and verify the home screen loads" --target android --app ./app-release.apk

If you build with an AI coding agent, point it at testmuai.com/kane-cli/agents.md. The Kane CLI getting started docs cover login, configuration, and your first run.