LaunchLint Academy
The short answer
- A successful Flutter build is not yet a submission-ready app. Bundle ID, application ID, versions, signing, native permissions, privacy declarations, and store metadata must describe the same production state.
- Freeze one release candidate, test the distributed artifact on real devices, and retain supporting detail for every material store answer.
- Do not postpone this checklist until submission day. Make it a release gate, link every item to the responsible commit or store field, and repeat affected checks after changes to dependencies, permissions, production configuration, or metadata. Supporting records must not contain secrets or personal test data. Engineering, product, and the person who controls the store console should approve the same artifact. This turns a one-off review into a reproducible process and makes it possible to explain exactly what was checked after a rejection or during the next update.
1. Freeze the release candidate
Record the commit, Flutter version, flavor, production environment, and target platforms before creating native archives.
Do not treat freeze the release candidate as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for freeze the release candidate recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
2. Identity and versioning
Bundle identifier, application ID, marketing version, and technical build numbers must remain aligned through upload.
Do not treat identity and versioning as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for identity and versioning recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
3. Signing and ownership
Apple certificates, provisioning, the Android upload key, and Play App Signing need named owners and recovery procedures.
Do not treat signing and ownership as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for signing and ownership recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
4. Native permissions
Info.plist, AndroidManifest, and plugin configuration should contain only required access with specific user-facing explanations.
Do not treat native permissions as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for native permissions recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
5. Plugins and privacy
Dart packages can introduce native SDKs and data flows that belong in App Privacy, Data Safety, and the privacy policy.
Do not treat plugins and privacy as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for plugins and privacy recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
6. Test the release artifact
Debug behavior does not prove that authentication, deep links, push, purchases, and failures work in the signed build.
Do not treat test the release artifact as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for test the release artifact recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
7. Prepare store metadata
Screenshots, descriptions, support, review access, and purchase details must truthfully explain the frozen release.
Do not treat prepare store metadata as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for prepare store metadata recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
8. Upload and controlled rollout
Processing, TestFlight or a test track, review warnings, and monitoring all precede the final production decision.
Do not treat upload and controlled rollout as an isolated checkbox. Tie the claim to the exact release build, a named owner, and reviewable supporting detail. Repeat the path on a clean device and record any mismatch before the store submission continues.
Evidence for release acceptance
- Production value for upload and controlled rollout recorded
- Affected file or store setting linked
- Expected and observed behavior compared
- iOS and Android differences reviewed deliberately
- Every uncertainty has an owner and due date
- Release stops when a blocking contradiction remains
Frequently asked questions
Is flutter build ipa or appbundle enough?
No. It creates an artifact but does not complete metadata, review access, or privacy declarations.
Can I change the bundle ID later?
Treat bundle and application IDs as permanent once the first store artifact has been uploaded.
Do Flutter plugins require individual review?
Yes. Plugins can add permissions, native SDKs, and data processing.
Does LaunchLint build my Flutter app?
No. LaunchLint statically reads supported project files and never executes untrusted code.