Flutter publishing
Publish a Flutter app to the App Store and Google Play
Shiptavio builds, signs, and submits your Flutter project through our Apple Developer and Google Play organization accounts, never individual accounts. You send source and store assets; you do not need a Mac, Xcode, or a developer account. The service is for free apps without in-app purchases.
Updated 26 October 2026. Free apps only. No in-app purchases or subscriptions.
Framework
Flutter and Dart
Source we build
Your project, including ios/ and android/
Store accounts
Company organization accounts, with transfer available later
Best fit
A free Flutter app that is ready for store review
Company organization accounts, not individual accounts
App Store publishing runs on the Apple Developer organization account of our Malaysia-based organization. Google Play publishing runs on our Google Play organization account. We do not use an individual or personal developer account for a customer app.
Promo price
RM199 per app for 12 months.
5 release credits included: your first publish plus up to 4 updates. One credit covers one publish or update, whether it targets iOS, Android, or both.
When they run out, buy the same RM199 package for 5 more. We do not sell single base credits.
macOS, tvOS and visionOS publishing is available separately at RM49 per platform credit. One credit covers one Apple platform release target.
After the launch period: RM399 per app for 12 months. Ends 31 December 2026.
What Shiptavio handles
- Review the Flutter project before the build starts.
- Run the documented release build on our Mac, including the iOS and Android targets.
- Sign with our distribution certificates and upload to App Store Connect and Google Play.
- Handle store feedback and resubmissions for the same release.
- Transfer the app to your own Apple and Google accounts later if you ask.
What we do not do
- Write or rewrite Dart code.
- Create a new Flutter project from a website.
- Sell in-app purchases or digital subscriptions.
- Guarantee that Apple or Google will approve the app.
- Test the app on your behalf or replace device QA.
What to send
Send source, not a finished binary. The source must be complete enough for us to reproduce your release build.
- The full Flutter project, including ios/ and android/.
- pubspec.yaml and pubspec.lock.
- The exact build command, including any flavor or non-secret --dart-define values.
- App icon, screenshots, store text, privacy policy, and a demo account if the app has a login.
- Production environment values for any API the app calls.
How a Flutter release works
The same review and credit rules apply to every framework. The build command and the native files are what change.
- 1
Register the app
Create an account, choose Flutter, and select iOS, Android, or both. macOS, tvOS, and visionOS are optional Apple platform targets with a separate credit.
- 2
Send the source
Use a GitHub repository or a source zip. Include the native folders and the lockfile. Leave out build output, dependency caches, .env files, keystores, and private keys.
What the project should containmy_app/ pubspec.yaml pubspec.lock lib/ ios/ android/ - 3
We build and sign
We install dependencies, run your release build on our Mac, sign with our Apple Developer organization certificate, and produce the Android App Bundle with our Google Play organization account key.
- 4
We submit and track
We upload to App Store Connect and Google Play, answer store feedback, and update the status in your dashboard. You can follow each platform separately.
Technical notes
These are the details that decide whether the source builds and whether the store accepts the upload.
Do not send build output
build/, .dart_tool/, ios/Pods/, and android/.gradle/ are generated. The CLI and the dashboard exclude the usual build folders, but check your zip if you upload one by hand.
Keep the bundle ID stable
Set the iOS bundle identifier and the Android applicationId once. Changing either after the first publish creates a different app in the store.
Increment the build number
pubspec.yaml uses version: 1.2.0+42, where 42 is the build number. Increase it for every store upload so the stores accept the new build.
Flavors and dart-define
If you use flavors, send the exact flutter build command and the matching entry file. Values passed with --dart-define are compiled into the app, so do not use them for secrets.
Permissions and usage strings
Add iOS usage descriptions to ios/Runner/Info.plist and Android permissions to the manifest. Reviewers test what happens when a permission is denied.
Testing is your responsibility
Shiptavio builds and submits, but it does not replace device QA. Test the core flow on a real iPhone and a real Android phone before you submit.
Before you submit
- The app is free and has no in-app purchases or subscriptions.
- The bundle ID and Android package name are final.
- The version and build number are incremented.
- The native folders are present and the project builds.
- Icons, screenshots, privacy policy, and a demo account are ready.
- No .env files, keystores, or private keys are in the source.
Flutter publishing tutorial
Set the app identity, prepare assets, run the release builds, and package source for Shiptavio.
Open the tutorialQuestions
Do I need a Mac to publish a Flutter app?
Do I need an Apple Developer Program membership?
Can you build a Flutter app with flavors?
Can I send an IPA or AAB?
Can I publish a paid Flutter app or in-app purchases?
Does Shiptavio guarantee App Store approval?
Related guides
Publish an Expo app
For Expo projects that use prebuild or a custom native setup.
Publish a React Native app
For bare React Native CLI projects with ios/ and android/.
Submit with the CLI
Package and send a release from your terminal or CI.
How to submit
The full dashboard flow, from account creation to store review.
Compare publishing options
Shiptavio, Expo EAS, Codemagic, and Fastlane side by side.
Prohibited apps
Check the categories we cannot publish before you start.
Ready to send your Flutter project?
Create an account, register the app, and add the source. A person reviews the project before the build starts.