LaunchLint Academy
Die kurze Antwort
- FlutterFlow kann Builds direkt zu Apple und Google übertragen, übernimmt aber nicht die inhaltliche Verantwortung für App, Fremdpakete, Datenschutz und Store-Eintrag.
- Behandle generierten Code, Custom Actions, API-Verbindungen, Umgebungen und Deployment-Zugang wie einen normalen Produktions-Release mit überprüfbaren Nachweisen.
- 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. Produktionsumgebung wählen
Package Name, API-Endpunkte, Firebase-Projekt und Feature Flags müssen eindeutig zur veröffentlichten Umgebung gehören.
Prüfe produktionsumgebung wählen 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 produktionsumgebung wählen 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. Store-Identität anlegen
Bundle ID, App ID und Play-Paketname werden zwischen FlutterFlow, Entwicklerkonten und Store-Einträgen exakt abgeglichen.
Prüfe store-identität anlegen 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-identität anlegen 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. Deployment-Zugang schützen
App-Store-Connect-Schlüssel, Issuer ID, Service Accounts und Keystore erhalten minimale Rechte, Eigentümer und Rotation.
Prüfe deployment-zugang schützen 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 deployment-zugang schützen 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. Custom Code inventarisieren
Custom Actions, Widgets und Pakete umgehen leicht visuelle Annahmen und können native Rechte oder Datenflüsse hinzufügen.
Prüfe custom code inventarisieren 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 custom code inventarisieren 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. Berechtigungen und Privacy Manifest
Kamera, Standort, Dateien und Required Reason APIs brauchen konkrete Konfiguration statt eines generischen Builder-Defaults.
Prüfe berechtigungen und privacy manifest 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 berechtigungen und privacy manifest 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. Backend und Daten erklären
Firebase, Supabase, APIs, Analytics und Uploads müssen mit Datenschutzerklärung, App Privacy und Data Safety übereinstimmen.
Prüfe backend und daten erklären 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 backend und daten erklären 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. Echten Store-Build testen
Preview und Test Mode ersetzen keinen signierten Build mit echten Redirects, Push, Käufen und Produktionsregeln.
Prüfe echten store-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 echten store-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
8. Einreichung vervollständigen
Direktes Deployment lädt den Build hoch; Screenshots, Hinweise für das Prüfteam, Inhalte, Länder und Freigabe bleiben separate Arbeit.
Prüfe einreichung vervollständigen 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 einreichung vervollständigen 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
Erledigt FlutterFlow die komplette Einreichung?
Nein. FlutterFlow kann übertragen, aber Store-Angaben und Review-Aufgaben bleiben beim Entwickler.
Muss Custom Code geprüft werden?
Ja. Er kann Berechtigungen, Secrets, SDKs und Verhalten verändern.
Kann ich denselben Package Name für Staging nutzen?
Separate Umgebungen brauchen normalerweise eigene, bewusst verwaltete Identitäten.
Führt LaunchLint mein FlutterFlow-Projekt aus?
Nein. Typische Exporte werden statisch gelesen; fremder Code wird nie ausgeführt.