Mastering Flutter Release to Google Play: A Step-by-Step Guide for Closed Testing

Let’s be honest: the first time you try to release a Flutter app to Google Play’s closed testing track, it feels like navigating a maze blindfolded. You’ve built a great app, your tests pass, and you’re ready for real-world feedback—only to be met with a console full of jargon, unclear prerequisites, and timing pitfalls that can stall your launch for days.

The core problem isn’t your Flutter skills; it’s that the process involves two distinct systems: your local Flutter build pipeline and the Google Play Console’s release workflow. Getting them out of sync is the most common cause of frustration. This guide cuts through the confusion with a clear, step-by-step path to a successful closed testing release.

The Golden Rule: Build First, Then Configure

The biggest mistake is diving into the Play Console and setting up your test track before you have a signed release build (APK or AAB) ready to upload. This leads to creating placeholder releases that expire or cause confusion. Follow this order instead.

Step 1: Prepare Your Flutter Build Locally

Before you even open the Play Console, ensure your app is ready for production.

1. Configure App Signing: You must use app signing by Google Play for closed testing. Generate an upload key and configure your app.

   • Create a keystore (if you don’t have one):

     keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

   • Reference it in android/app/build.gradle:

     android {
         ...
         signingConfigs {
             release {
                 storeFile file("../../upload-keystore.jks")
                 storePassword "your-store-password"
                 keyPassword "your-key-password"
                 keyAlias "upload"
             }
         }
         buildTypes {
             release {
                 signingConfig signingConfigs.release
                 ...
             }
         }
     }

2. Build Your App Bundle: Always use the Android App Bundle (.aab) format.

   flutter build appbundle

   Your build will be at build/app/outputs/bundle/release/app-release.aab.

Step 2: The Play Console Setup Dance

Now, with your .aab file in hand, log into the Google Play Console.

1. Create Your App & Fill Store Listing: If it’s your first release, complete all required store listing details (description, screenshots, privacy policy, etc.). This is a blocker.
2. Navigate to “Testing” > “Closed testing”: Click Create track.
3. Upload Your Build: Go to the “Releases” tab in your new track. Click Create new release and upload your app-release.aab. The console will validate it. This is where many get stuck—if your app signing isn’t configured correctly, you’ll see errors here.
4. Add Testers (Crucial Step): Go to the “Testers” tab. You have two key options:
   • Email Lists: Manually add tester emails. They must have a Google account.
   • Google Groups: More scalable. Create a Google Group, add members, and use its email address here.
   • Copy the Opt-in Link: This is the URL you’ll share with testers.

Critical Timing Note: Testers added before you roll out a release will receive an invitation email immediately. If you add testers after rolling out, they won’t get an automatic email—you must manually send them the opt-in link.

Step 3: Release to Your Testers

Back in the “Releases” tab for your closed track, review the release and click Start rollout. The status will change to “Pending publication” and then, usually within an hour, to “Available to testers.”

Your testers must now:

1. Accept the invitation via the email sent to them, or
2. Use the opt-in link you provided. They must be logged into the Google Play Store on their Android device with the same email you added as a tester.

Common Pitfalls & Pro Tips

• “I added testers but they can’t see the app.” This is the #1 issue. Ensure they are using the correct Google account on their device’s Play Store. Have them visit the opt-in link directly from the device.
• Version Code Conflicts: You cannot upload the same version code twice. Always increment the version in pubspec.yaml before building a new release.

  version: 1.0.1+2 # `1.0.1` is the version name, `+2` is the version code.

• Promoting a Build: When testing is done and you want to move a build to production, you don’t re-upload. In the Play Console, go to your closed testing track’s release, click Promote release, and select “Production”. This re-uses the exact same binary, which is safe and efficient.
• Internal Testing Track: For your most immediate team (developers, PMs), use the Internal testing track. It has a faster rollout time (minutes) and a higher tester limit. Use Closed testing for a broader external group.

Your Actionable Checklist

1. Increment version code in pubspec.yaml.
2. Verify app signing configuration in build.gradle.
3. Run flutter build appbundle.
4. In Play Console, ensure store listing is complete.
5. In Closed Testing track, create a new release and upload the .aab.
6. Add tester emails/list in the “Testers” tab.
7. Copy the opt-in link.
8. In “Releases,” review and start the rollout.
9. Communicate clearly with testers: send the opt-in link and instructions.
10. Verify the build becomes “Available to testers.”
11. After feedback, iterate: bump version, build anew, and create a new release in the same closed track.

By treating the process as two connected but separate phases—local build preparation and console deployment—you remove the mystery. Keep this checklist handy, and your next Flutter app will move from closed testing to production with confidence.