A FlutterFlow export in the repo, Ship to the stores, the keys, and the builds.
A phone app made in FlutterFlow lives in the repo beside the site, in the app/ folder (Settings › Code can name another), kept off the website. It ships to the App Store and Google Play from Settings › Deployment › Mobile app.
Two doors: the FlutterFlow start on the new-project page, or Ship to the stores in Settings › Deployment › Mobile app. A new export replaces the old one in the repo: files the new export no longer has are deleted, the rest overwritten. So an edit made in the repo is lost on the next export unless it is also made in FlutterFlow; Flexi says so before he changes the app's files.
Only the owner ships. Codemagic builds the app from codemagic.yaml at the repo's top and sends it to TestFlight and Google Play's internal testing, twenty to ninety minutes a build. Before each ship FlexOS commits the next build number, the real app icon, Apple's encryption answer and its own codemagic.yaml; edit none of those by hand.
A brand-new app cannot reach the stores until you have made it in App Store Connect (Apps › New App, with the app's bundle ID) and made Google Play's very first upload by hand in Play Console. Until then that store's build fails, and Where it stands says so.
Fix keys asks for the store keys that are missing, one per screen, each checked with Apple or Google before it goes in the Vault. A store's row asks for that store's. The Android keystore and the iOS signing certificate are guarded: replacing one asks first and keeps the old one with its passwords; the Vault page never replaces or removes them. Only the owner takes the signing keys out of the Vault; a team member sees them listed with no part of their values.
Apple lets a team hold only a few distribution certificates. If Apple refuses a new one, revoke an unused certificate at developer.apple.com › Certificates, or paste the private key of the one you already have on the Apple step.
The Mobile app section shows the last build and what each store holds. Redeploy ships the ready stores again.
Anyone on the project can change the app's code, and the build runs that code with the signing keys to hand. Look at what changed in
android/,ios/andpubspec.yamlbefore you ship.