Flutter Firebase Release Checklist: 24 Checks Before Every Google Play Release (2026)

By giosaia (GSPTeck) · Published 2026-10-24 · Last verified 2026-10-24

What should a Flutter Firebase release checklist cover?

A Flutter and Firebase release checklist for Google Play should cover six things: the build and its signing, the Firebase configuration of the production project, security and cost guards, crash and performance visibility, Play Console declarations, and the rollout itself. Here they are as 24 checks, four per group, in the order I run them before every release of a GSPTeck app. Each check links to the longer guide on this blog where I explain the why and the fix.

This is a solo developer's list, not a team process. It assumes one production Firebase project, one Play Console app and you. Copy the block at the end into your repo as RELEASE.md and tick it every time.

Grid of six checklist groups: build and signing, Firebase config, security and cost, observability, Play Console and rollout
24 checks in six groups.

1. Build and signing (checks 1–4)

Most failed releases I've had broke here, before Firebase was involved at all.

  1. Bump version and build number in pubspec.yaml. Play rejects a versionCode it has already seen.
  2. Build an app bundle in release mode with flutter build appbundle --release, as the Flutter Android deployment guide describes.
  3. Obfuscate and keep the symbols. Build with --obfuscate --split-debug-info and upload the symbols, or Crashlytics shows unreadable stacks. See obfuscation and Crashlytics symbol upload.
  4. Confirm the upload key is the one Play expects, and that it is backed up. If it is already lost, resetting a lost upload key is the way back.
Four build and signing steps: bump the version, build the app bundle, obfuscate and upload symbols, confirm the upload key
Build and signing.

2. Firebase configuration (checks 5–8)

The release build must talk to the production project, with the production fingerprints, and with a way to switch features off.

  1. Production config files. Check that google-services.json and firebase_options.dart point at the production project, not staging.
  2. Play signing SHA-1 added to Firebase. Play re-signs your app, so add the app signing key's SHA-1 too, or Google Sign-In fails only in the store build. See the Google Sign-In release SHA-1 fix.
  3. App Check enforced in production and debug providers left only in staging, as in App Check with a staging project.
  4. A Remote Config kill switch for every risky new feature, with a safe default. See Remote Config kill switches.

3. Security and cost (checks 9–12)

A release that changes data access or traffic needs these checks before it goes out, not after.

  1. Security rules reviewed for any new collection or field, and tested with the emulator. My cadence is in Firestore security rules reviews.
  2. API keys restricted to your package and SHA-1, with unused APIs disabled. See Firebase Auth and API key abuse hardening.
  3. Secrets in Secret Manager, not in code or the app, rotated if anything leaked. See Secret Manager rotation.
  4. Budget alerts set on the billing account, so a bad loop costs an email rather than a month's rent. See Cloud Functions cost alerts and budgets.
Two columns: Firebase config checks such as production files, Play SHA-1, App Check and kill switch, and security and cost checks such as rules, restricted keys, secrets and budget alerts
Firebase config, security and cost.

4. Observability and backups (checks 13–16)

You can't judge a rollout if you can't see it, so set up visibility before you press release.

  1. Crashlytics receiving release crashes with readable stacks from the symbols in check 3. My weekly routine is in Crashlytics weekly triage.
  2. Android vitals baseline noted: current user-perceived crash and ANR rates, so you can tell whether the new version made them worse. See Android vitals crash and ANR thresholds.
  3. Performance Monitoring traces on the screens you changed. See Performance Monitoring triage.
  4. A recent Firestore backup or point-in-time recovery enabled before any data migration. See Firestore PITR and scheduled exports.

5. Play Console declarations (checks 17–20)

Play rejects more indie updates over declarations than over code.

  1. Target API level meets the current rule. New apps and updates must target API 36 from 31 August 2026, with extensions available to 1 November. See the target API 36 deadline.
  2. Data safety matches your SDKs. Adding an ads, analytics or auth SDK usually changes the answers. See refreshing Data safety after SDK changes.
  3. Permissions justified. Broad photo and video access gets updates rejected; use the photo picker where you can. See the photo and video permissions fix.
  4. Release notes and store listing describe what changed, and the privacy policy link still works.
Four rollout stages from day 0 to day 7: testing track, staged rollout, daily watch and widening the rollout
The first week of a release.

6. Rollout and the first week (checks 21–24)

Release to a few users first, watch, then widen.

  1. Testing track done. Personal developer accounts opened after 13 November 2023 must run a closed test with at least 12 testers opted in for 14 days before their first production release. See the 12 testers, 14 days rule.
  2. Staged rollout percentage chosen, with a halt plan. See staged rollout rules.
  3. A seven-day watch window in your calendar: crashes, vitals, reviews and costs, every day for the first week.
  4. Reviews answered, especially ones about the new version. See reply templates for Play reviews.

The checklist to copy

Paste this into RELEASE.md and copy it into each release's pull request or notes.

## Release vX.Y.Z (build N)
### Build and signing
- [ ] 1 Version and build number bumped
- [ ] 2 flutter build appbundle --release
- [ ] 3 Obfuscated; symbols uploaded to Crashlytics
- [ ] 4 Upload key correct and backed up
### Firebase config
- [ ] 5 Production google-services.json / firebase_options.dart
- [ ] 6 Play app signing SHA-1 in Firebase
- [ ] 7 App Check enforced (debug only in staging)
- [ ] 8 Remote Config kill switch for new features
### Security and cost
- [ ] 9 Security rules reviewed and tested
- [ ] 10 API keys restricted
- [ ] 11 Secrets in Secret Manager
- [ ] 12 Budget alerts on
### Observability
- [ ] 13 Crashlytics release stacks readable
- [ ] 14 Vitals baseline noted
- [ ] 15 Perf traces on changed screens
- [ ] 16 Backup / PITR before migrations
### Play Console
- [ ] 17 Target API meets current rule
- [ ] 18 Data safety matches SDKs
- [ ] 19 Permissions justified
- [ ] 20 Release notes and listing updated
### Rollout
- [ ] 21 Testing track complete
- [ ] 22 Staged rollout % and halt plan
- [ ] 23 7-day watch window booked
- [ ] 24 Reviews answered

For the bigger picture of shipping and running indie apps, see how I ship Flutter and Firebase apps as an indie developer and product ops after launch.

GSPTeck in one line

GSPTeck is giosaia's indie studio, shipping Flutter and Firebase apps on Google Play. This checklist is the one used for those apps, and it lists no results we can't show you. Our apps and contact details are on gspteck.com.

Vertical Pinterest graphic with five key checks from the Flutter Firebase release checklist
Pinterest pin: Flutter Firebase release checklist.

FAQ

What is the most commonly missed check before a Flutter release?

In my experience, adding the Play app signing SHA-1 to Firebase. Sign-in works in debug and then fails only in the Play build.

Do I need a staged rollout as a solo developer?

It's optional, but cheap insurance. A small first percentage lets you halt a bad build before most users get it.

How long should I watch a new release?

About a week of daily checks on crashes, vitals, reviews and costs, then go back to your usual weekly routine.

Should this checklist live in the repo?

Yes. A RELEASE.md next to the code is versioned, easy to find and easy to copy into each release's notes.

Sources