Skip to main content
Every run uses a real build of your app, running on a virtual device. There are two ways to get a build to Mini, and you can mix them per app.
Connect your repo and Mini does the build for you. When a run needs a fresh artifact, it pulls the right commit, compiles for iOS and Android, and hands the binary to the test device.Requires:
  • The MiniTest GitHub App installed on the org. See GitHub integration.
  • The build env vars your app needs to compile (see below).
Monorepos are supported — point Mini at the subfolder that holds your mobile app in App Settings → Builds.This is the path that powers PR checks: when a PR opens, Mini builds the head commit, runs the suite, and posts the verdict back on the PR.
For Expo apps, Mini supports repack builds — incremental rebuilds that reuse the native shell when only the JS bundle has changed. First build of the day is full; the rest are fast.

​
Build env vars

Most mobile builds need at least one env var to compile cleanly: an API base URL, a Sentry DSN, a feature flag override. Mini stores them per app and injects them at build time.Set them in App Settings → Builds → Environment Variables. Add, edit, or remove individual values. Changes take effect on the next build.
Values are encrypted at rest and only decrypted inside the build environment. They don’t appear in dashboard logs, run reports, or copies of the fix prompt.

​
Build options

Two more switches live in App Settings → Builds → Advanced build settings. Like build env vars, they only apply when Mini builds your app from your repo. An uploaded build is already compiled, so these options can’t touch it.

​
Testing RevenueCat purchases

Experimental. These patches modify your native project inside the build environment, and every app’s build setup is different. The first build after enabling may fail, or purchases may not complete. When that happens we get the failed build on our side and investigate to make the patches work with your app. You can switch the toggle off at any time to go back to normal builds.
If your app monetizes through RevenueCat, runs can exercise your real purchase flows, paywalls included, against RevenueCat’s Test Store. No mocking on your side.This works for React Native and Expo apps using react-native-purchases, on both iOS and Android. Other frameworks aren’t supported yet.To set it up:
  1. Create a Test Store in your RevenueCat project and copy its test_ API keys. RevenueCat’s sandbox testing guide covers two options; the one used here is the Test Store, not the platform sandboxes (Apple sandbox and Google Play testing tracks).
  2. Put those keys in your build env vars (above), under the same variable names your app reads its RevenueCat keys from. Your app must read the key from configuration rather than hardcode it, so test builds hit the sandbox while your production builds keep using the production key.
  3. Turn on RevenueCat sandbox patches in App Settings → Builds → Advanced build settings.
On the next build, Mini patches the native build files so the binary on the virtual device can complete sandbox purchases. Your source code is never modified; the changes only exist inside the build environment.

​
Loop animations are frozen by default

To the agent, an infinite spinner looks exactly like a screen that’s stuck loading. To avoid runs failing on animations that were never going to end, Mini ships every Expo and React Native build with Disable loop animations turned on.At build time, looping animations are patched to settle immediately: Animated.loop completes on its first frame, and Reanimated’s withRepeat runs one cycle instead of repeating. Everything else keeps working as shipped, including transitions, gestures, and any animation that ends on its own.Turn the toggle off in App Settings → Builds → Advanced build settings if your app has looping animations that need to keep running during a run.

​
Picking a build for a run

When you trigger a run from the dashboard, the build picker lets you:
  • Use the latest build for the configured branch (default).
  • Pick a specific commit or build ID.
CI-triggered runs always use the build produced by the triggering commit. There’s no manual picking when Mini is gating a PR.

​
Web preview URLs

When you run a web build, Mini deploys it to a generated preview host you can open and share. The host looks like this:
<tenant_slug> is your Workspace slug, which you’ll find in Settings → General. <preview_key> is derived per build, so each build you run gets its own host on preview.minitap.ai.

​
The injected env var

The build automatically receives MINITAP_PREVIEW_URL, set to that preview URL. You don’t add this variable yourself. When you need the host inside your build config, reference the placeholder {{MINITAP_PREVIEW_URL}} and Mini fills it in at build time.

​
OAuth and allowed redirects

If your web app uses OAuth or any origin allow-list, preview builds need their host accepted. Add the wildcard domain below to your provider so every preview build authenticates without a per-build change: