Releasing a FlutterFlow App to the App Store and Google Play

One-click deploy or exported code

FlutterFlow can build and upload your app to App Store Connect and the Play Console directly. That is the fastest route for a first release. Teams usually switch to exported code when they need custom native configuration, several environments, code review or automated releases. On paid plans you can download the Flutter project or push it to a GitHub repository, typically to a dedicated branch that you merge into your main branch.

Two things to know before exporting: build with the same Flutter version that FlutterFlow uses for your project, or you will chase dependency errors that do not exist in FlutterFlow, and keep custom changes in custom code inside FlutterFlow where possible, so the next export does not overwrite them.

Signing for iOS and Android

• iOS: an App ID with the right bundle identifier and capabilities (push, Sign in with Apple, associated domains), an Apple Distribution certificate and an App Store provisioning profile. In CI, an App Store Connect API key lets tools handle certificates and profiles for you.
• Android: an upload keystore that signs the app bundle, and Play App Signing, where Google holds the final signing key. Store the upload keystore and its passwords in a password manager; losing them means a key reset request with Google.
• Versioning: every upload needs a higher build number. Set version and build number deliberately rather than relying on defaults.

Firebase configuration that breaks in production

FlutterFlow can generate the Firebase configuration files for you, but production builds expose problems that test builds hide:

1. Separate projects: use different Firebase projects for development and production, and make sure release builds contain the production files.
2. Google Sign-In on Android: with Play App Signing, the SHA-1 and SHA-256 fingerprints of Google's app signing key must be added to Firebase. Otherwise sign-in works in your local build and fails for users who install from Google Play.
3. Push on iOS: Firebase Cloud Messaging needs an APNs authentication key uploaded in the Firebase console, and the push capability enabled for the App ID.
4. Security rules: test-mode Firestore rules must be replaced before launch.

Store listing and common rejections

Both stores need screenshots, a description, a privacy policy URL, Apple's App Privacy details and Google's Data safety form, a content rating and, on Google, target audience and ads declarations. The rejections we see most often for FlutterFlow apps:

On Google Play, new personal developer accounts must also complete a closed test before production, and Google raises the required target API level every year. Apple's rules are in the App Review Guidelines.

CI with Codemagic or Fastlane

Once code lives in Git, automate releases. Codemagic is built around Flutter and handles code signing through an App Store Connect API key and an uploaded keystore. Fastlane gives more control: match for certificates, build and upload actions for TestFlight and Google Play tracks, run from GitHub Actions or another CI. Either way, keep secrets in the CI's secret store, never in the repository.

How jocapps can help

appsubmitter.io combines AI-assisted checks with experienced App Specialists: CI/CD setup, signing, submission to both stores and hands-on help with rejections, all in your own developer accounts. If your FlutterFlow project needs ongoing development after export, apprat.io combines AI-assisted development with a monthly budget of human developer hours. Read our guide to iOS code signing or book a free 30-minute call via the meeting planner.