{"id":28783,"date":"2026-07-14T10:21:06","date_gmt":"2026-07-14T10:21:06","guid":{"rendered":"https:\/\/www.tftus.com\/blog\/?p=28783"},"modified":"2026-07-15T08:06:43","modified_gmt":"2026-07-15T08:06:43","slug":"flutter-app-publishing-requirements","status":"publish","type":"post","link":"https:\/\/www.tftus.com\/blog\/flutter-app-publishing-requirements","title":{"rendered":"Flutter App Publishing Requirements: Complete Guide for App Store & Google Play"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n

Most Flutter developers hit the same wall: they finish the app, head straight to the store dashboard, and then discover a chain of compliance gates they didn’t know existed. The right sequence is not built \u2192 submit. It’s comply \u2192 build \u2192 submit. Get that order wrong, and you’re looking at rejections, a delayed launch, or \u2014 worst case \u2014 a banned developer account.<\/p>\n\n

This guide covers every Flutter app publishing requirement you need to clear before pressing “Submit for Review” on both the Google Play Store and the Apple App Store, including the Flutter-specific gotchas that generic app publishing guides don’t mention.<\/p>\n\n

Last updated: May 2026. Policy references:Google Play target API level requirements,Apple Privacy Manifest documentation,Google Play Console developer account requirements.<\/em><\/p>\n\n

What Makes Flutter App Publishing Different from Native Apps<\/strong><\/h2>\n\n

Flutter produces native apps from a single Dart codebase, but once you’re at the publishing stage, the rules come entirely from Google and Apple \u2014 not Flutter. That said, Flutter introduces several layers of complexity that native Android or iOS developers won’t be familiar with.<\/p>\n\n

Flutter-Specific Publishing Gotchas<\/strong><\/h3>\n\n

The three areas where Flutter developers get tripped up most often are:<\/p>\n\n

Merged manifest permissions.<\/strong> When you add packages from pub.dev, Flutter silently injects its AndroidManifest.xml permissions into your app’s merged manifest. You may declare no sensitive permissions in your own code, yet the final merged output includes location, camera, or Bluetooth access from a dependency. If your Google Play Data Safety form doesn’t account for those, expect a rejection \u2014 or worse, an account action. Google banned over 80,000 developer accounts in 2025 for policy violations, including undeclared permissions, according to Google’s annual Bad Apps report.<\/p>\n\n

Apple’s Privacy Manifest requirement.<\/strong> Since February 12, 2025, Apple has hard-blocked any upload that doesn’t include a valid PrivacyInfo.xcprivacy file (Apple developer announcement). This is not just about your own code. The Flutter framework itself appears on Apple’s required-SDK list, meaning even a basic Flutter app needs a Privacy Manifest. Every plugin you use that also appears on the list must be covered.<\/p>\n\n

pubspec.yaml as the version source of truth.<\/strong> Flutter reads version: 1.0.0+1 from pubspec.yaml and maps it to versionName + versionCode on Android and CFBundleShortVersionString + CFBundleVersion on iOS. You generally do not need to touch the Gradle file or Xcode settings for versioning. Version and build numbers must be properly incremented for every release.<\/p>\n\n

Timeline and Cost Reality<\/strong><\/h3>\n\n

Before diving into the technical steps, here is every fee you’ll pay, in USD, in one place \u2014 something most publishing guides skip entirely.<\/p>\n\n

\n\n\n\n\n\n\n\n\n
Fee<\/strong><\/td>\nPlatform<\/strong><\/td>\nAmount<\/strong><\/td>\nNotes<\/strong><\/td>\n<\/tr>\n
Developer account<\/td>\nGoogle Play<\/td>\n$25 (one-time)<\/td>\nUnlocks Google Play Console<\/td>\n<\/tr>\n
Developer program<\/td>\nApple<\/td>\n$99\/year<\/td>\nApp delisted if subscription lapses<\/td>\n<\/tr>\n
In-app purchase commission<\/td>\nApple<\/td>\n30% (standard)<\/td>\n15% under Small Business Program (<$1M\/yr revenue)<\/td>\n<\/tr>\n
CI\/CD (optional)<\/td>\nBoth<\/td>\n$0\u2013$49\/month<\/td>\nCodemagic free tier available<\/td>\n<\/tr>\n
Test devices<\/td>\nBoth<\/td>\nVariable<\/td>\nPhysical device testing is strongly recommended<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n\n

One timeline note that catches first-time publishers off guard: if you register a personal<\/strong> Google Play Console developer account, you are subject to a closed testing gate that requires at least 12 opted-in testers for 14 continuous days before you can apply for production access. That adds roughly three to four weeks to your launch window. Organizations and businesses that register under a company account are exempt from this gate. Decide which account type you’re opening before you pay the $25 fee.<\/p>\n\n

Personal vs. company account \u2014 the decision framework:<\/strong><\/p>\n\n

\n\n\n\n\n\n\n\n\n
Factor<\/strong><\/td>\nPersonal account<\/strong><\/td>\nCompany \/ organization account<\/strong><\/td>\n<\/tr>\n
Tester gate<\/td>\nRequired: 12 testers \u00d7 14 days<\/td>\nExempt \u2014 can go straight to production<\/td>\n<\/tr>\n
Launch timeline<\/td>\nAdd 3\u20134 weeks<\/td>\nNo delay<\/td>\n<\/tr>\n
D-U-N-S number<\/td>\nNot required<\/td>\nRequired for Apple; not required for Google Play<\/td>\n<\/tr>\n
Developer name on listing<\/td>\nYour real name<\/td>\nCompany name<\/td>\n<\/tr>\n
Best for<\/td>\nSide projects, solo developers<\/td>\nAgencies, companies, client apps<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n\n

If you are an agency shipping a client’s Flutter app, or if you have an active business entity, register the Google Play account under the organization from day one. There is no migration path \u2014 a personal account cannot be converted to an organizational account after creation.<\/p>\n\n

Pre-Publishing Checklist for Your Flutter Project<\/strong><\/h2>\n\n

Before you touch either store dashboard, these items need to be in order at the Flutter project level.<\/p>\n\n

Set Your Package Name and Version \u2014 Permanently<\/strong><\/h3>\n\n

Your application ID (com.company.appname on Android, matching bundle identifier on iOS) is permanent after the first upload. Changing it means submitting as a brand-new app, losing all ratings, reviews, and install history. Decide your own unique application identifier before you publish anything, even to internal testing.<\/p>\n\n

In pubspec.yaml, set your version string:<\/p>\n\n

\n

version: 1.0.0+1<\/p>\n<\/blockquote>\n\n

The number before the + is the version name shown to users. The number after is the build number used internally by the stores. Set your version number carefully \u2014 once a version has been uploaded, you cannot upload the same version number again.<\/p>\n\n

App Icon Requirements<\/strong><\/h3>\n\n

Prepare your launcher icon at the correct dimensions for both platforms. The easiest path is the flutter_launcher_icons package, which generates all required sizes from a single source image. If you prefer manual control, follow the Material Design guidelines for Android and Apple’s Human Interface Guidelines for iOS.<\/p>\n\n

Critical iOS-specific rule: the 1024\u00d71024 App Store app icon must be fully opaque. No alpha channel, no transparency. This is one of the most common causes of iOS upload failures. Verify every size in the Xcode Asset Catalog before submitting.<\/p>\n\n

For Google Play, you’ll need:<\/p>\n\n

    \n
  • App icon: 512\u00d7512 pixels<\/li>\n\n
  • Feature graphic: 1024\u00d7500 pixels<\/li>\n<\/ul>\n\n

    Privacy Policy URL<\/strong><\/h3>\n\n

    Both the Google Play Store and the Apple App Store require a publicly accessible privacy policy URL before submission. This is not optional, even for apps that collect no personal data. Prepare this before you open either store dashboard.<\/p>\n\n

    Test on Real Devices \u2014 Flutter Release-Mode Failures to Know<\/strong><\/h3>\n\n

    Debug builds and release builds behave differently in Flutter, and the delta goes beyond “crashes only appear in release mode.” There are several Flutter-specific failure modes that only surface after you run flutter build appbundle –release or flutter build ios –release:<\/p>\n\n

    Tree-shaking removes assets you actually need.<\/strong> In release mode, Flutter applies aggressive Dart AOT tree-shaking. If your code references assets or classes indirectly (through string-based lookups, reflection-style patterns, or generated code), tree-shaking may strip them. The debug build works fine because tree-shaking is disabled in JIT mode. Fix: use explicit references and verify the assets block in pubspec.YAML lists everything needed.<\/p>\n\n

    Dart AOT compilation exposing null-safety issues hidden in JIT debug mode.<\/strong> Debug builds run Dart in JIT (Just-in-Time) mode, which is more forgiving with null checks and type assertions at runtime. Release builds compile to native machine code via AOT (Ahead-of-Time), which enforces strict null-safety and type soundness. Code that runs without errors in debug can throw a null check operator used on a null value in production.<\/p>\n\n

    Platform channel timeouts on low-end devices.<\/strong> Plugin calls that invoke native platform channels (camera, location, Bluetooth, payments) are synchronous from the Dart side but execute asynchronously on the host platform. On low-end Android devices under memory pressure, these calls can time out in release mode, where there are no debug pauses to mask the delay. Test on the lowest-spec device in your target range, not just a flagship. Recommended baseline Android test devices: Samsung Galaxy A14 or Xiaomi Redmi 12C (entry-level, 3\u20134 GB RAM, widely used in Southeast Asia and Latin America). For iOS, test on the oldest device your deployment target supports \u2014 if your minimum is iOS 16, an iPhone 8 (A11 chip, 2 GB RAM) is the right baseline.<\/p>\n\n

    Before submitting, install a release APK on physical Android devices and use TestFlight for iOS testing. Thoroughly test your Flutter app on different devices and operating systems to ensure compatibility and that it functions as intended without bugs or crashes.<\/p>\n\n

    Google Play Store Requirements for Flutter Apps<\/strong><\/h2>\n\n

    Developer Account Setup and Costs<\/strong><\/h3>\n\n

    Create your Google Play Console account at play.google.com\/console. The one-time $25 registration fee applies to both personal and organizational accounts. This account is required to distribute Android apps through the Play Store.<\/p>\n\n

    When you create a new app, you’ll choose between “app” and “game,” select target countries, and set free or paid pricing. These choices can be changed later, but your package name cannot.<\/p>\n\n

    Technical Requirements: AAB Format and API Level<\/strong><\/h3>\n\n

    Android App Bundle is mandatory.<\/strong> New apps published to Google Play since August 2021 must use the .aab format, not a plain APK. Build your release bundle from the project root:<\/p>\n\n

    flutter build appbundle –release<\/p>\n\n

    The output lands at build\/app\/outputs\/bundle\/release\/app-release.aab. You can still use Flutter build APK to create an APK for local device testing or sideloading, but Google Play expects the .aab for new submissions.<\/p>\n\n

    targetSdk 35 is now mandatory.<\/strong> As of August 31, 2025, all new and updated submissions on Google Play must target API level 35 (Google Play target API requirements). Apps still targeting SDK 33 or 34 are rejected immediately. Check your android\/app\/build.gradle:<\/p>\n\n

    android {\n\n\u00a0 \u00a0compileSdk 35\n\n\u00a0 \u00a0defaultConfig {\n\n\u00a0 \u00a0 \u00a0 \u00a0targetSdk 35\n\n\u00a0 \u00a0 \u00a0 \u00a0minSdk 21 \u00a0\/\/ or your minimum\n\n\u00a0 \u00a0}\n\n}<\/code><\/pre>\n\n
    64-bit compliance.<\/strong> A correctly built Flutter app bundle includes both 32-bit and 64-bit Dart code and Flutter runtime compiled artifacts by default. If you’re using native plugins that ship only armeabi-v7a libraries, you’ll need to obtain or build 64-bit versions. Use Android Studio’s APK Analyzer to inspect .so files and confirm arm64-v8a is present.<\/p>\n\n
    App Signing and Keystore Management<\/strong><\/h3>\n\n
    To publish on the Play Store, you must sign your app with a digital certificate. This involves creating an upload keystore.<\/p>\n\n
    \n
    Create the keystore:<\/p>\n
    \u00a0<\/p>\n\n
    keytool -genkey -v -keystore upload-keystore.jks \\<\/p>\n
    \u00a0<\/p>\n\n
    \u00a0-keyalg RSA -keysize 2048 -validity 10000 \\<\/p>\n
    \u00a0<\/p>\n\n
    \u00a0-alias upload<\/p>\n<\/blockquote>\n\n
    Keep the .jks file private and never commit it to public source control. Store it \u2014 and your key passwords \u2014 in a secure location separate from your codebase. A lost keystore means permanent inability to update your app.<\/strong> You cannot recover it. You would have to resubmit as a new app and lose all existing ratings, reviews, and install history.<\/p>\n\n
    \n
    Create a key.properties file in the android\/ folder:<\/p>\n
    \u00a0<\/p>\n\n
    storePassword=yourStorePassword<\/p>\n
    \u00a0<\/p>\n\n
    keyPassword=yourKeyPassword<\/p>\n
    \u00a0<\/p>\n\n
    keyAlias=upload<\/p>\n
    \u00a0<\/p>\n\n
    storeFile=..\/upload-keystore.jks<\/p>\n<\/blockquote>\n\n
    This is your properties file. Reference it in your Gradle file to configure signing for release builds. Add key.properties to .gitignore.<\/p>\n\n
    Enable Play App Signing<\/strong> \u2014 it is strongly recommended. Google manages the final app signing key while you upload with your upload key. If your upload key is ever compromised, Google can rotate it. Without Play App Signing, a compromised key = a compromised app with no recourse.<\/p>\n\n
    The Merged Manifest Permissions Audit<\/strong><\/h3>\n\n
    Before running flutter build appbundle, audit your merged manifest. After a Flutter build, open the merged output at:<\/p>\n\n
    \n
    android\/app\/build\/intermediates\/merged_manifests\/release\/AndroidManifest.xml<\/p>\n<\/blockquote>\n\n
    Compare every <uses-permission> tag against your Google Play Data Safety form declarations. Any permission that appears in the merged manifest \u2014 even if injected by a pub.dev package \u2014 must be declared in Data Safety. Common offenders include analytics SDKs, ad networks, push notification plugins, and crash reporters.<\/p>\n\n
    Google Play Data Safety Form<\/strong><\/h3>\n\n
    Complete the Data Safety section in Google Play Console before submitting for review. Note: In April 2025, Google reclassified Android ID as a device identifier that must be declared. If your Flutter app uses any advertising or analytics plugin, this likely affects you. Declare the data type, collection purpose, and whether it’s shared with third parties.<\/p>\n\n
    Also, complete the app content rating questionnaire, the ads declaration, and the target audience form. Missing any of these blocks in the submission.<\/p>\n\n
    Testing Requirements for Personal Developer Accounts<\/strong><\/h3>\n\n
    If you registered a personal (non-organizational) Google Play Console account, closed testing for personal developer accounts requires at least 12 opted-in testers for 14 continuous days prior to applying for production access.<\/p>\n\n
    How to reach 12 testers: friends, colleagues, beta community forums, or services like BetaFamily. Each tester must actively opt in via your closed testing link \u2014 passive invites don’t count. Start this process as early as possible since it runs in parallel with your final QA cycle.<\/p>\n\n
    Apple App Store Requirements for Flutter Apps<\/strong><\/h2>\n\n
    Developer Program and Hardware Requirements<\/strong><\/h3>\n\n
    An Apple Developer Program enrollment costs $99 per year. Unlike Google’s one-time fee, this renews annually. If your subscription lapses, your apps are delisted from the App Store until you renew.<\/p>\n\n
    A macOS computer with Xcode installed is required to build and sign iOS apps. There is no workaround for debugging on a physical iOS device \u2014 that still requires macOS. However, for teams without a Mac (agencies shipping a client’s Flutter app, for example), Codemagic<\/strong> provides a cloud-based Mac environment that can compile, sign, and submit iOS apps without a local Mac. This is a common workflow for cross-platform Flutter teams.<\/p>\n\n
    Bundle Identifier, Signing, and Capabilities<\/strong><\/h3>\n\n
    Open the ios\/ folder in Xcode (or open Runner.xcworkspace). Set a unique bundle identifier matching your Apple Developer portal registration \u2014 for example, com.company.appname. An App Store listing must be created via App Store Connect and a bundle ID registered before you can upload a build.<\/p>\n\n
    Enable automatic signing if you’re working solo, or configure manual provisioning profiles for team or CI\/CD setups. Under the “Signing & Capabilities” tab, enable any necessary capabilities for your Flutter app \u2014 Sign in with Apple, Push Notifications, HealthKit, and so on. Capabilities that are declared in your code but not enabled in Xcode’s entitlements are a common rejection source.<\/p>\n\n
    Do not change the bundle identifier after publishing.<\/strong> Like Android’s application ID, changing it creates a new app entry.<\/p>\n\n
    Apple Privacy Manifest: A Hard Upload Block<\/strong><\/h3>\n\n
    Since February 12, 2025, every iOS app upload that doesn’t include a valid PrivacyInfo.xcprivacy file is rejected at the point of upload \u2014 before it even reaches a human reviewer.<\/p>\n\n
    Your Privacy Manifest must cover:<\/p>\n\n
      \n
    1. The Flutter framework itself<\/strong> \u2014 Flutter appears on Apple’s list of required-reason APIs (it uses UserDefaults for preferences and file timestamp APIs). Your manifest must include the correct NSPrivacyAccessedAPITypes entries for these.<\/li>\n\n
    2. Every pub.dev plugin on Apple’s required-SDK list<\/strong> \u2014 check each plugin’s repository for its own PrivacyInfo.xcprivacy. Well-maintained packages include one; older or unmaintained ones may not, and you’ll need to add coverage manually or switch packages.<\/li>\n<\/ol>\n\n
      Run flutter build ios –release and verify the archive contains a valid Privacy Manifest before attempting an upload via Xcode or the Transporter tool.<\/p>\n\n
      Here is a minimal PrivacyInfo.xcprivacy template covering the Flutter framework’s required APIs. Add this file to your Xcode project under the Runner target (not a framework target):<\/p>\n\n
      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\n<!DOCTYPE plist PUBLIC \"-\/\/Apple\/\/DTD PLIST 1.0\/\/EN\"\n\n  \"http:\/\/www.apple.com\/DTDs\/PropertyList-1.0.dtd\">\n\n<plist version=\"1.0\">\n\n<dict>\n\n  <key>NSPrivacyAccessedAPITypes<\/key>\n\n  <array>\n\n    <!-- Flutter framework: UserDefaults (NSUserDefaults) -->\n\n    <dict>\n\n      <key>NSPrivacyAccessedAPIType<\/key>\n\n      <string>NSPrivacyAccessedAPICategoryUserDefaults<\/string>\n\n      <key>NSPrivacyAccessedAPITypeReasons<\/key>\n\n      <array>\n\n        <string>CA92.1<\/string>\n\n      <\/array>\n\n    <\/dict>\n\n    <!-- Flutter framework: file timestamp APIs -->\n\n    <dict>\n\n      <key>NSPrivacyAccessedAPIType<\/key>\n\n      <string>NSPrivacyAccessedAPICategoryFileTimestamp<\/string>\n\n      <key>NSPrivacyAccessedAPITypeReasons<\/key>\n\n      <array>\n\n        <string>C617.1<\/string>\n\n      <\/array>\n\n    <\/dict>\n\n  <\/array>\n\n  <key>NSPrivacyCollectedDataTypes<\/key>\n\n  <array\/>\n\n  <key>NSPrivacyTracking<\/key>\n\n  <false\/>\n\n<\/dict>\n\n<\/plist><\/code><\/pre>\n\n
      If your app uses plugins that also appear on Apple’s required-SDK list (common ones include path_provider, shared_preferences, and firebase_core), check each plugin’s repository for its own PrivacyInfo.xcprivacy. Well-maintained plugins bundle this file automatically from Flutter 3.18+. For plugins that don’t, you either add their required-reason entries to your app-level manifest above, or migrate to a maintained alternative.<\/p>\n\n
      Info.plist Permission Strings<\/strong><\/h3>\n\n
      Every permission your app requests needs a clear usage description string in Info.plist. Camera, microphone, photo library, location (always vs. when-in-use), Bluetooth, contacts, health data \u2014 each requires its own NS*UsageDescription key with a plain-language explanation of why the app needs it.<\/p>\n\n
      Vague strings like “This app needs camera access” are a common rejection reason. Apple’s reviewers check that the stated reason matches the actual app functionality. Review the app store guidelines to ensure your descriptions are specific and accurate.<\/p>\n\n
      If your Flutter app or any of its plugins use App Tracking Transparency (advertising identifiers, cross-app tracking), you must implement the ATT prompt and declare it in App Store Connect’s privacy nutrition labels.<\/p>\n\n
      Build and Upload Process<\/strong><\/h3>\n\n
      Build the iOS release:<\/p>\n\n
      flutter build ios –release<\/p>\n\n
      Open the iOS workspace in Xcode, select “Any iOS Device (arm64)” as the target, then go to Product \u2192 Archive<\/strong>. Once the archive is complete, use the Organizer window to upload via Xcode’s distribution workflow. Uploading an app using Xcode or the Transporter tool is necessary for iOS deployment.<\/p>\n\n
      After upload, connect the build to your app version in App Store Connect, complete the App Review information (including test account credentials if your app requires login), fill in the privacy nutrition labels, and submit for review.<\/p>\n
      Watch: How to Build, Sign, and Publish a Flutter App on Google Play<\/h4>\n
      Before submitting your Flutter application to Google Play, it’s helpful to see the complete publishing workflow in action. This step-by-step tutorial demonstrates how to generate a release build, configure app signing, create an Android App Bundle (AAB), and publish your application through the Google Play Console\u2014complementing the publishing checklist and technical requirements covered in this guide.<\/p>\n
      \u00a0<\/p>\n\n