Eine Flutter-App im Play Store und App Store veröffentlichen: Schritt-für-Schritt-Anleitung

Die applicationId (Android) und die Bundle ID (iOS) sind die dauerhafte Identität Ihrer App in jedem Store; keine der beiden lässt sich nach dem ersten Upload ändern. Legen Sie beide vor Beginn der Veröffentlichung endgültig fest — eine spätere Änderung bedeutet, einen komplett neuen Eintrag bei null zu beginnen und Ihre bestehenden Bewertungen und Installationszahlen zu verlieren.

In Flutter steht die Versionsnummer im Feld version: x.y.z+N von pubspec.yaml; x.y.z ist die für Nutzer sichtbare Version, und N ist die Build-Nummer, die gleichzeitig dem Android versionCode und der iOS Build Number entspricht. Wird N bei einer neuen Store-Einreichung nicht erhöht, wird der Upload abgelehnt.

Die Icon-Anforderungen unterscheiden sich zwischen den Stores: Play verlangt ein hochauflösendes 512x512-Pixel-Icon mit Alphakanal (Transparenz), während der App Store ein 1024x1024-Pixel-PNG OHNE Alphakanal erwartet. Mit dem Paket flutter_launcher_icons können Sie beide aus einem einzigen Quellbild mit einem Befehl erzeugen.

Der Befehl flutter build appbundle --release erzeugt das store-fertige Paket unter build/app/outputs/bundle/release/app-release.aab. Der Play Store akzeptiert für neue Uploads inzwischen nur noch das .aab-Format; eine separate .apk müssen Sie nicht erzeugen.

Persönliche (individuelle) Play-Console-Konten, die nach dem 13. November 2023 eröffnet wurden, müssen vor dem Produktionszugang einen ununterbrochenen 14-tägigen geschlossenen Test mit mindestens 12 aktiven Testern abschließen. Diese Anforderung gilt nicht für Organisationskonten oder früher eröffnete persönliche Konten; prüfen Sie vor der Beantragung die aktuelle Anforderung in Play Console, da sich die Regel gelegentlich ändert.

Die allererste .aab, die für eine App in Play Console hochgeladen wird, muss immer manuell hochgeladen werden — keine CLI oder automatisierte Einreichung dafür; spätere Releases können eine CLI oder eine eigene Integration nutzen. Beim Übergang in die Produktion senkt ein gestaffelter Rollout (z. B. zunächst 5-20 %, schrittweise Erhöhung unter Beobachtung von Android vitals) statt einer sofortigen Veröffentlichung an alle das Risiko.

Der Befehl flutter build ipa --release erzeugt eine release-fertige .ipa-Datei unter build/ios/ipa/. Um diesen Build zu archivieren und an App Store Connect zu senden, benötigen Sie einen Mac (physisch oder in der Cloud); Xcode läuft nicht unter Windows oder Linux. Besitzen Sie keinen Mac, sind Cloud-CI-Dienste wie Codemagic, GitHub-Actions-macOS-Runner oder MacStadium eine Option.

Die resultierende .ipa können Sie entweder über den Ablauf des Xcode Organizer (Window > Organizer > Archives > Distribute App) oder über die eigenständige Transporter-App zu App Store Connect hochladen; beide führen zum gleichen Ergebnis. Version (nutzerseitig sichtbar) und Build-Nummer (muss pro Upload eindeutig und steigend sein, innerhalb derselben Version nicht wiederverwendbar) sind zwei getrennte Felder.

TestFlight bietet zwei Teststufen: Der interne Test (bis zu 100 Personen in Ihrem App-Store-Connect-Team) erfordert KEINE Apple-Prüfung und steht zur Verfügung, sobald der Build verarbeitet wurde. Der externe Test richtet sich an Tester, die per E-Mail oder öffentlichem Link beitreten (bis zu 10.000 pro Gruppe); der ERSTE Build, der einer App hinzugefügt wird, muss Apples „Beta Review" bestehen (meist innerhalb eines Tages abgeschlossen), während spätere Builds keine vollständige Prüfung mehr benötigen müssen.

Bei Play gelten strenge Zeichenlimits: App-Name bis zu 30, Kurzbeschreibung bis zu 80, Vollbeschreibung bis zu 4000 Zeichen. Bei App Store Connect muss der App-Name im gesamten Store eindeutig sein, außerdem sind ein Untertitel und ein Keywords-Feld auszufüllen. Screenshot-Größen (1080x1920 für Play-Telefon-Screenshots, exakte Pixelmaße für die 6,9-Zoll-iPhone-Klasse des App Store) folgen in jedem Store unterschiedlichen Regeln.

Beide Stores verlangen, dass Sie Ihr Datenerfassungsverhalten deklarieren: das Data-safety-Formular von Play und die App-Privacy-Labels des App Store (manchmal „Nährwertkennzeichnung" genannt). Nutzen Sie ein Werbe-SDK, Analytics oder Crash-Reporting, müssen Sie dies auf beiden korrekt angeben; keines der beiden Panels lässt Sie ohne eine wirklich erreichbare, aktuelle Datenschutzerklärungs-URL veröffentlichen.

Beide Panels verlangen außerdem ein Support-/Kontaktfeld: bei Play eine kontoweite Support-E-Mail und ein optionales Website-Feld; bei App Store Connect eine verpflichtende Support-URL und eine optionale Marketing-URL. Falls Sie für diese Felder keine Website haben, behandeln wir praktische Optionen in einem separaten Beitrag.

Die häufigsten Apple-Ablehnungen sind: Guideline 2.1(a) (Abstürze, leere Bildschirme, defekte Links, nicht deklarierte fehlende Funktionen, oder ein fehlendes funktionierendes Demo-Konto in den Review Notes für eine Login-pflichtige Funktion), Guideline 5.1.1 (leere oder vage Beschreibungen der Berechtigungsnutzung) und Guideline 4.3 (Template-Apps, die mit kleinen Änderungen erneut eingereicht werden). End-to-End-Tests auf einem sauberen Gerät vor der Einreichung verhindern die meisten dieser drei Fälle.

Bei Play ist das häufigste Problem ein Data-safety-Formular, das nicht dem tatsächlichen SDK-Verhalten entspricht, oder eine leere/nicht erreichbare Datenschutzerklärungs-URL; beides birgt das Risiko einer Ablehnung oder späteren Sperrung. Die Nutzung von AdMob ohne app-ads.txt-Verifizierung führt nicht direkt zur Ablehnung, kann aber die Anzeigenauslieferung einschränken und Umsatz kosten.

Bei Projekten mit Expo (EAS) ist der Ablauf weitgehend automatisiert: npx eas-cli build --platform all --profile production baut in der Cloud für beide Stores, und npx eas-cli submit automatisiert die Einreichung (abgesehen von Plays Erst-Upload-Ausnahme). Versionsnummern liegen in drei getrennten Feldern in app.json — expo.version, expo.ios.buildNumber und expo.android.versionCode — statt in Flutters einzelnem pubspec.yaml-Feld, und müssen manuell synchron gehalten werden.