Mobile App Cloud Builds: What Moves Off Your CI Runner

TL;DR A mobile app cloud build runs your existing iOS or Android build recipe on managed infrastructure and returns an installable artifact. Your CI pipeline still chooses the recipe, starts the job, handles the result, and decides what happens next.

What a mobile app cloud build moves

A cloud build moves the machine that executes compilation. It does not replace the build recipe or the pipeline around it. Revyl remote builds run Expo, React Native, native iOS, and native Android recipes on cloud runners, then store the finished artifact on the selected Revyl app. For iOS, the documented output is a simulator .app or an archive containing one. For Android, it is an installable .apk. Those boundaries are documented in the remote-build overview.

This matters to a CI owner because the handoff stays narrow. CI checks out the revision and invokes the build. The remote runner executes the project’s ordered setup and build commands. Revyl registers the resulting artifact so a later pipeline step can launch a cloud device or run a test against it. The current feature is early access and must be enabled for the workspace, as stated in the remote-build overview.

Keep one recipe for local and remote execution

The build contract lives in .revyl/config.yaml. A named profile contains an iOS recipe, an Android recipe, or both. Each recipe defines the app destination, ordered commands, artifact path, environment, secret references, caches, and optional toolchain image. The configuration reference says local and remote execution resolve the same recipe. Adding --remote changes where it runs and activates the remote image and caches.

That removes a common source of CI drift: a cloud-only script that slowly stops matching the command developers run locally. Keep the recipe in the repository, pass the profile and platform explicitly in unattended CI, and review recipe changes with the application code.

Run the recipe from CI

The documented CI pattern is a CLI invocation inside the workflow you already use. This command selects the release profile and its iOS recipe, executes that recipe on a Revyl runner, and returns a machine-readable result. It is copied from the CI builds guide.

# Source: https://docs.revyl.com/builds/ci-builds (revyl-cli v0.1.104)
revyl build --profile release --platform ios --remote --json

Isolation and caching are separate decisions

Every Revyl remote build runs in a clean, single-use VM. Cache state is restored into that clean workspace rather than keeping a long-lived runner around. The caching reference separates two mechanisms: compilation caches are on by default for Xcode, Gradle, and native C or C++ work, while configured path caches are opt-in for directories such as dependencies or generated files.

A configured path cache updates only after a successful build, so a failed job does not replace the last saved archive. Cache keys are scoped by organization and platform. Treat the cache key as part of the build contract, keep artifact globs specific enough to avoid stale output, and compare a cold run with a repeat run before deciding that a cache helps. The same caching reference documents those behaviors and the cold-build control.

Pin the toolchain that explains the result

A repeatable build needs more than the same source revision. The runner image fixes the operating system and the Xcode or Android SDK toolchain. Revyl lets a recipe pin an image, and a command-line image override takes precedence for one invocation. The current image catalog and precedence rules are listed in the toolchain reference.

Pinning is useful when a compiler or SDK change can alter the result. It also makes a failure report actionable: the revision, profile, platform, and image together identify what ran. Use the platform default only when accepting a changing toolchain is intentional.

What stays in your pipeline

Cloud compilation does not own your release policy. CI still decides which revisions build, which profile is selected, which checks must pass, and whether an artifact is promoted. It also supplies authentication and references to encrypted build secrets. Revyl’s configuration reference distinguishes non-secret environment values from stored secret references and warns against putting credentials in ordinary environment overrides.

Keep failure handling there too. A non-interactive job should select profile and platform explicitly, consume the structured result, and stop the pipeline when the build fails. If the next step needs a device, use the registered artifact only after the build reports success.

Price the queue and the build, not just the runner

Revyl remote builds are metered by build minutes, and a workspace without build credits receives a billing error. The public remote-build overview does not state a per-minute price, so a cost comparison needs the terms for your workspace rather than an invented rate.

Measure the current pipeline before moving it. Record queue time, execution time, successful build rate, and monthly runner cost over the same review window. After the move, keep the revision, recipe, and toolchain comparable. A lower machine bill is not a win if queue time or failed-build retries rise. The useful comparison is cost per successful artifact and time from queued job to usable artifact.