You've built your Flutter app. It works on your device. Your team has tested it. Now comes the step that trips up more first-time developers and founders than any other: actually getting it live on the App Store and Google Play.

App store submission is not complicated, but it is detailed. There are prerequisites to set up, build configurations to get right, metadata to prepare, and review guidelines to comply with and if you miss any of them, you face delays, rejections, and the frustration of going back and forth with Apple and Google before your app ever reaches a user.

This guide walks you through the entire process for both stores, step by step, so you know exactly what to do and in what order.

Before You Start: Prerequisites for Both Stores

Get these in place before you touch a build or a submission form. Trying to sort them mid-submission wastes time and introduces errors.

Apple Developer Account Sign up at developer.apple.com. The individual or organization membership costs $99 per year. Organization accounts require a D-U-N-S number (a free business identifier from Dun & Bradstreet) which can take several days to process. Applying early waiting on account activation is one of the most common avoidable delays in iOS publishing.

Google Play Console Account Sign up at play.google.com/console. One-time registration fee of $25. Activities within a few hours. Significantly faster and cheaper than Apple's program.

Privacy Policy Both stores require a privacy policy URL before submission. This is non-negotiable. If your app collects any user data, even just an email address for login, your privacy policy must accurately describe what data you collect, how you use it, and how users can request deletion. Use a generator like Termly, iubenda, or App Privacy Policy Generator if you don't have legal support. Host it at a permanent public URL, a simple webpage or even a Google Docs link set to public works.

App Icons Prepare your app icon in the required sizes before building. Flutter's flutter_launcher_icons package automates generating all required sizes from a single source image. Your source icon should be 1024x1024px, PNG format, no transparency (Apple rejects transparent icons), no rounded corners (the stores apply rounding themselves).

Screenshots Prepare screenshots for all required device sizes before you open App Store Connect or Play Console. For Apple: you need screenshots for the 6.9-inch display (iPhone 16 Pro Max size), 6.5-inch display, and 12.9-inch iPad Pro if your app supports iPad. For Google: you need at minimum two phone screenshots. Use real device screenshots or a mockup tool like AppMockUp, Rottenwood, or Figma device frames.

Part 1: Publishing to Google Play

Google Play is the more straightforward of the two stores and the faster to approve, so it's a good place to start if this is your first submission.

Step 1 - Create your app in Play Console

Log into play.google.com/console and click "Create app." Enter your app name, select your default language, confirm whether it's an app or a game, confirm whether it's free or paid, and accept the developer program policies. This creates your app's shell in the console. Nothing is live yet.

Step 2 - Complete the store listing

Navigate to "Store presence" → "Main store listing." Fill in:

• Short description (80 characters maximum this appears in search results)

• Full description (4,000 characters maximum write this with your primary keyword in the first two sentences)

• Screenshots (minimum 2, maximum 8 for phone; also upload tablet screenshots if your app supports tablets)

• Feature graphic (1024x500px banner displayed at the top of your store listing)

• App icon (512x512px)

• App category and tags

Step 3 - Complete the content rating

Navigate to "Policy" → "App content" → "Content rating." Complete the IARC questionnaire about your app's content. Answering honestly misrepresenting your content rating is a policy violation. The questionnaire takes about five minutes and automatically assigns your rating.

Step 4 - Complete the data safety section

This is the most time-consuming part of the Play Console setup. Navigate to "Policy" → "App content" → "Data safety." Declare every type of data your app collects and shares account info, location, device identifiers, financial info, and so on. Be thorough and accurate. Google cross-checks declared data practices against app behavior and can reject or remove apps with inaccurate declarations.

Step 5 - Set up your app's target audience and content

If your app targets children or families, select the appropriate audience settings. This triggers additional policy requirements. If your app is for a general audience (not specifically targeting children), select "Everyone."

Step 6 - Build your release APK or App Bundle

In your Flutter project, run:

flutter build appbundle --release

This produces an .aab (Android App Bundle) file in build/app/outputs/bundle/release/. Google strongly prefers App Bundles over APKs; the Play Store uses the bundle to generate optimized APKs for each device configuration, resulting in smaller download sizes.

Before building for release, ensure your app's version name and version code in pubspec.yaml are set correctly. Version code must be an integer that increments with every submission you cannot reuse a version code.

You also need a signed build. Generate a keystore file using keytool, configure your key.properties file in your Flutter project's android folder, and reference it in your build.gradle. The Flutter documentation covers this process in detail. Store your keystore file securely, losing it means you can never update your app on Google Play.

Step 7 - Create a release and upload

