Runtime / Mobile
Device infrastructure
Build your own mobile workflows on Revyl's cloud iOS simulators and Android emulators.
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
| Your workflow | What Revyl provides |
|---|---|
| A script or CI job that exercises an app | Session provisioning, app installation and launch, device actions, and screenshots through the CLI. |
| An agent that operates a mobile app | Device tools through MCP, including screenshots, actions, and optional natural-language instructions and validation. |
| A remote development workflow | Cloud devices with a live viewer and a build, install, and reload loop. |
| An interactive demo on your site | An embeddable live device with its own bounded session lifecycle. |
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
Your script, CI job, or agent
|
Revyl CLI / MCP
|
Managed device session
|
iOS simulator / Android emulator
|
Your app + live view + evidenceYou 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.
| Workflow | Revyl today | Limrun's documented flow |
|---|---|---|
| Build an app | revyl build --remote runs the configured build recipe in the cloud and uploads the artifact. | lim xcode build . and lim gradle build . provision or reuse a cloud build sandbox and run remotely. |
| Run your app | Start a device with an uploaded app or build, then control it through Revyl CLI or MCP. | Attach an iOS simulator to the build sandbox, or create a device with an installed artifact. |
| Appium on Android | No public ADB tunnel or Appium endpoint. | Standard Appium drivers connect through an ADB tunnel. |
| Appium on iOS | No public Appium endpoint or XCUITest adapter. | A forked XCUITest driver forwards host operations; WebDriverAgent is reached through an authenticated tunnel. |
| Maestro | No public framework adapter or Android ADB tunnel. | An iOS CLI wrapper connects stock flows to a patched XCTest runner. The guide directs Android users to Appium. |
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.
Appium and Maestro
The device quickstart uses Revyl's native device
commands. An unchanged Appium or Maestro suite needs a framework connection
layer; a viewer URL is not an automation endpoint. The
Appium driver and
Maestro runner are source-installed integrations
that run a native command subset against existing device sessions. Get them
from RevylAI/appium-revyl-driver
and RevylAI/maestro-revyl-driver.
The Maestro runner embeds the Maestro runtime; it is not a plugin for stock
maestro test. Neither provides standard UiAutomator2/XCUITest or full Maestro
compatibility; each page lists the commands it supports.
Provision a device, run your own commands, collect evidence, and clean up.
Use the supported native subset and understand its compatibility limits.
Understand how YAML flows connect to Android and iOS devices.
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.