LaunchLint Academy
Die kurze Antwort
- Berechtigungen sind Produktverhalten, Plattformkonfiguration und Datenschutzversprechen zugleich. Fordere nur Zugriff an, der für eine aktuelle Funktion notwendig ist, und erkläre ihn im Moment der Nutzung konkret.
- Prüfe iOS-Purpose-Strings, Android-Manifest, Laufzeitverhalten-Flow, Ablehnung und Fallback gemeinsam. Eine deklarierte Berechtigung ohne erreichbare Funktion ist ebenso verdächtig wie ein Feature ohne passende Konfiguration.
- Diese Checkliste ist kein einmaliger Content-Check. Führe sie vor dem ersten Store-Upload, nach relevanten Änderungen an Abhängigkeiten oder Konfigurationen und unmittelbar vor der Freigabe erneut aus. Entwicklung, Produkt und die Person mit Zugriff auf die Store-Konsole müssen denselben Build beurteilen. Statische Signale im Projekt sind besonders wertvoll, weil sie reproduzierbar sind, beweisen aber weder das Laufzeitverhalten noch die Antwort eines Backends. Ergänze sie deshalb mit Tests des signierten Artefakts, offiziellen Store-Angaben und einem klaren Freigabeprotokoll.
1. Berechtigungsinventar erstellen
Ordne jede iOS-Usage-Description und Android-Permission einer realen Funktion, einem SDK und einem Datenzweck zu.
Behandle berechtigungsinventar erstellen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für berechtigungsinventar erstellen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
2. Zugriff minimieren
Nutze Photo Picker, System-Intents, ungefähren Standort oder manuelle Eingabe, wenn die Funktion damit ohne breiten Zugriff funktioniert.
Behandle zugriff minimieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für zugriff minimieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
3. Purpose Strings konkret schreiben
Erkläre in Nutzersprache welche Funktion den Zugriff benötigt und was unmittelbar danach geschieht; generische Texte schaffen kein Vertrauen.
Behandle purpose strings konkret schreiben als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für purpose strings konkret schreiben eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
4. Im Nutzungskontext fragen
Fordere die Berechtigung erst an, wenn der Nutzer die Funktion startet, und erkläre ungewöhnliche Gründe vor dem Systemdialog.
Behandle im nutzungskontext fragen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für im nutzungskontext fragen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
5. Ablehnung respektieren
Die App darf nicht abstürzen oder den gesamten Kernfluss sperren; biete verständlichen Fallback und einen Weg zu Einstellungen, wenn nötig.
Behandle ablehnung respektieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für ablehnung respektieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
6. Framework-Konfiguration abgleichen
Expo-Plugins, React-Native-Pakete, Flutter-Plugins und native Dateien können Rechte automatisch ergänzen oder Texte überschreiben.
Behandle framework-konfiguration abgleichen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für framework-konfiguration abgleichen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
7. Datenschutzangaben synchronisieren
Berechtigung, tatsächliche Datenerhebung, Datenschutzerklärung, App Privacy und Data Safety müssen dieselbe Praxis beschreiben.
Behandle datenschutzangaben synchronisieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für datenschutzangaben synchronisieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
8. Release-Build auf echten Geräten testen
Teste Erstabfrage, Ablehnung, erneute Anfrage, dauerhaft verweigerte Rechte, eingeschränkte Auswahl und Upgrade von älteren Installationen.
Behandle release-build auf echten geräten testen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für release-build auf echten geräten testen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
Häufige Fragen
Braucht jede deklarierte iOS-Berechtigung einen Purpose String?
Geschützte Ressourcen verlangen die passende Usage Description. Fehlt sie, kann der Zugriff scheitern; unklare Texte erhöhen zudem das Review-Risiko.
Sollte ich alle Rechte beim Onboarding fragen?
Nein. Frage möglichst im Kontext der Funktion und nur nach dem notwendigen Zugriff.
Kann ein Plugin unnötige Rechte hinzufügen?
Ja. Prüfe die resultierende native Konfiguration und entferne oder blockiere nicht benötigte Rechte.
Erkennt LaunchLint das tatsächliche Zugriffsmoment?
Nicht vollständig. Statische Dateien zeigen Konfiguration und Aufrufe; Timing und UX brauchen einen Laufzeittest.