Navigate to "Release" → "Production" → "Create new release." Upload your .aab file. Add release notes (what's new in this version required even for your first release; write something like "Initial release"). Review the release summary and click "Start rollout to production."

Step 8 - Wait for review

Google's review process for new apps currently takes anywhere from a few hours to three days. You'll receive an email when the review is complete. If rejected, the rejection reason will be listed in Play Console with a link to the relevant policy.

Part 2: Publishing to the Apple App Store

Apple's process is more involved than Google's, and Apple's review team is more stringent. Plan for at least 24 to 48 hours for review, and have your privacy policy, permissions justifications, and demo account ready before submitting.

Step 1 - Create your app in App Store Connect

Log into appstoreconnect.apple.com. Navigate to "My Apps" and click the "+" button to create a new app. Select iOS as the platform, enter your app name (this must exactly match the name in your Xcode project), select your primary language, select or create a Bundle ID that matches your Flutter project's bundle identifier, and enter your SKU (a unique internal identifier use your bundle ID or a variation of it).

Step 2 - Complete your app information

Fill in:

• App name (30 character limit choose carefully, this is what appears on the App Store)

• Subtitle (30 character limit a short, keyword-rich description shown below your app name in search)

• Category (primary and optional secondary)

• Privacy policy URL (mandatory)

• Age rating (complete the questionnaire)

Step 3 - Prepare your version information

This is the content users see on your App Store listing:

• Description (4,000 characters lead with your primary keyword, write for users not bots, but include keywords naturally)

• Keywords field (100 characters total, comma-separated these are your ASO levers; do not repeat words already in your title or subtitle)

• Support URL

• Marketing URL (optional but recommended)

• Screenshots for all required device sizes

• App preview video (optional but increases conversion 15 to 30 seconds, landscape or portrait matching your app orientation)

• What's new in this version (for first submission, write "Initial release" or a brief description of the app)

Step 4 - Configure pricing and availability

Set your price tier (free or a paid tier from Apple's price grid). Select the territories where your app will be available. If launching globally, select all territories. If launching in specific markets first, select accordingly.

Step 5 - Complete App Privacy details

Navigate to "App Privacy" in your app's page in App Store Connect. Declare your data collection practices similar to Google's data safety section but Apple's own format. Categories include data used to track users, data linked to identity, and data not linked to identity. To be accurate, Apple has rejected apps for privacy label misrepresentation.

Step 6 - Build your iOS release in Xcode

In your Flutter project, run:

flutter build ipa --release

This builds your iOS app and produces an .ipa file. Alternatively, open the iOS folder of your Flutter project in Xcode directly (open ios/Runner.xcworkspace), select "Any iOS Device" as the build target, and go to Product → Archive.

Before building, ensure your Bundle Identifier matches what you registered in App Store Connect, your version number and build number are set correctly in Xcode (or in pubspec.yaml if you're using flutter build ipa), and your signing certificate and provisioning profile are correctly configured in Xcode under Signing & Capabilities.

Step 7 - Upload your build via Xcode or Transporter

From Xcode's Organizer window (Window → Organizer), select your archive and click "Distribute App." Choose "App Store Connect" as the distribution method, follow the signing prompts, and click "Upload." Alternatively, use Apple's Transporter app to upload an .ipa file directly.

Once uploaded, the build appears in App Store Connect under your app's TestFlight section within 15 to 30 minutes (sometimes longer). You must then select the build in your version's submission form before submitting for review.

Step 8 - Complete the submission checklist and submit

Before you can click "Submit for Review," App Store Connect requires all of the following to be complete: version information filled in, screenshots uploaded for all required device sizes, build selected, app privacy details completed, age rating completed, pricing and availability set, and export compliance answered (whether your app uses encryption most apps using HTTPS answer yes to standard encryption).

Once all green checkmarks appear, click "Add for Review" then "Submit for Review."

Step 9 - Respond to review

Apple's review team may approve your app, request additional information, or reject it with a specific guideline cited.

Common first-submission rejection reasons include: missing demo account credentials for apps requiring login (always include a test account in your review notes), permissions not justified (if you request camera, location, or contacts access, the reason must be clear and the feature must be functional in the submitted build), placeholder content (remove all lorem ipsum, test data, and coming soon placeholders before submission), and guideline 4.2 minimum functionality (your app must do something meaningful; Apple rejects thin apps or apps that are essentially just websites).

If rejected, read the rejection reason carefully, make the specific fix requested, and resubmit. Do not argue with reviewers via the Resolution Center unless you have a genuine factual case it rarely helps and slows the process.

After Both Stores Approve: The First 48 Hours

Once both apps are live, move through this checklist immediately:

☐ Download your own app from both stores on a real device and complete a full user flow end to end the production build behaves differently from your development build in ways that sometimes only appear after store processing.

☐ Confirm push notifications fire correctly in production.

☐ Confirm payment flows work in production mode (not sandbox).

☐ Share your store links publicly update your website, social profiles, and any pre-launch landing page.

☐ Set up monitoring in Firebase Crashlytics so you see any crashes that appear in the production environment within the first hours of real user traffic.

☐ Watch your first reviews. Respond to every one in the first week it signals to both stores and to prospective users that the app is actively supported.

One Final Note on Timing

Plan your submission dates carefully. Apple's review takes 24 to 72 hours on average but can be longer around major holidays and around the time of major iOS releases in September and October each year. Google's review is faster but new developer accounts occasionally face extended review periods for their first submission.

If you have a specific launch date, a product launch event, a marketing campaign, a client delivery deadline submit at least five to seven days early to give yourself a buffer for a revision request without missing your window.

The submission process feels daunting the first time. By the second or third app, it becomes routine. Work through it methodically, keep this guide open, and you'll have both stores approved and your app in users' hands before you know it.