Google Play: publishing a Flutter app in 7 steps

November 8, 2026 • 18 min • Mickael Saidi

Laptop displaying code, open notebook, pen and smartphone on a white desk.

The myth of "one simple click": what publishing really involves

The process of publishing a Flutter app on the Google Play Store is rarely a simple click. Imagine a developer who has just finished their project: the code compiles, the tests pass, the interface is polished. Then comes the fateful question: "How do I make it available to as many people as possible?" This moment, experienced by thousands of developers every year, reveals a little-known reality: publishing is a project in its own right, with its own requirements and pitfalls.

The official Flutter documentation devotes a detailed section to Android publishing, and services like Codemagic or Shorebird promise to simplify the process. Yet many beginners run into unforeseen obstacles: signature configuration, complete store listing, content classification, testing on pre-launch tracks. Far from the image of a simple APK upload, publishing an app requires careful preparation.

This guide walks you through step by step, from preparing your project to going live, while examining how tools are evolving and what that means for the future of mobile deployment.

Common myths and realities

| Myth | Reality |

|-------|---------|

| All you have to do is compile an APK and upload it | You must generate an Android App Bundle (AAB), configure the signature, and fill out a complete store listing |

| Publishing is free | A Google Play developer account is paid (one-time fee) |

| Once published, it's done | You must maintain updates, respond to reviews, and monitor performance |

| Dynamic updates replace all submissions | These updates only update Dart code; native changes or store metadata require a new submission |

These misconceptions often come from a lack of familiarity with the complete process. The Flutter documentation reminds us: "Build and release an Android app" involves much more than compilation. According to the Android Studio signing guide, you must either generate an upload key and entrust it to Google via Play App Signing, or sign the APK yourself with a private key. This is a crucial point that many beginners discover late.

The 7 critical step roadmap

Here is the recommended path for publishing your first Flutter app, based on current practices and recommendations from official and community sources.

Step 1: Prepare the project for release

Before thinking about the Play Store, your Flutter project must be properly configured. Check the application ID, version number, and version name in the `build.gradle` file. The Flutter documentation stresses the importance of these parameters for managing updates. Add an adaptive app icon and make sure all requested permissions are actually used.

Versioning is often overlooked by beginners. Yet the Play Store uses the `versionCode` (an integer incremented with each update) and the `versionName` (the user-readable string). Poor management of these values can block submission or confuse users. The Codewithandrea guide reminds us that Android project settings must be defined carefully before any publishing attempt.

Step 2: Generate a signing key and configure signing

App signing is mandatory for distributing on Android. Two approaches exist:

Play App Signing (recommended): you generate an upload key, upload it to the Play Console, and Google manages the final signing key. This simplifies recovery if the key is lost.
Manual signing: you sign the APK or AAB with your own private key. Riskier, because losing the key prevents any updates.

The Android Studio guide details these steps and strongly recommends Play App Signing for new developers. The upload key is generated using the `keytool` utility provided with the JDK. It is imperative to keep this key in a safe place and never share it.

Step 3: Create a Google Play developer account

To distribute your app, you must have a developer account. Registration involves a one-time fee and identity verification. Once the account is created, you gain access to the Play Console, the interface for managing your apps.

Identity verification can take a few days, so it is advisable to start early. The developer account also gives access to testing tools, reports, and monetization features.

Step 4: Build the App Bundle

Flutter recommends producing an Android App Bundle (AAB) rather than an APK. The command is simple:

flutter build appbundle

This format allows Google Play to generate optimized APKs for each device, reducing download sizes. The Flutter documentation states that the AAB is now the standard for new applications.

The generated AAB file is located in the `build/app/outputs/bundle/release/` folder. It is important to test this artifact before uploading it, ideally on a physical device or an emulator, to verify behavior under real conditions.

Step 5: Configure the Play Store listing

This is often the most time-consuming step. You must provide:

A complete and attractive description
Screenshots and possibly a video
A high-resolution icon
A content rating
A privacy policy if your application collects data
Contact and support information

Codewithandrea's guide on publishing a Flutter application emphasizes that the quality of the listing directly influences the conversion rate. Every element must be carefully crafted: screenshots must show the key features, the description must be clear and optimized, and the privacy policy is mandatory as soon as the application processes personal data.

Step 6: Test with testing tracks

Before production, use the Play Console testing tracks:

Internal track: for a small group of trusted testers
Closed track: for a larger but controlled audience
Open track: for large-scale public testing

