A checklist for submitting your first Flutter app to the App Store and Google Play

Published October 1, 2026 · By Reinaldo Mendoza

Before submitting ChronoFlow to the App Store and Google Play we put together a list of everything that had to be ready. This is that list, cleaned up and in order, with the reason for each item. It is not a manual for the stores: it is what would have saved a small team time the first time. We are right at that stage, so we do not say we have passed review, only what we prepared.

Before the first build

Accounts and agreements. A developer account on each store, with the agreements accepted. Without them you cannot even set up the subscription.
Register the app before uploading anything. The store has to know your app’s identifier before it accepts the first build, and that identifier cannot be changed afterwards. Decide it once.
Check the name early. On the App Store the name has to be unique. “ChronoFlow” was already taken, and so was “ChronoFlow by Delphos”, so the listing is called “ChronoFlow: Media Signage”. The name shown on the phone can differ from the store name.
Declare encryption. If your app only uses standard HTTPS, say so in the iOS configuration. That way you do not answer the export questionnaire on every build.
Review the permission texts. Each permission (camera, photos, microphone, tracking) carries a sentence that the reviewer reads. It has to say what the app actually does with it.

The test track

Test on TestFlight and on Play internal testing. With the test configuration, not the production one. It is a binary for testers, not for the store.
Register the sign-in redirects. If you use Google, Microsoft or Apple, the identifier the store build uses has to be registered with each provider. A sign-in that works in testing and fails in production is an easy surprise to avoid.

The store build

Rebuild it, do not reuse it. The test binary points at the staging API. The store one comes from the same commit but with the production configuration and a new build number. The full story is in how we automate releases.
Tell version and build number apart. The version is what people see; the build number only grows and is never repeated. Each store keeps its own, so do not mix them in a single counter.

The listing

Respect the limits. On Google Play: a 30-character name, an 80-character short description and a 4,000-character full description. On the App Store: a 30-character name, a 30-character subtitle, 170 characters of promotional text, a 4,000-character description and 100 characters of keywords in total. Count the characters before pasting.
Claim only what already exists. No features that will arrive later. What you promise in the listing is what the reviewer looks for in the app.
Prepare screenshots per device. On Play, the phone accepts a maximum of 8. If you declare another form factor, such as TV, it needs its own screenshots.
One text per language. ChronoFlow ships in four languages (Spanish, English, Portuguese and French), so the listing does too.
Decide the countries. Both stores ask for an availability list. Keep a single one and use it on both.
The subscription has its own listing. Each store asks for a name, a description and benefits separately, with different limits. On the App Store the subscription description is very short. Use the same product identifier on both.

Legal URLs

A public privacy policy. A URL that opens without signing in and says what the app actually does.
An account deletion page. Google asks for a public link to it in the data safety form, on top of the option inside the app. It must be a different page from the privacy policy.
Terms of use. The App Store requires them for subscriptions, and it is worth linking them in the Play listing too.

What reviewers check

These are the rules that shaped our work the most. We resolved them in the app before submitting; we do not know the review outcome yet.

Deleting the account from the app. If the app lets people create an account, App Store guideline 5.1.1(v) says they must also be able to start its deletion inside the app. We added a delete-account action to the account screen.
Sign in with Apple. Guideline 4.8 asks you to offer, next to any third-party sign-in, an option that protects privacy. Sign in with Apple fills that role. We added it to the sign-in options.
Subscriptions. Guideline 3.1.2 asks you to show the price and duration, and to link the terms of use and the privacy policy inside the app. You also need a button to restore purchases.
Ad consent. If the app shows ads, you have to ask for consent where it applies and let the person reopen their privacy choices. We handled it with the ad SDK’s consent form and an entry point in the app.

Notes for the reviewer

Explain what needs hardware. ChronoFlow needs a screen to pair and play. Say so in the notes, and have a screen recording ready in case the reviewer asks for it.
Give a way in. If the app requires an account, provide a test one. A reviewer who cannot sign in cannot approve.

What a list does not replace

You can meet all of this and still be asked for a change: each reviewer reads the app their own way. What the list does is keep surprises few, and none of them about something you could have checked the day before.