Skip to main content
Builds are the foundation of everything in Revyl because tests, reports, and app comparisons all depend on having a concrete app version to run against. Builds are stored in an App and can either be built on Revyl’s cloud infrastructure or uploaded from an external source.

Creating an App

Create separate apps for each platform + environment you need: iOS Production, iOS QA, Android Staging. Don’t create a new app for each release, just upload a new build to the existing app.
  1. Click Create app
  2. Enter a name, pick iOS or Android, and optionally add a description
  3. Upload a build

Ways to add builds

Revyl supports four main paths for getting builds into the platform.
  • Add builds manually: Upload an Android APK or iOS app bundle directly from the Revyl UI. Click Upload build on the Builds page and pick the app, or on the app’s own Builds page. Drag in an .apk or .app bundle, name it (e.g. v1.2.0, sprint-42)
  • Import from Expo: Automatically sync your EAS builds directly with Revyl (see Expo Auto Sync).
  • Remote build: Build from source in Revyl’s cloud environment (see Remote Builds).
  • CLI: Upload builds from your terminal or CI pipeline (see CLI).
  • Signed store builds: Sign a release build with your own certificate or keystore and upload it to App Store Connect or Google Play from a remote build (see Signed Store Builds).
Supported formats:
  • Android: .apk (or .zip containing .apk)
  • iOS: Simulator .app bundle
Revyl requires simulator or emulator builds to function. See Artifact Requirements and Framework Guides for more details.

Types of Builds

Depending on the framework being used, builds differ in how much of the app and assets are bundled. Frameworks like Expo and React Native enable quick iteration via hot-reload by decoupling JS from native modules during local development.
  • For testing: Use a preview or production-like build that bundles the app binary, JS, and all required assets and native modules.
  • For dev loops: Use a dev build that relies on a local dev server (e.g., Metro) for live JS bundling and hot-reload.
See specific Framework Guides for further guidance.
Name apps by platform + environment (for example, iOS Production, iOS QA, Android Staging) so tests and dev workflows target the correct app. Run tests and CI against preview/release builds; reserve dev/debug builds for local dev loops.

Active Build

Every app has one active build that tests run against by default:
  • Latest: the most recent upload, selected automatically
  • Pinned: you manually set a build via Set as current in the build menu, or with the pin on its row in the app’s Builds list
Upload a new build and every test on that app picks it up, unless the test is pinned to a specific version.

App Overview

Click any app to open its Overview. The top row shows the app’s sessions, device time, builds, and Proof of Changes runs over the last 7 days, each compared with the 7 days before. An app with no builds yet, or no Proof of Changes runs yet, shows a zero with a prompt beside it to upload its first build or connect GitHub. Below that are a chart of the app’s sessions per day beside its recent builds, a preview of the app’s Atlas map beside its open Atlas feedback, and its tests with the 7-day pass rate. While you are inside an app, the header shows the app’s name beside a tile with its platform logo, and the sidebar keeps its usual order but lists only that app’s sections: Overview, Atlas, Explorations, Sessions, Cloud Agents, Builds, Tests, and App settings. Workflows can span several apps, so they stay organization-wide. Click the app’s name in the header to return to its Overview, or the chevron beside it to jump to another app or back to All apps; apps you visited recently are listed first. All apps at the top of the sidebar also leaves the app. Picking an app from an organization-wide page such as Sessions opens that app’s version of the same page (from Workflows, its Overview). Opening a session, test, report, exploration, or proof run that belongs to one app, or a Cloud Agent conversation linked to exactly one app, switches the header and sidebar to that app. When the sidebar is collapsed, its top button is Back, which returns to the page you came from. Inside an app:
  • Builds: the same list as the Builds page, limited to the app. Filter by build profile, search, or status. Each build shows its readiness (how many of the app’s tests passed, failed, or have not run on it), the build the app runs is tagged Current or Latest, the pin on a row makes that build current, and Run previews the latest build or explores the app
  • Explorations: autonomous exploration runs launched against the app, with Explore app to start one
  • App settings: the app’s name and description, the system prompt injected into every LLM call on the app, its StoreKit configuration on iOS, and its public embeds. Settings on the Overview opens the same page

Builds Page

Builds in the sidebar lists every build across your apps, live builds first: remote builds while they queue and run, finished and failed remote builds, and uploaded builds. Search by version or package name, or filter by platform or status. Choose an app from the header to open its Builds page, where you can filter by build profile. Upload build uploads a build to an existing app; for a new app, use Create one instead or Create app on the Apps page. Open a remote build to follow each step on its Steps tab, including Revyl signing and store upload steps, with its logs. Completed remote builds and uploads show the artifact’s filename, size, type, SHA-256 checksum, package, and validation result under Artifact. Package and validation details appear when the artifact can be inspected successfully. A build with only one of these sections shows it without tabs. The open tab is part of the page address, so a copied link opens the same tab.

Expo Auto Sync

Import Expo and EAS builds into Revyl

Remote Builds

Build from source in Revyl’s cloud environment

CLI

Upload builds from the terminal or CI

Builds

Return to the Builds section overview