These tracks allow you to validate the application's behavior, gather feedback, and fix bugs before the public launch. They are also a good way to verify over-the-air updates if you use a service like Shorebird.

Step 7: Publish to production and monitor

Once testing is successful, submit the version to production. Google's review can take a few hours to a few days. After publication, monitor the metrics in the console: installs, uninstalls, ratings, crashes. Publishing is not an end, but the beginning of a continuous improvement cycle.

Quick checklist

[ ] Final application ID and incremented version
[ ] Adaptive icon added
[ ] Signing key generated and configured (Play App Signing preferred)
[ ] Google Play developer account created
[ ] AAB built with `flutter build appbundle`
[ ] Complete Play Store listing (description, screenshots, rating, privacy)
[ ] Tests performed on a testing track
[ ] Version submitted to production and monitored

What 2026 changed: code push and automation are reshaping deployment

For a few years now, tools like Shorebird and Codemagic have been transforming the way Flutter applications are deployed. Shorebird, presented in a recent article on Dev.to, allows you to update the Dart code of your application without going through the Play Store review. In practice, you can fix a bug or adjust business logic and deploy the update in a few minutes, without waiting for Google's approval. This approach, called code push, was long the preserve of React Native applications, but it is now becoming accessible to Flutter developers.

Developer coding on a laptop with a smartphone

On the other hand, continuous integration (CI/CD) is becoming widespread. Services like Codemagic allow you to automate compilation, signing, and uploading. By connecting your Git repository to Codemagic, each commit on the main branch can trigger a build and an automatic submission. This reduces manual errors and speeds up the release cycle.

Comparison: classic publishing vs code push vs CI/CD

| Method | Advantages | Disadvantages |

|---------|-----------|---------------|

| Classic publishing (manual) | Total control, no external dependency | Time-consuming, risk of errors |

| Code push (Shorebird) | Fast updates without review, real-time bug fixes | Does not cover native changes or store metadata |

| CI/CD (Codemagic) | Full automation, reduces oversights | Requires initial configuration, dependency on the service |

| Direct FlutterFlow deployment | Extreme simplicity, integrated into the builder | Limited to FlutterFlow projects, less flexibility |

These tools are not mutually exclusive. Many developers combine CI/CD for full builds and code push for quick fixes.

Scenarios for 2027: Optimistic, Pessimistic, Realistic

As 2027 approaches, several trajectories are conceivable for the Flutter publishing ecosystem. Drawing on current trends, here are three scenarios.

Optimistic scenario: publishing becomes almost transparent

In this future, artificial intelligence assists the developer at every step: automatic generation of the store listing, optimization of screenshots, real-time compliance checks. Over-the-air update tools become the norm, enabling continuous updates without friction. A beginner could publish their first application in a few hours, with minimal configuration. Services like FlutterFlow, which already offer direct deployment from the interface, could simplify the process even further.

Pessimistic scenario: complexity increases and discourages beginners

Conversely, the multiplication of privacy rules, security requirements and content policies could weigh down the process. The potential flaws of updates without review could lead the stores to tighten controls. Beginner developers, overwhelmed by paperwork and technical constraints, could give up even before publishing.

Realistic scenario: gradual hybridization

The most likely scenario combines both: automation and over-the-air update tools become more widespread, but human review by the stores remains essential for major changes. Developers adopt a hybrid approach: CI/CD for production builds, over-the-air updates for minor fixes, and sustained attention to compliance at all times. The learning curve remains real, but it is softened by better documentation and ready-to-use templates.

This scenario is supported by current developments: Codemagic and Shorebird are gaining popularity, but neither completely eliminates the need to go through the Play Console for metadata and native changes.

Three perspectives: the beginner, the tool provider, the Play Store reviewer

To better understand the stakes, let us imagine three different points of view.

The beginner developer: "I thought publishing would be the simplest part, but I spent more time on the store listing than on the code. Fortunately, the guides and tools like Codemagic saved me from mistakes."

The deployment tool provider: "Our goal is to reduce friction for developers, but compliance with store rules remains an unavoidable step. We automate what can be automated, but the final responsibility always lies with the developer."

The Play Store reviewer: "The majority of rejections are due to incomplete metadata or privacy issues, not the code itself. A well-prepared store listing considerably reduces delays."

These hypothetical perspectives reflect the realities documented in the sources: the store listing and compliance are key factors of success or failure.