Skip to main content
Cloud development lets your local app run on a cloud iOS simulator or Android emulator. You keep editing code in your normal workspace while Revyl handles the device, install, stream, and network path. Use it when a teammate, cloud agent, or worktree agent needs to inspect the app without setting up Xcode, Android Studio, Simulator, or Emulator locally.

​
Agent Quick Start

Copy this into your coding agent from the root of your mobile app repo:
Agent prompt

​
How It Works

The loop has three pieces:
  1. A development-capable build installed on the cloud device.
  2. A local dev server or build command running in your workspace.
  3. A Revyl session that connects the device to your local app through the CLI.
For Expo and React Native, most JavaScript and TypeScript changes hot reload through Metro. For other stacks, Revyl uses a rebuild-and-reinstall path when a change needs a new binary.

​
What You Need

  • A Revyl account with access to your workspace.
  • The Revyl CLI installed and authenticated. See Revyl CLI.
  • A Revyl app with an uploaded development build.
  • A project directory that Revyl can run locally.
For iOS, use a simulator .app or zipped .app, not an .ipa. For Android, use a debuggable APK whose native libraries include x86_64 or arm64-v8a. See Artifact Requirements.

​
1. Upload a Development Build

The uploaded build is the shell Revyl installs on the cloud device. It must be able to load local code or be rebuilt quickly for local changes. You can upload from the dashboard in Apps, or from the CLI:
Use the profile name and platform written for your project. The command runs one recipe in the cloud by default; no profile is stored as active/default. See Build Configuration for prerequisites. For framework-specific build commands, use the build guides.

​
2. Initialize Your Project

Run this from the app directory, not the monorepo root unless the app itself lives there:
revyl init creates .revyl/config.yaml with a stable project.id. When detection succeeds, it also writes build.framework and the detected iOS and/or Android named profiles. If detection picks a nested native project instead of the Expo or React Native app, rerun detection from the app directory:
If the result still needs adjustment, edit build.framework and the generated profile recipes in .revyl/config.yaml, then run revyl config validate. Expo projects also need a custom URL scheme configured in the Expo app and baked into the development client so Revyl can open it on the remote simulator and point it at Metro. See the CLI dev setup guide for monorepos, custom ports, schemes, and profile setup.

​
3. Start the Loop

You can start from the terminal or from a live session in the UI.

​
Start From the Terminal

Revyl starts the local dev server, creates a relay, installs your development build, and opens the cloud device session. The profile and platform identify the same named recipe used by revyl build. Explicit values win. When omitted, Revyl prefers one unique development-like profile and otherwise resolves only a sole eligible choice; it never stores an active/default profile or platform. Use selection or build flags when needed:
The resolved recipe stays with the dev context and drives any local, remote, or later rebuild for that context.

​
Start From the UI, Then Attach

If you already launched a session from the dashboard, attach your local dev loop to it:
This is useful when a teammate or agent already has the right device state open and you want to connect local code to that session instead of starting over.

​
4. Iterate

For Expo and React Native, save a JavaScript or TypeScript file and wait for Metro to update the cloud device. For other stacks, some code changes need a new build before they appear on the cloud device. Use the rebuild flow in revyl dev when that happens. Use the browser stream for visual checks, or drive the device from another terminal:
Work in small observe-act-verify loops: look at the current screen, take one action, then confirm the device did what you expected.

​
5. Handle Login Early

If the app needs authentication, decide how agents should reach a useful state before they start debugging. Good options are:
  • A stable test account with seeded data.
  • A staging-only demo mode.
  • A test-only auth bypass deep link.
For the deep link pattern, see Auth Bypass Deep Links.

​
Troubleshooting

CLI Dev Loop Guide

Full command reference for contexts, attach, tests, and rebuilds.

Auth Bypass Deep Links

Start sessions from authenticated app states.