Builds
Test builds, store builds and sending to the store. What each step produces, the app id, version numbers, and why you rarely need to rebuild.
Updated September 25, 2026
Open Builds. Pick the store at the top, Google Play (Android) or App Store (iOS), and the page lays out three steps. Next for you marks the one to do next.
Before your first build, set the App id on the card at the top of the page if the wizard did not. It is baked into the binary and locked for good after your first store build (step 2).
Step 1: Test it on a phone
Optional, and free during the trial. Android produces an installable .apk you can put on your own phone. When it finishes, the line under the build says whether the .apk is a signed release build; if it is, it is ready to hand to customers, and your install link offers your newest .apk until the app is on Google Play.
To get it onto your phone, scan the QR code Builds shows beside the .apk with your Android phone. The page it opens downloads the app and walks you through the prompts Android shows the first time. It works on Android phones only. Once the app is on Google Play, that link opens Google Play instead, so no code is shown.
On iOS, step 1 is labelled Compile check (not installable): a simulator build that proves the app compiles. It cannot be installed on an iPhone or iPad and never reaches TestFlight or the App Store; the way onto your own iPhone is the store build and TestFlight, which take a paid plan and your own Apple Developer account.
On either store, step 1 does not change the version number.
Step 2: Make the store build
- Android builds the signed .aab app bundle that Google Play needs. Android phones cannot install an .aab directly; it is for uploading. The same build also makes a fresh signed .apk, which becomes the one your install link offers.
- iOS builds, signs and uploads to TestFlight. This is the build Apple reviews. Invite testers from App Store Connect.
Every store build gets a new version number. Store builds need the app id, the app name and an icon, and they are refused for a store that is still a test address.
Step 3: Send it to the store
- iOS: Submit for review sends your latest TestFlight build to Apple, along with the listing and screenshots from the Publish page. Nothing is rebuilt.
- Android, with Google Play connected: Send to Google Play production promotes the internal-testing build. Nothing is rebuilt.
- Android, without a Play connection: download the .aab, upload it in Play Console, then mark it sent on the Publish page.
While a build runs
The tracker shows Queued, Building, Signing, Submitting, In review, Live, or Failed. One build runs per app at a time; a second request is refused with A build is already running for this app. If the build machine is busy or offline, or your workspace has hit its daily build limit, the page says so and you can try again later.
You don’t need to keep the page open. When a build finishes or stops, the workspace owner gets an email saying how it ended, with a link back to it. On Google Play it says what Google did with the release: on the track, saved as a draft that still needs its rollout button, or saved but not sent for review. If builds keep failing, you get at most one failed-build email per app per hour.
Build history lists every build with its platform, version, lane, status and artifact. Each artifact shows its file name, size and checksum, and can be downloaded. Only the newest three builds per app per platform keep their files.
Do you actually need a new build?
Usually not. Pressing build again when a build already exists opens a reminder: changes to your design, content and products reach installed apps on their own. Build again only for the launcher icon, the app name on the home screen, the app id, the native launch-screen colour, or a change of store domain.
App id rules
Lowercase, dot-separated, at least two segments, letters, numbers and underscores only, up to 100 characters. A handful of reserved ids are refused. Test builds work without an app id; store builds do not.
Version numbers
Store builds raise the version. Test builds and Android production promotions keep the current one. The Play and App Store checklists use the version to tell you what is where, for example v1.0.2 on TestFlight or v1.0.2 is a draft on Play production — roll it out.
Minimum phone versions
Your app runs on iOS 15 and newer and Android 7.0 and newer. StoreToNative keeps the build tooling current with Apple’s and Google’s yearly requirements, so a build you make today is accepted by both stores.
Billing and builds
During the trial, step 1 works and store publishing waits for a paid plan. After the trial ends, or if a payment fails, new builds pause while published apps keep working. See Plans and billing.
Still stuck? Open a ticket from Support in the console, or contact us.