Overview

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

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

​

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.

​

Default branch and default build

Every app has a default branch, and every branch has a default build: the build a run uses when it picks the branch but no build. A branch’s default build is either Latest build, its newest usable build, or the build the branch is pinned to. Uploads don’t pin a branch unless asked (--pin, or pin: true in the API). A branch on Latest build runs each new upload because it is the newest; a pinned branch keeps its pin. Pin a branch from a build’s row or menu, by choosing Pinned build in App settings > Build branches, with revyl app branch pin, or with --pin on revyl build or revyl build upload. Unpinning the branch, or deleting its pinned build, puts it back on Latest build. Use App settings > Build branches to manage branches, change the default branch, or change a branch’s default build. A saved or run-only choice of Automatic uses the branch’s default build; Latest build uses the branch’s newest build, even when the branch is pinned, and Exact build uses the one you pick. All branches · Latest build uses the newest build on any of the app’s branches, and the run shows which branch it came from. Apps created before branches started with their default branch pinned to the build they ran. When uploads stopped pinning, every branch pinned to its newest usable build moved to Latest build, so those branches now run each new upload. Pin a branch again to keep it on one build. Browser uploads and Expo imports go to the branch you choose, or the app’s default branch; Expo auto-sync goes to the branch chosen for each platform in Integrations > Expo, or the app’s default branch. CLI uploads go to the app’s default branch unless you pass --branch <name>. Pass it in scripts that must keep uploading to one branch even if the default changes. See Build branches for saved selections and all branch controls.

​

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 icon and name, 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. Point at the app’s name to show an × beside it, which leaves the app for the same page across All apps; the App row at the top of the sidebar does the same. 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, as it is on sessions, reports, the test editor, and Atlas, its top button is Back, which always returns to the page you were on before this one. Each app’s icon comes from its builds. After an upload or build completes, Revyl checks its icon in the background at most once per app every 24 hours. Uploads during that window keep the existing icon. Unchanged icons are not uploaded again, and managed review builds do not change the icon. An app without an icon shows a plain tile with its platform logo. For a ZIP-wrapped Android build, the contained APK must be at most 48 MiB for icon extraction. Uploading the APK directly avoids this icon-only size limit. Inside an app:

• Builds: the same list as the Builds page, limited to the app. Filter by branch, 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 each branch runs by default is tagged Default, whether the branch follows Latest build or is pinned (the Branch column names its branch), an empty branch shows the command that uploads to it, the pin button on a row pins its branch to that build (on the pinned build, it unpins the branch), and Run previews the shown branch’s build in a simulator or starts an exploration on that branch
• Explorations: autonomous exploration runs launched against the app, with Explore app to start one
• App settings: the sidebar switches to the app’s settings, with a back row at the top that returns to the page you came from. General holds 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. Build branches lists the app’s branches with each one’s default build and latest build: create or rename one, change the default branch, or change a branch’s default build to Latest build or a Pinned build picked from a searchable list of its builds. Under Repository, Build profiles, Pull / merge requests, and Session settings each show one part of the linked GitHub or GitLab project root that builds the app: the app’s own build profiles, what Revyl builds, checks, and posts on its pull or merge requests, and the defaults for the device sessions the project root starts. With proof of changes on, Pull / merge requests links to the authentication bypass on Session settings, which proof runs use to start the app signed in. From any of them, Connect repository starts first-time setup. If both providers are connected to the organization, you choose a provider during setup; an already linked app stays on its provider. The Repository card identifies the connected provider, and GitLab apps show the repository webhook setup and delivery status on Pull / merge requests; the project-root picker switches between the app’s project roots or adds one, Repository settings opens the whole project root, and a badge marks a project root shared with other apps; pointing at it lists up to four of them, each opening that app on the same tab. Changes on the three tabs are saved together, and saving a shared setting first names the apps it also changes. Below them, the organization and account settings (Users, Plans, Billing & Usage, Org Settings for owners, My Account, and API Keys) open inside the app, so you stay in it. Switching apps from the header keeps the same tab, and All apps opens the organization page that holds the same settings. 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 branch or 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.

​

Related guides