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, Android, or Web, and optionally add a description
3. For iOS or Android, upload a build. For Web, optionally enter your first deployed HTTPS URL and commit SHA, then click Create app. Web apps do not need a package or bundle ID.

You can create a Web app without a URL and add one later: open Sessions → Start session, choose Web and your app, then click Add URL build. URLs cannot contain credentials, query parameters, or fragments; URL-build commit SHAs use 7–40 lowercase hexadecimal characters. A Web recipe can instead build a static or server application with revyl build --platform web, locally or on Revyl’s runners. The resulting bundle runs inside its Web session.

​

Ways to add builds

Revyl supports these 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).
• Remote build: Build from source in Revyl’s cloud environment (see Remote Builds).
• CLI: Upload builds from your terminal or CI pipeline (see CLI).
• Web URL: Register a deployed HTTPS URL as a Web app’s build, optionally linked to a commit.
• Web bundle: Build a declared output directory with a Web recipe; the CLI validates and uploads its tar.zst and runtime settings.
• 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
• Web: A recipe-built tar.zst, with index.html for static apps or a configured server start command

​

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.

​

Branches

Every build belongs to a branch of its app. Each app has a default branch, and each branch runs its default build: its newest usable build (Latest build) or a build you pin. CLI uploads go to the branch named after your Git branch, and dashboard uploads go to the branch you choose. See Build branches.

​

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 haven’t run on it.
  • The Branch column names each build’s branch, and the Default tag marks the build each branch runs by default. The pin button on a row pins its branch to that build, or unpins it on the pinned build. See Build branches.
  • An empty branch shows the command that uploads to it. 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; see Manage branches. 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