How releasing works
In Releases, you take your app to the App Store and Google Play through your own developer accounts. You connect each store account, test your app, and then submit a version for review.
To see these steps in FlutterFlow, go to Releases and select How releasing works at the top of the page.
The four stages
Each store moves through the same four stages: Set up, Test, Review, and Live. The App Store and Google Play move independently, so one store can be in Review while the other is still in Test.
| Stage | What happens |
|---|---|
| Set up | You create your developer account, connect FlutterFlow to it, and add your app in the store’s console. |
| Test | FlutterFlow uploads a version of your app, and your testers try it through TestFlight or Google Play. |
| Review | You submit the version, and Apple or Google reviews it. |
| Live | People can get your app from the store. |
Testing and the public release are separate steps. Sending a version to testers doesn’t submit it for review.
FlutterFlow builds your app for iPhone only, so the App Store requires no iPad screenshots.
Releases shows a card for each store with its stage, whose move it is, and the next action when it’s your move. The bar at the top holds the next send, to one store or to both, and appears only when you have a version to send. See Release status.
Versions
FlutterFlow builds every version from your app, which is what you’ve pushed. Work in a thread that you haven’t pushed never reaches testers or the stores. Changes that you push reach the stores in the next version that you send.
The exception is going back to an earlier version: FlutterFlow builds that version again, and your app doesn’t change. See Earlier versions.
Store accounts
Your store accounts are FlutterFlow’s connections to your Apple Developer account and your Google Play account. They belong to your FlutterFlow account, not to one app, so you connect each store account once and every app can use it. An Apple team key can reach every app on your Apple team.
If you have only one store account for a store, a new app uses it automatically. If you have more than one store account, or if you created the app before connecting the account, an owner of the app chooses which one it uses, starting from the one that most of your apps use.
An owner can change it later: in Releases, select Change next to the store account that the app uses, or choose another account in Project Settings › App stores. After the store has the app, choose a store account that can reach it there. Moving the app to another Apple team or Google Play account takes an app transfer in that store.
Only an owner of your account can connect, rename, or disconnect store accounts. To see your store accounts, open the account menu and select App stores.
To stop one app from using a store account, open that store’s page in Releases and select Stop using on followed by your app’s name, or in Project Settings › App stores choose None for that store and confirm Stop using. The connection stays for your other apps.
When you disconnect a store account, uploads to that store stop for every app that uses it until you select another store account for each app. Before you confirm, FlutterFlow lists the apps that disconnecting affects. Disconnecting deletes FlutterFlow’s copy of the key. To revoke the key itself, go to App Store Connect for an Apple key or Google Cloud for a Google Play key.
To connect each store, see Connect App Store Connect and Connect Google Play.
What stays in the consoles
Some tasks stay in App Store Connect and Play Console, such as the questions that Apple and Google ask before they review a version. See Finish console setup.
Who can release
Owners and developers can send versions to testers and submit them for review. Billing members and viewers don’t see store status or versions in Releases. Only owners can connect a store for an app, choose the store account that it uses, and set its App ID. See Team roles.
Your allowance pays for the agent’s work. Every release builds from what you have pushed to your app. Asking the agent for a build in a thread uses allowance, like any other message to the agent.
When Apple requests changes, clicking Fix with the agent opens a new thread with a prefilled request; sending that request uses allowance.