Flutter • iOS • App Store Connect

A Complete Guide to Publishing a Flutter App on the Apple App Store

From your first iOS release build to TestFlight, App Review, and a successful App Store launch.

Who is this guide for? Flutter developers who have an app ready for iOS distribution. You need a Mac with a compatible version of Xcode and access to the Apple Developer Program. Apple requirements change, so verify current policies before submitting.

Publishing workflow at a glance

👤

1. Account

Developer Program

⚙️

2. Configure

Bundle ID and signing

📦

3. Build

Archive and upload

🚀

4. Release

Review and launch

1. Prerequisites

Mac and Xcode: iOS builds and signing require macOS and Xcode. Use versions supported by your Flutter SDK and accepted by App Store Connect.
Flutter SDK: Use a stable release and check that your plugins support the target iOS version.
Apple Developer Program: Enroll if you need App Store distribution. Membership terms and fees depend on your region and account type.
App assets: Prepare an app icon, screenshots, description, support information, and a privacy policy URL where required.

flutter doctor -v
flutter --version
xcodebuild -version
pod --version

Resolve toolchain and CocoaPods issues before preparing your release build.

2. Prepare and test your Flutter project

flutter pub get
flutter analyze
flutter test

Run the release build on a physical iPhone if possible. Simulator testing is useful, but does not fully test push notifications, camera, location, Apple sign-in, payments, and other device-dependent features.

Review iOS permissions

If your app uses protected resources, review ios/Runner/Info.plist and add accurate purpose strings only for the features you actually use. For example:

<key>NSCameraUsageDescription</key>
<string>Use the camera to take a profile photo.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Select a photo to use as your profile picture.</string>

These are examples, not universal entries. The message should describe the real feature and user benefit. Do not request unnecessary permissions.

3. Configure your Bundle ID

The Bundle ID uniquely identifies your iOS app. Choose a stable reverse-domain identifier, such as com.example.myflutterapp, and use the same value in the Apple Developer configuration, Xcode target, and App Store Connect record.

Open Certificates, Identifiers & Profiles in your Apple Developer account.
Create an explicit App ID if one does not already exist.
Open the iOS workspace:

open ios/Runner.xcworkspace

In Xcode, select the Runner project and target.
Open General → Identity and set the Bundle Identifier to match your registered App ID.
Set the display name shown under the app icon.

Important: Changing the Bundle ID after publishing can affect app identity and update continuity. Choose carefully before the first release.

4. Configure code signing

In Xcode, select the Runner target and open Signing & Capabilities.
Enable Automatically manage signing when appropriate.
Select the correct Apple Developer team.
Verify the Bundle ID and resolve signing warnings.

If your app uses Push Notifications, Associated Domains, Sign in with Apple, App Groups, or other capabilities, configure them in both the Apple Developer account and Xcode. Some capabilities also need backend or domain setup. Never share certificates, private keys, or account credentials publicly.

5. Add app icon and launch screen

Replace template artwork in ios/Runner/Assets.xcassets with your production icon. Follow Apple's current icon requirements, check supported appearances such as light, dark, or tinted where applicable, and test the result on a device. Review the launch screen for outdated branding or placeholder content.

6. Set version and build number

In pubspec.yaml, use a version line such as:

version: 1.0.0+1

1.0.0 is the user-facing version; 1 is the build number. Increase the build number for every newly uploaded build of the same app version. You can override these values with build flags.

7. Create an App Store Connect app record

Sign in to App Store Connect. Open Apps, add a new app, select iOS, and enter the app name, primary language, Bundle ID, and an internal SKU. Verify that the Bundle ID matches your Xcode project. The app record is where you manage metadata, screenshots, privacy details, pricing, builds, and review submissions.

8. Build the release IPA

Run the following commands from your Flutter project root:

flutter clean
flutter pub get
flutter build ipa --release

Flutter typically creates an Xcode archive under build/ios/archive/ and an IPA under build/ios/ipa/. Check the command output if your configuration differs.

To set the version and build number explicitly:

flutter build ipa --release \
  --build-name=1.0.0 \
  --build-number=2

For a custom export configuration, you can use an export options plist, provided it is configured for your signing and distribution workflow:

flutter build ipa --release \
  --export-options-plist=ios/ExportOptions.plist

If the build fails, read the first meaningful error in the Flutter/Xcode logs and address it before changing multiple signing settings.

9. Upload the build to App Store Connect

You can upload through Xcode or Apple's Transporter app. A typical Xcode workflow:

Open ios/Runner.xcworkspace.
Select an appropriate archive destination.
Choose Product → Archive.
When Organizer opens, select the archive and choose Distribute App.
Choose App Store Connect distribution, validate the archive, and follow the upload steps.

Alternatively, open the generated IPA in Transporter and upload it. Wait for Apple to process the build; it may not appear in App Store Connect immediately.

Build versus release: Uploading a build does not publish it to the public App Store. You still need to complete metadata, select the build, and submit it for review.

