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 → Source code → Source folder.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 & env vars → Build environment variables → Edit variables. Add, edit, or remove individual values, or paste a whole .env file into any key field to fill several rows at once. 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 & env vars, right under the build instructions. 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 Patch RevenueCat in App Settings → Builds & env vars.
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 looping 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 & env vars 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.

​
TestFlight builds on physical iPhones

If physical devices are enabled for your workspace, a run can use Minitap’s real phones instead of virtual devices. Android phones need no setup: upload your APK as usual, or let Mini build it from a commit, and pick a physical device when you start the run. On iOS, the iPhones install your app from TestFlight, so you don’t upload an .ipa for them, and an iOS build Mini makes from a commit runs on a virtual device.
  1. In App Store Connect, open your app’s TestFlight tab and add ios@qa.minitap.ai as an external tester. A public TestFlight link works too.
  2. When you start a run, set the iOS card’s Device picker to a physical iPhone. The build list then offers your existing TestFlight links, and add a new TestFlight link opens a dialog: confirm the tester if you have not yet, then paste the public link (https://testflight.apple.com/join/...) and your bundle ID; the run uses it right away. Version and build number are optional labels. The tester confirmation also lives in App Settings → General → Physical iOS devices.
Each platform card’s Device picker offers Cloud (virtual device), Physical, any model, or a specific model from the device farm with how many are free right now. TestFlight links carry a TestFlight badge in the build list and can only be picked once the iOS card is on a physical device. Reruns keep the device choice of the original run.
The iPhone installs whatever build TestFlight currently serves for that link. If the run fails with a TestFlight: message, the beta is usually full or the tester invite hasn’t been accepted yet.

​
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: