Which platforms and devices does mobile testing support?

iOS and Android. The same bridge drives iOS simulators, Android emulators, and real devices over USB — an iPhone simulator through simctl, an Android emulator through adb, a real Android over USB debugging, and a real iPhone via an Apple Developer provisioning profile and a WebDriverAgent signed with your team certificate.

Is mobile a separate product or a paid add-on?

No. Mobile testing draws on the same test, Discovery, heal, and run budgets as web — there's no separate mobile add-on or price. It's one pipeline, one vocabulary, and one health dashboard across web and mobile.

How do I start a mobile run?

Install Appium 2.x with the XCUITest and UiAutomator2 drivers, boot a simulator or connect a device, and start the local runner with the --mobile flag — the mobile bridge boots on port 9515. From there, recording and Discovery drive the device through the runner.

How are broken mobile steps healed?

With a deterministic Appium step healer, not the LLM loop used for web. It replays and repairs the affected step against the live app; if it can't make a safe change it tags the test @needs-review instead of silently rewriting it. Mobile tests share the web lifecycle: DRAFT to ACTIVE on the first green pass, quarantine after repeated heal failures, and auto-re-promotion after two green runs.

Mobile testing

Q: Do mobile tests run in the cloud?

No — mobile tests run local-only. A readiness gate refuses to create a cloud run unless a local runner advertises the platform with a booted device, so runs happen against the simulator, emulator, or real device attached to your machine.

Q: Does mobile also cover API and security testing?

Yes. During recording the mobile bridge pipes traffic through a local HTTPS-intercepting proxy, so the captured API calls feed the same API test generator and security audit pipeline as your web sessions — the same coverage, reached through a native app.

The same voice and discovery pipeline that records and generates Playwright tests for the web now drives Appium sessions against iOS and Android. Same AI, same intent classification, same lifecycle — different target. Mobile lives in one pipeline, one vocabulary, and one health dashboard alongside your web tests.

Mechanism: Appium 2.x driven through a local mobile bridge on port 9515 → one action vocabulary across iOS and Android.

The problem: Mobile automation usually means a second toolchain, a second query language, and a suite that lives apart from your web tests — double the maintenance for one product. iOS and Android are normally automated with different frameworks (XCUITest vs. UiAutomator2), so tests and know-how don't transfer between the two platforms. Native locators pinned to screen coordinates or fragile element paths break the moment a layout shifts, exactly like brittle CSS selectors on the web. Recording a mobile flow and replaying it reliably across simulators, emulators, and real devices normally takes heavy, per-platform setup.

Point the same pipeline at a native app — Instead of a URL, you start the local runner with npx @validate.qa/runner start --mobile and boot an iOS simulator or Android emulator (or connect a real device). The same voice + discovery pipeline that drives web recording now drives the mobile session through the runner — you author it the same way you author web tests.

Bridge to the device over Appium — A local mobile bridge boots on port 9515 and speaks Appium 2.x — the XCUITest driver for iOS, UiAutomator2 for Android. Simulators, emulators, and real devices all plug into the same bridge, and an optional --tunnel flag exposes it over HTTPS when the dashboard needs to reach your machine.

Read the view hierarchy, not pixels — The agent walks the native view hierarchy — a tree of XCUIElement nodes on iOS, UiObject2 descriptors on Android — the same way it reads the web accessibility tree. Locators prefer stable identifiers: an iOS accessibility identifier (the mobile equivalent of a web data-testid) or an Android resource ID, rather than fragile screen coordinates.

Speak one shared action vocabulary — Every recorded step maps to a compact action vocabulary — tap, swipe, type, assert, plus a few navigation helpers — that is identical on iOS and Android. Voice narration is classified by intent — command, expectation, description, noise — and an expectation spoken within a few seconds of an action becomes its assertion.

Generate Appium tests and carry API + security through — Discovery runs in survey mode to catalog the view hierarchy or deep mode to record journeys with expected outcomes, then emits Appium tests. During recording the bridge pipes traffic through a local HTTPS-intercepting proxy, so the captured API calls feed the same API test generator and security audit pipeline as your web sessions — mobile isn't a separate silo of coverage.

Run local-only and self-heal deterministically — Mobile tests run local-only: a readiness gate refuses a cloud run unless a local runner advertises the platform with a booted device. When a step breaks, a deterministic Appium step healer replays and repairs it — not the LLM web-heal loop — and tags the test @needs-review if it can't make a safe change. Tests follow the same lifecycle as web: DRAFT → ACTIVE on first pass, quarantine after repeated heal failures, auto-re-promote after two green runs.

Open Mobile testing · Get Started Free