> ## Documentation Index > Fetch the complete documentation index at: https://docs.revyl.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](/remote-builds/quickstart) to compile your app in the cloud too. ## Separate the device from the test runner ```text theme={null} Your script, CI job, or agent | Revyl CLI / MCP | Managed device session | iOS simulator / Android emulator | Your app + live view + evidence ``` 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**. | 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](/infrastructure/quickstart) likewise starts with the minimum device workflow; detailed build setup lives in the [Builds](/builds/index) guides. Sources: Limrun's [quickstart](https://docs.limrun.com/docs/quickstart), [Gradle builds](https://docs.limrun.com/docs/android/build-with-gradle), [Appium](https://docs.limrun.com/docs/testing/appium), and [Maestro](https://docs.limrun.com/docs/testing/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](/infrastructure/appium) and [Maestro runner](/infrastructure/maestro) 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](/infrastructure/maestro#text-input-through-the-viewer-channel) 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. 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](/builds/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.