Prerequisites
- Revyl CLI installed and authenticated (
revyl auth login) - An Expo or React Native project with a dev client build
Step 1: Configure hot reload
revyl init --detect from the Expo app directory. If detection
still needs correction, edit build.framework and the generated development
profile, then run revyl config validate.
Configure the custom URL scheme in the Expo app before building the development
client; the scheme is attached to the build artifact rather than authored in
.revyl/config.yaml. See Configuration Files for the
profile schema and Dev Loop Framework Guides for
framework-specific setup.
Step 2: Upload a dev build
Upload a development client build. It lands on the Revyl branch named after your Git branch, which the first upload creates, or on the app’s default branch outside a Git checkout:revyl build runs in the cloud.
The dev loop remains local unless you use revyl dev --remote.
revyl dev resolves one named profile/platform recipe, runs on the branch named
after your Git branch, and installs that branch’s default build. Pass
--branch <name> to both build and dev to use another branch. For every branch
and build rule, see Dev Loop.
Step 3: Start the dev loop
revyl dev first
prefers one unique development-like profile and then accepts only a sole
eligible profile or platform. It prompts for remaining choices interactively
and fails with the valid choices non-interactively. This is invocation-time
selection, not an active/default profile.
This:
- Starts your local dev server (Expo via
npx expo start --dev-client, or Metro vianpx react-native start) - Creates a Revyl relay to expose it to cloud devices
- Installs the dev client build on a cloud device
- Opens the device session in your browser
revyl dev --debug to print the diagnostic probes.
Now edit code locally and see changes reflected on the device instantly.
Platform and build overrides
revyl dev rebuild operations all use that same recipe.
If Revyl starts Expo and verifies relay transport but times out proving the
first Expo manifest, retry with --force-hot-reload first. This launches after
the relay and dev server start, skipping only the manifest and bundle proof. If
the app loads, keep working; if the dev client shows a project load error,
restart Expo/Metro or capture revyl device report --session-id <id> --json.
If you already run Expo with its own tunnel, you can collapse the manual device
start + deep-link step into one command:
--no-build reuses an existing build and keeps rebuilds off for this session.
Add --branch <name> to require a specific branch’s build.
--tunnel accepts either the full Expo dev-client link or the raw https://...
tunnel URL. Passing the full dev-client link does not depend on an authored
scheme field in the local Revyl config. Prefer the Revyl relay first in
cloud-agent environments; use Expo tunnel fallback only after device screenshots
or revyl device report --session-id <id> --json show force mode still did not
load through the relay.
Step 4: Interact with the device
Userevyl device commands to observe, act, and verify in a tight loop.
Step 5: Verify flows live
While the dev loop is active, verify outcomes with device commands:Step 6: Create tests from the session
After verifying a flow manually, convert the device session into a regression test:Step 7: Promote to regression
Once the test is stable, push and run it:Device-first flow
Start a plain device session first, then attach and run the dev loop on it:revyl dev --context checkout again to resume, or revyl dev stop to detach.
Context management
Team sharing
All developers push builds to a shared app container (theapp_id in config). Each developer gets their own cloud device session, relay URL, and local server. For JS projects, multiple developers can share the same dev build and still see their own code changes.