LaunchLint Academy
The short answer
- FlutterFlow can upload builds to Apple and Google, but it does not assume responsibility for app behavior, third-party packages, privacy, or the store listing.
- Treat generated code, custom actions, API connections, environments, and deployment credentials as a normal production release with reviewable evidence.
- 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. Select the production environment
Package name, API endpoints, Firebase project, and feature flags must belong to the intended public environment.
Do not treat select the production environment 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 select the production environment 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. Create store identity
Bundle ID, Apple app ID, and Play package name must match across FlutterFlow, developer accounts, and listings.
Do not treat create store identity 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 create store identity 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. Protect deployment access
App Store Connect keys, issuer ID, service accounts, and keystores need minimum access, ownership, and rotation.
Do not treat protect deployment access 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 protect deployment access 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. Inventory custom code
Custom actions, widgets, and packages can add native permissions, secrets, or data flows outside the visual model.
Do not treat inventory custom code 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 inventory custom code 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. Permissions and privacy manifest
Camera, location, files, and required-reason APIs need specific configuration rather than an assumed builder default.
Do not treat permissions and privacy manifest 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 permissions and privacy manifest 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. Explain backend data
Firebase, Supabase, APIs, analytics, and uploads must align with the privacy policy and both store declarations.
Do not treat explain backend data 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 explain backend data 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. Test a real store build
Preview and Test Mode do not replace a signed build with production redirects, push, purchases, and rules.
Do not treat test a real store build 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 a real store build 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. Complete the submission
Direct deployment uploads the build; screenshots, review notes, app content, territories, and release remain separate work.
Do not treat complete the submission 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 complete the submission 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
Does FlutterFlow complete the submission?
No. It can upload a build, while store metadata and review work remain your responsibility.
Must custom code be reviewed?
Yes. It can change permissions, secrets, SDKs, and behavior.
Can staging reuse the production package name?
Separate environments normally need deliberately managed identities.
Does LaunchLint execute FlutterFlow code?
No. Typical exports are read statically and untrusted code is never run.