Skip to main content
Built your app on your laptop or your own CI? Upload the file and Mini runs your scenarios on it. This page covers which file fits which device, how to upload from the dashboard and the CLI, Android App Bundles, TestFlight and Ad Hoc builds for physical iPhones, and how to check which build a run used. Prefer Mini to compile from a commit? See Builds from your repository.

​
Which file for which device

Not sure which devices you’ll use? See Devices.

​
From the dashboard

In Run tests, each platform row has a Build cell. Open it and click Upload a build…, then pick the file. The build cell also lists Recent builds, split into Your builds and Team builds, and View all builds searches the rest. The dashboard reads the file and tells you where it can run. Upload a device .ipa while the iOS row is on the simulator, and it says the build runs on physical iPhones and offers to Switch. A build marked Flagged as broken can still be picked.

​
From the CLI

The platform is detected from the extension. The CLI prints the build ID to start a run with.
Then start a run on that build:
  • Pass --platform ios or --platform android when the file name doesn’t end in a known extension.
  • A device .ipa uploaded without --physical is rejected with a hint to add the flag, and a simulator build uploaded with --physical is rejected too.
  • --ios-physical and --android-physical need physical devices on your workspace, see Devices.
Every CLI command is in the CLI reference. Build environment variables and build options don’t apply to uploads: your file already has everything baked in.

​
Android App Bundles (.aab)

Upload the same .aab you send to Google Play, from the dashboard or the CLI:
Mini turns the bundle into the APKs a device installs. That takes a minute or two, so the build shows as converting first. The CLI waits until the build is ready, so your CI can start a run right after (--no-wait skips the wait). If the bundle can’t be converted, the build is marked failed with the reason. One upload runs everywhere. A bundle without asset packs becomes one build for all devices. A bundle with Play Asset Delivery packs becomes an Emulator version and a Phone version shown as one upload, and the fast-follow and on-demand packs are installed the way Google Play’s local testing does it. Start runs with the ID the upload printed: Mini installs the right version on each device. A bundle with no arm64 code has no Phone version, and the build picker says so. Mini signs the generated APKs with your workspace’s own signing key. Two things follow:
  • Google sign-in checks the app’s signing certificate. Register the key’s SHA-1 in your Firebase project, or as an Android OAuth client in Google Cloud. minitest build signing-certificate prints it.
  • Play Billing and Play Integrity only trust builds signed by Google Play, so they don’t work on these builds.

​
Physical iPhones: TestFlight and Ad Hoc

Physical iPhones can’t install a simulator build. They get your app in one of two ways.
Minitap’s iPhones install your app from TestFlight, so there is no build to upload. New builds and new iPhones need nothing more from you.
  1. In Run tests, set the iOS row’s Run on to Physical device.
  2. Open the Build cell and click Add a new TestFlight link.
  3. The first time, the dialog shows an Apple ID. In App Store Connect, open your app’s TestFlight tab, add that Apple ID as an external tester (or share a public link), then click I added the tester.
  4. Paste the TestFlight public link (https://testflight.apple.com/join/...). Minitap asks for the Bundle id only if it doesn’t know it yet. Click Use this TestFlight link.
The link then shows in the build list with a TestFlight badge, and you can only pick it while the iOS row is on a physical device. The iPhone installs whatever build TestFlight serves for that link at the time of the run. If the run fails with a TestFlight error, the beta is usually full or the tester invitation hasn’t been accepted yet.

​
Which build a run used

  • Runs list: the Build Version column shows the app version and build number, like v2.3.1 (142), with the branch, pull request or commit underneath. For a file you uploaded, hover to see its name.
  • Run report: under the recording, a run on a physical iPhone from TestFlight shows the build the iPhone installed, like “Tested 2.3.1 (57) via TestFlight”, next to the phone model and iOS version.
  • CLI: minitest build get <build_id> returns the build’s appVersion, buildNumber and commitSha.
Runs started from a pull request always use the build of the commit that triggered them.

​
Next steps

Devices

Simulators, emulators and physical phones, and how a run picks one.

Builds from your repository

Let Mini compile the app from the commit each run needs.

Start a run

From the dashboard, a pull request, Slack or the CLI.