LaunchLint Academy
Die kurze Antwort
- Ein erfolgreicher Flutter-Build ist noch keine einreichungsbereite App. Bundle ID, Application ID, Versionen, Signierung, native Berechtigungen, Datenschutzangaben und Store-Eintrag müssen denselben Produktionsstand beschreiben.
- Friere einen Release-Kandidaten ein, teste das tatsächlich verteilte Artefakt auf echten Geräten und halte für jede Store-Angabe einen Nachweis bereit.
- Arbeite die Checkliste nicht erst am Tag der Einreichung ab. Lege sie als Release-Gate im Projekt an, verknüpfe jeden Punkt mit dem zuständigen Commit oder Store-Feld und wiederhole betroffene Prüfungen nach jeder Änderung an Abhängigkeiten, Berechtigungen, Umgebungswerten oder Metadaten. Speichere keine Secrets oder personenbezogenen Testdaten im Nachweis. Für die finale Freigabe sollten Entwicklung, Produkt und die Person mit Zugriff auf die Store-Konsole denselben Build beurteilen. So wird aus einer einmaligen Kontrolle ein reproduzierbarer Prozess, der auch nach einer Ablehnung oder bei einem späteren Update erklärt, welcher Stand tatsächlich geprüft wurde.
1. Release-Kandidat festlegen
Bestimme Commit, Flutter-Version, Flavor, Umgebungswerte und Zielplattformen, bevor native Archive entstehen.
Prüfe release-kandidat festlegen nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für release-kandidat festlegen festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
2. App-Identität und Versionen
Bundle Identifier, Application ID, Marketing-Version und technische Build-Nummern dürfen nach dem Upload nicht auseinanderlaufen.
Prüfe app-identität und versionen nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für app-identität und versionen festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
3. Signierung und Besitz
Apple-Zertifikate, Provisioning, Android-Upload-Key und Play App Signing brauchen klare Eigentümer und sichere Wiederherstellung.
Prüfe signierung und besitz nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für signierung und besitz festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
4. Native Berechtigungen
Info.plist, AndroidManifest und Plugin-Konfiguration müssen nur notwendige Rechte mit konkreten Nutzungserklärungen enthalten.
Prüfe native berechtigungen nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für native berechtigungen festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
5. Plugins und Datenschutz
Dart-Packages können native SDKs und Datenflüsse einbringen, die in App Privacy, Data Safety und Datenschutzerklärung auftauchen.
Prüfe plugins und datenschutz nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für plugins und datenschutz festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
6. Release-Build testen
Debug-Verhalten beweist nicht, dass Login, Deep Links, Push, Käufe und Fehlerbehandlung im signierten Build funktionieren.
Prüfe release-build testen nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für release-build testen festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
7. Store-Metadaten vorbereiten
Screenshots, Beschreibung, Support, Testzugang für das Prüfteam und Angaben zu Käufen müssen den eingefrorenen Build wahrheitsgemäß erklären.
Prüfe store-metadaten vorbereiten nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für store-metadaten vorbereiten festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
8. Upload und kontrollierter Rollout
Verarbeitung, TestFlight beziehungsweise Test-Track, Review-Warnungen und Monitoring gehören vor die endgültige Freigabeentscheidung.
Prüfe upload und kontrollierter rollout nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für upload und kontrollierter rollout festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
Häufige Fragen
Reicht flutter build ipa oder appbundle?
Nein. Der Befehl erzeugt ein Artefakt, vervollständigt aber weder Store-Angaben noch Testzugang für das Prüfteam oder Datenschutzformulare.
Kann ich Bundle ID oder Application ID später ändern?
Nach dem ersten Store-Upload sind diese Identitäten praktisch fest. Prüfe sie vor dem Anlegen der Store-Einträge.
Muss ich Plugins einzeln prüfen?
Ja. Plugins können Berechtigungen, native SDKs und Datenverarbeitung hinzufügen.
Baut LaunchLint meine Flutter-App?
Nein. LaunchLint liest unterstützte Projektdateien statisch und führt niemals fremden Code aus.