LaunchLint Academy
Die kurze Antwort
- Eine Ionic/Capacitor-App besteht aus Web-Build, Bridge, Plugins und zwei nativen Projekten. Ein korrekter Browser-Build beweist deshalb noch keine sichere oder store-konforme mobile Veröffentlichung.
- Prüfe synchronisierte Web-Assets, Plugin-Berechtigungen, native Konfiguration, Navigation, Offline-Fehler und Store-Angaben als zusammenhängenden Release.
- 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. Web-Artefakt einfrieren
Der vorgesehene Produktions-Build muss vollständig sein, richtige Endpunkte enthalten und vor der nativen Synchronisierung feststehen.
Prüfe web-artefakt einfrieren 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 web-artefakt einfrieren 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. Capacitor-Konfiguration
appId, appName, webDir, Server-Optionen und Plugins müssen zur Store-Identität und zum Release-Modell passen.
Prüfe capacitor-konfiguration 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 capacitor-konfiguration 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. Native Projekte synchronisieren
Änderungen an Web-Assets oder Plugins werden bewusst in iOS und Android übernommen und im Commit nachvollzogen.
Prüfe native projekte synchronisieren 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 projekte synchronisieren 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. Plugins und Berechtigungen
Jedes Plugin kann native Rechte, SDKs, Manifest-Einträge und Datenschutzpflichten hinzufügen.
Prüfe plugins und 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 plugins und 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. Navigation und WebView-Sicherheit
Externe URLs, Deep Links, JavaScript-Brücken und erlaubte Domains brauchen restriktive Regeln und echte Gerätetests.
Prüfe navigation und webview-sicherheit 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 navigation und webview-sicherheit 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. Plattformkonfiguration
Info.plist, Entitlements, AndroidManifest, Network Security Config, Signierung und Versionswerte werden separat geprüft.
Prüfe plattformkonfiguration 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 plattformkonfiguration 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. Release-Verhalten testen
Offline-Zustände, Zurück-Navigation, Tastatur, Dateien, Kamera, Push und Wiederaufnahme unterscheiden sich vom Browser.
Prüfe release-verhalten 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-verhalten 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. Store-Prüfung vorbereiten
Der hybride Ursprung entschuldigt weder unklare Metadaten noch fehlende Review-Zugänge, Datenschutzangaben oder Käufe.
Prüfe store-prüfung 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-prüfung 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
Häufige Fragen
Reicht ein erfolgreicher Web-Build?
Nein. Plugins, Bridge und native Projekte bestimmen das ausgelieferte mobile Verhalten.
Muss ich ios und android committen?
Für reproduzierbare Releases sollten relevante native Änderungen nachvollziehbar versioniert sein.
Sind alle externen URLs unproblematisch?
Nein. Erlaubte Navigation, Deep Links und die JavaScript-Brücke brauchen enge Grenzen.
Unterstützt LaunchLint Capacitor?
Ja. Ionic/Capacitor-Projekte werden statisch geprüft, ohne den Web- oder Native-Code auszuführen.