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.

One workflow for web and mobile.

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: How are broken mobile steps healed?

With an AI heal loop that your local runner runs against the live app, the same approach used for web tests. It reproduces the failure, repairs the affected steps, and saves the fix only after it replays green; otherwise the steps are left unchanged and the test is tagged @needs-review or flagged as a likely app bug. 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.

Q: Does mobile also cover API and security testing?

Yes. During discovery and test runs the local runner can route the device's traffic through a local capture proxy, so the captured API calls feed the same API test generator and security audit pipeline as your web sessions. HTTPS bodies are decrypted only when you opt in for a debug build and device that trust the runner's certificate; otherwise HTTPS passes through undecrypted.

Create and run native iOS and Android tests through Appium, 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 discovery and test pipeline that drives web testing now drives the mobile session through the runner — you record taps and assertions on a live device mirror in the dashboard, and the recording becomes a test in the same lifecycle as your 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 XCUIElementType nodes on iOS, Android widget class nodes from UiAutomator2 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. Assertions are recorded explicitly: switch the recorder to Assert mode and tap the element that proves the outcome, and it becomes an assertion step.

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 discovery and test runs the runner can route the device's traffic through a local capture proxy, so the captured API calls feed the same API test generator and security audit pipeline as your web sessions. HTTPS bodies are decrypted only when you opt in for a debug build and device that trust the runner's certificate; otherwise HTTPS passes through undecrypted.

Run local-only and self-heal on your machine — 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, the local runner reproduces the failure and runs an AI heal loop against the live app, the same approach used for web tests. A fix is saved only after it replays green; otherwise the steps are left unchanged and the test is tagged @needs-review or flagged as a likely app bug. 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