Skip to main content

Mobile testing (iOS and Android)

TestChimp supports native mobile test authoring and the same plan → repo → agent → CI workflow you use for web. Mobile tests are written with Mobilewright—a Playwright-style API and tooling for iOS and Android (see the Mobilewright site for SDK, CLI, and examples).

For cloud-hosted real devices used in automation, see Mobile Use (device farm and integration patterns).

This page is the authoritative reference for mobile vs web capabilities in TestChimp. For instrumenting native apps for TrueCoverage (SwiftPM, JitPack, automation URLs), see Instrumenting your app for TrueCoverage. For product overview, TrueCoverage introduction. For web Smart Steps (ai.act / ai.verify), Introduction to SmartTests.

Feature parity: web vs native mobile

CapabilityWeb (Playwright)Native mobile (Mobilewright)
Smart Steps (ai.act, ai.verify, …)YesNot yet
ExploreChimpYesYes
Requirement traceability (// @Scenario: etc.)YesYes
Closed feedback loop — agents expand coverage aligned to requirementsYesYes (requirement alignment)
TrueCoverage (RUM + test event alignment)YesYestestchimp-rum-ios, testchimp-rum-android, installTestChimp, TESTCHIMP_PROJECT_TYPE, automation URLs — see Instrumenting your app

Smart Steps (ai.act / ai.verify, …) remain web-only today; native mobile uses standard Mobilewright APIs for UI steps.

How to get started

  1. Create a project in TestChimp and set project type to Android or iOS. TestChimp creates a test scaffold tailored to that platform (Mobilewright layout and conventions).
  2. Connect Git and map the same two folders as for web: a plans directory (markdown test plans) and a tests directory (your Mobilewright suite root).
  3. Install the TestChimp skill on Claude, Cursor, or another supported host.
  4. After each PR, run your usual /testchimp test (or equivalent) flow so plans, tests, and coverage signals stay aligned.

Requirement coverage in the product updates when tests are executed and reported, the same as for web projects.

CI and backends

For CI runs, the recommended approach is to configure mobile_use_api_key so jobs launch devices in the cloud (via Mobile Use) instead of relying on simulators only on generic CI runners—especially when you need consistent device matrices or GPU-attached farms.

If your app depends on ephemeral, PR-scoped backends, run those environments somewhere reachable over HTTP from the cloud devices (for example preview URLs or a Bunnyshell-style ephemeral environment). Avoid “backend only on localhost inside the CI worker” when the device under test is on a separate network: the device must be able to call your API and web entrypoints across the network.