LaunchLint Academy
Die kurze Antwort
- EAS Submit lädt eine fertige App-Datei zu Apple oder Google hoch. Es vervollständigt nicht automatisch deine Store-Texte, Datenschutzangaben, Screenshots oder Hinweise für das Prüfteam.
- Prüfe vor dem Erstellen der App-Datei Identität, Versionswerte, Erweiterungen und native Berechtigungen. Teste danach die Produktionsversion auf echten Geräten und gleiche den beobachteten Ablauf mit App Store Connect und der Play Console ab.
- Behandle Kontolöschung, Testzugang für das Prüfteam, Käufe und die Datenverarbeitung eingebundener Dienste als Teil der Veröffentlichung. Ein erfolgreicher technischer Build bedeutet noch keine Store-Freigabe.
1. Was EAS Submit erledigt – und was nicht
EAS Submit überträgt eine fertige iOS- oder Android-App-Datei an den jeweiligen Store. Für iOS landet sie in App Store Connect beziehungsweise TestFlight, für Android im gewählten Test- oder Veröffentlichungskanal. Das spart manuelle Upload-Schritte. Apple und Google prüfen anschließend trotzdem die App-Datei, Store-Angaben und Hinweise für ihr Prüfteam.
Der häufigste Denkfehler lautet: Wenn EAS Build und EAS Submit erfolgreich durchlaufen, ist die App einreichungsbereit. Bewiesen ist dann nur, dass eine App-Datei erstellt und übertragen werden konnte. Ein vollständiger Anmeldeablauf, korrekte Store-Angaben, verständliche Berechtigungstexte, funktionierende Käufe sowie erreichbare Datenschutz- und Support-Seiten müssen weiterhin geprüft werden.
Nach EAS Submit bleiben mindestens diese Aufgaben offen:
- Store-Eintrag, Kategorie, Altersfreigabe und Verfügbarkeit pflegen
- Screenshots und Beschreibung mit der aktuellen Produktionsversion vergleichen
- App Privacy beziehungsweise Data Safety vollständig beantworten
- Kontakt, Testkonto und besondere Prüfschritte für das Prüfteam eintragen
- In-App-Käufe oder Abonnements sichtbar und prüfbar machen
- Die App in App Store Connect beziehungsweise der Play Console tatsächlich zur Prüfung senden
2. App-Identität und Versionswerte vor dem Produktionsbuild fixieren
Bundle Identifier und Android Package Name sind keine kosmetischen Werte. Sie verbinden den Build mit dem Store-Eintrag, Signierung, Push-Konfigurationen und häufig auch OAuth-Redirects. Prüfe sie deshalb vor dem ersten produktiven Upload. Ein versehentlich veröffentlichtes Package lässt sich später nicht wie ein sichtbarer App-Name beliebig umbenennen.
Halte außerdem sichtbare Versionsnummer und technische Build-Nummer auseinander. Für jede erneut hochgeladene iOS-Version muss die Build Number steigen; auf Android übernimmt versionCode diese Rolle. Prüfe bei dynamischer app.config zusätzlich, welche Werte im Produktionsprofil tatsächlich verwendet werden. Eine lokale Entwicklungskonfiguration ist kein belastbarer Nachweis für die Produktionsversion.
{
"expo": {
"name": "My Production App",
"slug": "my-production-app",
"version": "1.0.0",
"ios": {
"bundleIdentifier": "com.example.myapp",
"buildNumber": "1"
},
"android": {
"package": "com.example.myapp",
"versionCode": 1
}
}
}Kontrollfragen:
- Sind Bundle Identifier und Package Name exakt den Store-Einträgen zugeordnet?
- Steigen buildNumber und versionCode bei jedem neuen Binary?
- Verwendet das Produktionsprofil die richtigen API-, OAuth- und Deep-Link-Domains?
- Sind Icon, Splash Screen und sichtbarer App-Name final statt Platzhalter?
- Ist klar, welche Werte aus Environment Variables oder app.config kommen?
3. Berechtigungen vom tatsächlichen Nutzer-Flow her erklären
Expo-Bibliotheken können native Berechtigungen über Config Plugins oder eingebettete Android-Manifeste hinzufügen. Deshalb reicht es nicht, nur nach selbst eingetragenen Permissions zu suchen. Inventarisiere die installierten Bibliotheken, prüfe die resultierende Konfiguration und entferne Berechtigungen, die der Produktionsflow nicht benötigt.
Auf iOS müssen Purpose Strings konkret erklären, welche Funktion die Daten benötigt. Ein Text wie ‚Diese App benötigt Zugriff auf die Kamera‘ wiederholt nur den Dialog. Besser ist die überprüfbare Funktion: ‚Nutze die Kamera, um den QR-Code auf deinem Veranstaltungsticket zu scannen.‘ Laut Expo werden Info.plist-Änderungen mit einem neuen nativen Binary ausgeliefert; ein OTA-Update genügt dafür nicht.
{
"expo": {
"ios": {
"infoPlist": {
"NSCameraUsageDescription":
"Use the camera to scan the QR code on an event ticket."
}
},
"android": {
"blockedPermissions": [
"android.permission.RECORD_AUDIO"
]
}
}
}Teste für jede sensible Berechtigung:
- Der Dialog erscheint erst, wenn die Funktion ihn nachvollziehbar benötigt
- Ablehnen führt nicht in einen kaputten oder leeren Bildschirm
- Die Erklärung nennt Zweck und Nutzerwert statt nur die technische Ressource
- Eine spätere Aktivierung über Systemeinstellungen ist verständlich erreichbar
- Nicht verwendete Berechtigungen werden aus der nativen Konfiguration entfernt
4. Projektdateien, App-Verhalten und Datenschutzangaben abgleichen
package.json zeigt, welche externen Bibliotheken und Dienste wahrscheinlich im Projekt verwendet werden. Daraus lassen sich Risikofragen ableiten, aber noch keine vollständige Datenschutzerklärung. Analyse-, Fehlerprotokoll-, Anmelde- oder Zahlungsdienste können Daten übertragen. Ob, wann, zu welchem Zweck und mit welcher Verarbeitung im Hintergrund, ergibt sich erst aus Konfiguration und tatsächlichem Verhalten.
| Ebene | Nützliche Nachweise | Reicht allein? |
|---|---|---|
| Projektdateien | Eingebundene Dienste, Berechtigungen, Erweiterungen und Internetadressen | Nein – zeigt Signale, nicht jeden Datenfluss |
| Laufende App | Zeitpunkt, Einwilligung, optionale Nutzung und tatsächliche Übertragung | Nein – Server und Drittanbieter bleiben zu prüfen |
| Store-Konsole | Angegebene Datentypen, Zwecke, Weitergabe und Löschung | Nein – Angaben müssen mit App und eingebundenen Diensten übereinstimmen |
Google erklärt ausdrücklich, dass auch durch Drittanbieter-Bibliotheken und eingebundene Dienste übertragene Nutzerdaten in Data Safety gehören und der Entwickler für vollständige Angaben verantwortlich bleibt. Erstelle daher pro Dienst einen kleinen Datensteckbrief: Datentyp, Empfänger, Zweck, erforderliche oder optionale Nutzung, Aufbewahrung und Löschweg. Gleiche ihn mit Datenschutzerklärung, App Privacy und Data Safety ab.
5. Testzugang und Kontolöschung wie ein fremder Prüfer testen
Wenn Kernfunktionen hinter Anmeldung, Einladung, Rolle, Region oder Abo liegen, braucht das Prüfteam einen stabilen Weg dorthin. Apple nennt dafür ein aktives Demo-Konto oder einen voll funktionsfähigen Demo-Modus. Das Konto sollte nicht an persönliche Daten, ein Mitarbeitertelefon oder kurzlebige Einmalcodes gebunden sein.
Belastbare Angaben für das Prüfteam enthalten:
- Testkonto mit dauerhaft erreichbarem Server
- Kurze Schritte vom App-Start bis zur geschützten Kernfunktion
- Erklärung spezieller Rollen, QR-Codes, Hardware oder Standortvoraussetzungen
- Test- oder Demo-Zustand für Käufe und Abonnements
- Erreichbaren Kontakt, der während der Prüfphase antworten kann
Account-Löschung ist ein eigener Prüfpfad. Bei Apple muss eine App, die Account-Erstellung unterstützt, die Löschung innerhalb der App anstoßen können. Google verlangt bei Apps mit Account-Erstellung zusätzlich zum In-App-Weg eine Web-Ressource für Löschanfragen. Teste nicht nur den Button, sondern Bestätigung, Re-Authentifizierung, abhängige Daten, aktive Abos und die Erklärung eventuell gesetzlich notwendiger Aufbewahrung.
6. Screenshots, Claims und digitale Käufe gegen den Build prüfen
Store-Metadaten sind Teil der Prüfung. Entferne Aussagen über Funktionen, die im eingereichten Build fehlen, nur für interne Tester aktiv sind oder erst später freigeschaltet werden. Screenshots sollten den aktuellen Flow zeigen und keine UI versprechen, die der Reviewer nicht erreichen kann. Kontrolliere außerdem Support- und Privacy-URLs ohne Login und auf einem mobilen Browser.
Bei digitalen Inhalten müssen Produkte sichtbar, aktuell und in der Prüfversion funktionsfähig sein. Wenn ein Kauf nur unter bestimmten Bedingungen erscheint, beschreibe diese in den Hinweisen für das Prüfteam. Prüfe die Wiederherstellung früherer Käufe, fehlgeschlagene Käufe, bereits aktive Abos und den Zustand nach einer Neuinstallation. Eine eingebaute Zahlungsbibliothek beweist nicht, dass diese Randfälle korrekt umgesetzt sind.
Letzter Abgleich der Store-Angaben:
- App-Name, Untertitel und Beschreibung passen zum aktuellen Funktionsumfang
- Screenshots zeigen reale, erreichbare Oberflächen
- Support- und Datenschutz-Link sind öffentlich über HTTPS erreichbar
- Alle beworbenen Käufe sind im Testkonto sichtbar
- Hinweise für das Prüfteam erklären Sonderfälle knapp und ohne Marketingtext
- Keine Platzhaltertexte oder internen Debug-Hinweise sind sichtbar
7. Die Abschlussprüfung 24 Stunden vor der Einreichung
Plane eine kurze Änderungspause statt zwischen letzter Funktionsänderung und Einreichung zu improvisieren. Erzeuge die Produktionsversion aus dem vorgesehenen Entwicklungsstand, notiere ihre Kennung und prüfe genau diese App-Datei. Änderungen an nativer Konfiguration, Berechtigungen oder eingebundenen Diensten nach dem Test erfordern eine neue Version und eine erneute gezielte Prüfung.
Empfohlene Reihenfolge:
- Entwicklungsstand und Produktionskonfiguration festhalten
- iOS- und Android-Version auf mindestens je einem echten Gerät installieren
- Erststart, Anmeldung, abgelehnte Berechtigung, Kernfunktion, Kauf und Kontolöschung testen
- Eingebundene Dienste mit Datenschutzerklärung, App Privacy und Data Safety abgleichen
- Screenshots, Beschreibung, Links und Hinweise für das Prüfteam final lesen
- Testkonto auf einem fremden Gerät prüfen
- App-Datei hochladen, Verarbeitungsfehler prüfen und erst dann zur Store-Prüfung senden
Speichere die Ergebnisse als kurze Nachweisliste. Das muss kein schweres Compliance-Dokument sein: Versionskennung, geprüfter Ablauf, erwartetes Ergebnis, tatsächliches Ergebnis und verantwortliche Person genügen. Bei einer Ablehnung kannst du so schneller unterscheiden, ob das Problem in der App-Datei, in den Store-Angaben oder in der Kommunikation liegt.
8. Was eine statische Prüfung der Projektdateien beitragen kann
Eine statische Prüfung kann App-Kennungen, Signale eingebundener Dienste, Konfigurationserweiterungen, Begründungstexte für Berechtigungen sowie Hinweise auf Anmeldung, Käufe oder Tracking reproduzierbar finden. Gute Risikohinweise nennen die konkrete Datei und erklären, welche Frage von Apple oder Google dadurch wichtig wird.
Nicht zuverlässig aus den Projektdateien ableitbar sind das Verhalten eines externen Servers, die Erreichbarkeit eines Testkontos, jede Interaktion in der laufenden App oder die vollständige Richtigkeit deiner Store-Formulare. LaunchLint führt fremden Code bewusst nicht aus. Die Prüfung fokussiert deine manuelle Kontrolle, ersetzt aber weder deine Verantwortung noch die Entscheidung des Stores.
Häufige Fragen vor der Einreichung mit Expo
Reicht ein erfolgreicher EAS-Build für die App-Store-Einreichung?
Nein. Er beweist nur, dass eine App-Datei erstellt wurde. Testzugang, Store-Angaben, Datenschutzangaben, Käufe und Abläufe auf echten Geräten müssen separat geprüft werden.
Kann ich iOS-Berechtigungstexte mit einem OTA-Update korrigieren?
Nein. Änderungen an Info.plist werden mit einer neuen nativen App-Version ausgeliefert. Plane nach einer Korrektur einen neuen Produktionsbuild ein.
Muss ein Testkonto echte Nutzerdaten enthalten?
Nein. Verwende ein dediziertes Demo-Konto ohne persönliche Daten und ohne kurzlebige Einmalcodes. Es muss die prüfbaren Kernfunktionen zuverlässig zugänglich machen.
Kann LaunchLint die Annahme im Store garantieren?
Nein. LaunchLint identifiziert wahrscheinliche Risiken und Nachweise in den Projektdateien. Die endgültige Bewertung bleibt bei Apple oder Google und umfasst auch das Verhalten der laufenden App sowie die Store-Angaben.