Builds and downloads

When builds start

Your first build starts when you finish the setup steps. After that, start a new one with Start new build whenever you need a new version (see Release an update). The page shows each step while a build runs.

Before a build starts

Before a build starts we check what it will use: your icon, your Firebase files against your app's package name and bundle ID, your App Store Connect key and your signing keys. Anything that would make it fail shows under Before your next build with what to do and a link to fix it; the build waits until it's fixed. Things that won't stop it (no Firebase files yet, for example) show as good to know.

When a build doesn't finish

The page says why in plain words and what to do, for example a Firebase file for another package name, an Apple agreement waiting to be accepted, or a version the store already has. What the build printed shows the end of the build's output, without your keys and passwords. If it was our build machine, start the build again.

Rebuild a build as it was

Rebuild as it was, next to a ready build, makes it again from the same app code, settings and store listing, with a new version number. Use it when the newest build has a problem and you want the earlier app back in the stores.

Release in stages

When we publish for you, Release in stages sends a new version to some people first. On Google Play, choose who gets it first (1% to 50% of Android users): the version goes to production for that share, and the page shows Continue, Stop and Release to everyone until it reaches everyone. On the App Store, phased release lets Apple send it to more iPhone users each day over seven days; you can Pause, Resume or Release to everyone. Your Google Play service account needs the right to release to production.

Versions people can use

Under Versions people can use, set a minimum version: older versions of your app stop at an Update required screen with a button to the store they came from (Google Play, Galaxy Store, AppGallery, or your page on the App Store). A recommended version asks older versions to update once; people can carry on with Not now. Every copy of your app asks when it opens, whatever its content comes from. Leave a box empty to allow every version.

Go back to an earlier build

Go back to this build, next to an earlier ready build, puts back what that build had: your app's name, colors, template, font, icon and logo, and its store listing. The pages you had published then come back as your draft on Pages & look, to check and publish. The build is then made again from the same app code, with a new version number for the stores. Under Versions people can use, Versions in use shows which versions people opened over the last 7 days, and which are below your minimum.

Automatic builds

On plans with automatic builds, a save that changes the app itself (its name, icon, colors, Firebase files, links), its store listing when we publish for you, or the stores it goes to starts a new build ten minutes after your last save, so several changes go into one build. Pages, texts, prices and settings reach the app without a build. The page says when the waiting build starts; Start new build starts it now.

Your files

• APK: install it directly on an Android phone to test.
• App Bundle (.aab): the file you upload to Google Play.
• iOS build (.ipa): the file you upload to App Store Connect. On Pro and Business it's uploaded to TestFlight for you. It comes with the Growth plan and up, and needs the App Store Connect API key on the Publishing step.
• Android upload key: the keystore and its passwords. Every future update on Google Play needs this same key: keep a copy somewhere safe.
• Store assets: store icons, the feature graphic, your screenshots and your listing text.
• WordPress plugin (.zip), on WordPress sites.

Download links are made fresh each time the page opens and expire after a few minutes. Reload the page for new ones.

Your signing key is kept safe

Your Android signing key is created with your first build, stored encrypted, and never replaced, so you can always update your app on Google Play.

Test before you publish

Install the APK on an Android phone (allow installs from your browser or files app when the phone asks). On Pro and Business, test the iOS build with TestFlight.