10. Test with TestFlight

Open the app's TestFlight section in App Store Connect.
Wait for the uploaded build to finish processing.
Complete any required beta testing information.
Add internal testers or configure an external testing group. External testing may require beta app review.
Install the build through TestFlight and test the complete user journey.

Test sign-in, account creation, password recovery, purchases, notifications, deep links, file uploads, permissions, offline behavior, and production backend configuration. A release build should be tested independently of debug mode.

11. Complete the App Store listing

Prepare accurate metadata before submitting. Fields can vary by app and current Apple requirements. Common items include:

App name and subtitle.
Description and keywords where available.
App icon and required screenshot sizes.
Category and age-rating questionnaire.
Support URL and marketing URL, if used.
Privacy policy URL and App Privacy questionnaire.
Pricing and country/region availability.
Review contact details, notes, and demo credentials if login is required.

Use current screenshots that show the actual app. Avoid placeholder content, misleading claims, and broken links. Ensure the support information works.

12. Privacy, data collection, and account deletion

Answer Apple's privacy questions based on what your app and its third-party SDKs actually collect and how the data is used. Review analytics, crash reporting, advertising, authentication, payments, and backend services—not only your Dart code.

Privacy policy: Explain data collection, purpose, use, and relevant user choices or contact options.
App Privacy details: Report collection and use accurately, including relevant third-party SDK behavior.
Tracking: If your app tracks users across apps or websites as Apple defines tracking, review App Tracking Transparency requirements.
Login services: If you use certain third-party or social login services for the primary account, check Apple's current Sign in with Apple rules and exceptions.
Account deletion: If users can create accounts, review Apple's in-app account deletion requirements and implement a real deletion flow when applicable.
Permissions: Ask only for access needed by a clear feature and explain why it is needed.

Do not copy another app's privacy answers. They must match your own app, SDKs, backend, and actual behavior.

13. Review payments and subscriptions

If your app sells digital features, content, or subscriptions, review Apple's current in-app purchase rules for your business model and storefronts. Physical goods and services consumed outside the app can be treated differently; do not assume every payment flow can use an external processor.

Make prices, trial periods, renewal terms, and subscription benefits clear.
Test purchase, restore purchase, cancellation, and error states.
Provide required subscription terms and links.
Ensure reviewers can access paid or restricted features using the instructions or demo account provided.

14. Submit for App Review

Open your app version in App Store Connect.
Complete required metadata and compliance questions.
Select the correct processed build.
Provide review notes and a working demo account if needed.
Choose Add for Review and review the draft submission.
Choose Submit for Review to send it to Apple.

Monitor the status in App Store Connect. If Apple requests changes, read the message carefully, address the specific issue, upload a new build if needed, and reply through the resolution process.

15. Common rejection or delay causes

Issue	What to check
Crashes or freezes	Test release builds on real devices and fix startup, navigation, and network failures.
Reviewer cannot log in	Provide working credentials and clear instructions, or explain access where no account is needed.
Privacy information incomplete	Reconcile privacy answers, SDK behavior, permissions, and policy.
Payment issues	Check applicable purchase rules, price disclosure, restore flow, and reviewer access.
Placeholder content	Remove unfinished screens, broken links, and inaccurate screenshots.
Signing mismatch	Verify Bundle ID, team, version, build number, and selected build.

Use Apple's current App Review Guidelines as the authoritative reference. A successful build does not guarantee approval; Apple reviews functionality, content, privacy, and compliance.

16. Release and monitor the app

After approval, follow the release option configured for your app version. Depending on your settings, you may release automatically after approval, release manually, or use a phased release where available. Confirm pricing, territories, and the final listing before launch.

After launch, monitor crash reports, customer reviews, support requests, analytics, and backend health. Keep a plan for shipping fixes if a production issue appears.

17. Final pre-submission checklist

☐ Flutter dependencies resolved, analyzer clean, tests passing.
☐ Correct Xcode team, Bundle ID, signing, capabilities, and deployment target.
☐ Final icon, launch screen, and accurate permission messages.
☐ Correct version and unique build number.
☐ Release IPA generated and validated.
☐ Release build tested on a physical device and through TestFlight.
☐ Description, screenshots, category, age rating, and URLs complete.
☐ Privacy policy and App Privacy details accurate.
☐ Demo credentials and review notes supplied if needed.
☐ Payments, account deletion, login, and SDK compliance reviewed.

Conclusion

Publishing a Flutter app on the Apple App Store is a repeatable workflow: prepare the project, configure signing, build and upload the IPA, test through TestFlight, complete your store listing, and submit the selected build for review. Testing the release build early, keeping privacy information accurate, and giving reviewers reliable access can reduce delays.

Official resources

Apple's supported Xcode versions, upload requirements, metadata fields, and review policies may change. Verify current requirements in official documentation before submitting.

Flutter Learning

Search This Blog