Mobile Automation in Kane CLI: iOS and Android Runs

The Three Kane CLI Run Targets

A mobile run drives an app installed on a virtual device on your machine. You pass a build with --app, Kane CLI boots the device, installs it, and runs your objective against it. The same perception, accessibility-tree inspection, vision grounding, and code generation it uses on web pages are all platform-aware.

Three targets exist, and the flag value is what you type:

WebViews inside the app under test are handled in the same run, so a hybrid screen does not need you to script a switch between native and web content. Both mobile targets require macOS on Apple Silicon, and real hardware stays with the broader TestMu AI platform rather than the local CLI. If your coverage question is about real devices instead of virtual ones, the real device cloud runs 10,000+ real Android and iOS devices.

Setting Up a Simulator or Emulator

One command per target pulls the tooling Kane CLI manages for that toolchain:

kane-cli doctor --target simulator --install

Drop --install and the same command becomes a read-only check that prints one line per requirement with its fix. The --target flag is mandatory and singular, which is easy to forget. Running it bare on v0.8.13 gives you the exact correction rather than a guess:

$ kane-cli doctor
error: --target is required - say which toolchain to check.
  kane-cli doctor --target emulator
  kane-cli doctor --target simulator

Kane CLI manages its own test tooling, not the platform SDK. You still bring the platform pieces:

• Xcode 16 or newer - it bundles the iOS Simulator, the simctl tool, and at least one iOS runtime. Point the developer directory at the full Xcode install, not the standalone Command Line Tools, or simctl will not resolve.
• An arm64-v8a AVD - create one in Android Studio Device Manager. An x86 or x86_64 image on Apple Silicon boots extremely slowly or hangs, and Intel HAXM is not needed because Apple Silicon uses the built-in Hypervisor framework.
• Kane CLI discovers the device, boots it, and installs your build from there. You never run adb or boot a simulator by hand.

Once the toolchain is ready, two list commands confirm what you can target. Full flag coverage lives in the Kane CLI mobile testing docs.

kane-cli devices list --target emulator   # devices on this machine
kane-cli apps list --target simulator     # uploaded builds, with the APP ID column

Running Your First Mobile Objective

The objective is the same shape you already write for web. You describe the outcome and let the agent resolve the path:

kane-cli run "Place an order for a smartwatch and verify the confirmation screen" \
  --target simulator \
  --app ./builds/MyApp.zip \
  --device-name "iPhone 15" --os-version 17

Devices resolve by human-readable name and OS version, which is the v0.8.7 change that made mobile usable day to day. There are no capability files. That address is written into the test.md file, so a later replay targets the same device rather than whatever happens to be booted.

Two details matter in a non-interactive run such as CI. A device must already be set with the device flags or with kane-cli config set-device-name, or the run exits and prints the fix instead of guessing. And mobile code export is Appium Python only, so passing --language javascript on a mobile export fails immediately with a clear message rather than producing broken output. For the replayable-test format these runs write, see Test.md.

Evidence From a Mobile Run

Every Kane CLI run seals an evidence pack, and mobile replay emits evidence on each step exactly as web runs do. What is mobile-specific sits in the run environment and the logs:

• The run environment records the device - the device model and OS version are stored in the result summary, so a verdict is tied to what it ran on.
• Device logs join the per-step logs - output from the emulator or simulator sits alongside the usual run logs. Since v0.8.7 the noisy tags are filtered out, leaving the signal.

The pack is a sealed directory saved under .testmuai/evidence/ in your project, holding results, per-step screenshots with annotated copies, a HAR network log, console output, and the failure record. You open it locally with kane-cli evidence serve, and nothing is uploaded to do so. Because it is a file you keep, it can be diffed in git rather than expiring on a third-party retention timer.

Mobile and Web Run Differences

Most of what you know carries over. These are the differences worth knowing before your first run:

If you are weighing virtual devices against a framework-first approach, the tradeoffs in Appium vs Detox still apply to what you maintain, and what an emulator is covers where a virtual device stops representing real hardware.

Start Running Mobile Objectives

Install the CLI, sign in, and pull the toolchain for whichever target you want first:

npm install -g @testmuai/kane-cli
kane-cli login
kane-cli doctor --target simulator --install

Point your first objective at a build you already have, then read the sealed pack to see what the agent acted on. Full command and flag coverage is in the Kane CLI product page and the mobile testing docs.