A release is a specific build with known configuration and evidence that its important journeys work. Treating it as “the app runs on my phone” leaves room for incorrect endpoints, missing permissions, broken sign-in redirects, and untested upgrade behavior.

Identify exactly what you are shipping

Record the source revision, app version, build number, SDK version, and environment. Keep signing material and production credentials outside source control. Follow Flutter's platform release guides for Android signing and app bundles, and for iOS signing, archiving, and distribution. Store requirements change, so verify the current platform guidance before each submission.

Check production configuration

Confirm API endpoints, application identifiers, associated domains, notification configuration, and privacy-related descriptions. Debug and release builds can have different behavior. Install the actual release candidate on devices rather than relying only on a debug run.

Keep a short configuration review that compares the candidate with the intended production environment. It is easier to notice an unexpected hostname in a concrete checklist than to remember every setting while packaging the app.

Exercise the journeys that matter

  • Fresh install, first launch, and onboarding.
  • Sign-in, session expiry, sign-out, and account switching.
  • One important read and one important write.
  • Permission denied, then granted later in device settings.
  • Slow network, lost connection, and retry.
  • App backgrounding and resuming during a task.
  • Upgrade from the previous published version with existing local data.

Use realistic but non-production personal data. Include at least one device that represents the lower end of the hardware you support. Inspect both themes and the languages that ship with the release.

Prepare for the first users

Know where crash reports, support messages, and service health information will appear. Decide who can pause a rollout and what evidence would trigger that decision. Record known limitations honestly in release notes when they affect users.

Keep the checklist alive

After a release issue, add the smallest reproducible check that would have caught it. Remove obsolete steps when the product changes. A checklist that can be completed carefully is more useful than a long document people skip under deadline pressure.

Official references: Build and release a Flutter Android app and Build and release a Flutter iOS app.