Skip to main content
Revyl provides cloud iOS simulators and Android emulators that you can provision, control, and observe from your own tools. You don’t need to author a Revyl test or use Revyl’s AI agent to use a device. Use the device layer for a custom test harness, an agent tool, a development workflow, or an interactive app demo. Revyl manages the device session; your code decides what happens on it.

​
What you can build today

The host running your CLI or agent does not need a local simulator. For example, a Linux CI runner can control an iOS simulator hosted by Revyl. Use remote builds to compile your app in the cloud too.

​
Separate the device from the test runner

You own the orchestration, assertions, and pass/fail policy. Revyl supplies the device lifecycle and control surface. Natural-language actions are optional: you can use coordinates, app lifecycle commands, screenshots, and UI hierarchy output without delegating your test logic to an AI agent.

​
How this compares with Limrun

Both platforms provide cloud builds and virtual devices. The difference for an existing test suite is the connection between its runner and the device. Limrun keeps its initial path short: build, create or attach a device, then run the existing test. Device catalogs and advanced build options are not required reading for that first run. Revyl’s quickstart likewise starts with the minimum device workflow; detailed build setup lives in the Builds guides. Sources: Limrun’s quickstart, Gradle builds, Appium, and Maestro guides. This compares documented behavior, not a live benchmark of the two services.

​
What needs to be added for Appium and Maestro

The Revyl Appium driver and Maestro runner provide a smaller path: native command subsets over existing device APIs, without ADB or WebDriverAgent. The Maestro runner uses the genuine published runtime with a custom driver; it is not a plugin for stock maestro test. Both are private source integrations with synthetic-app checks covering native Appium lookup and gestures, plus Maestro actions, deletion, appearance, and deep links on staging Android emulators and iOS simulators. Maestro input/paste uses the existing viewer control channel with explicit limitations and loopback-only integration coverage. Duration-preserving swipe/scroll remains gated on undeployed worker capabilities. These subsets do not establish broader compatibility. The requirements below are for broader standard-driver and stock Maestro compatibility, not prerequisites for those subsets or a delivery commitment:
  1. Android connectivity: expose an authenticated, session-scoped ADB connection or a managed runner with device access. Verify Appium first and Maestro separately rather than assuming every ADB-based tool works.
  2. iOS Appium execution: provide an Appium/XCUITest runner on the simulator’s Mac, or a remote adapter for WebDriverAgent, simulator lifecycle, and file operations. A viewer URL alone cannot replace those interfaces.
  3. iOS Maestro execution: provide a managed Maestro runner or an adapter that installs and starts its XCTest driver and forwards lifecycle operations. Publish which flow commands and Maestro versions work.
  4. An end-to-end contract: tie framework sessions to the allocated device, enforce ownership and expiry, return test exit codes and artifacts, and release the device on failure. Validate the complete build → install → assertion → evidence → cleanup path before claiming compatibility.
A managed runner is an alternative to maintaining provider-specific driver forks; matching Limrun’s user outcome does not require copying its exact architecture. For released workflows, use Revyl’s native device commands or keep your existing framework execution environment.

Device quickstart

Provision a device, run your own commands, collect evidence, and clean up.

Appium

Use the supported native subset and understand its compatibility limits.

Maestro

Understand how YAML flows connect to Android and iOS devices.

Embed a live device

Put an interactive app session in your own product, website, or docs.

​
Device and build boundaries

These workflows use virtual devices, not physical handsets. Bring an iOS simulator .app or zipped .app, or a single Android .apk with a supported 64-bit ABI. A physical-device .ipa or Android .aab is not interchangeable with those artifacts. See Artifact requirements. Treat session output, screenshots, logs, and app state as private. Keep API keys in your secret manager, use a test account and non-sensitive fixture data, and stop the specific session your job created. Parallel jobs should each use their own session ID rather than relying on a shared active-device selection.