LaunchLint Academy
Die kurze Antwort
- React Native und Expo sind keine eigenen Ablehnungsgründe. Risiken entstehen an den Übergängen zwischen JavaScript, nativer Konfiguration, Backend, Store-Metadaten und dem Weg, den ein Prüfer tatsächlich testen kann.
- Die häufigsten prüfbaren Gruppen sind unvollständige Apps nach Guideline 2.1, ungenaue Metadaten nach 2.3, falsche Zahlungswege nach 3.1, zu wenig eigenständiger Produktwert nach 4.2 sowie Datenschutz- und Account-Löschprobleme nach 5.1.
- Arbeite nicht nur die zitierte Guideline ab. Reproduziere den konkreten Review-Weg im eingereichten Produktionsbuild, korrigiere die Ursache und antworte mit überprüfbarer Nachweis statt mit einer allgemeinen Zusicherung.
1. Warum React Native fast nie die eigentliche Ursache ist
Apple bewertet das ausgelieferte Produkt, seine Metadaten und das beobachtbare Verhalten. Ob eine Oberfläche mit SwiftUI, React Native oder Expo gebaut wurde, ändert diese Prüfung nicht. Relevant wird das Framework dort, wo Abstraktionen native Details verdecken: ein Config Plugin ergänzt eine Permission, ein SDK sendet Daten, eine dynamische app.config setzt im Release andere Werte oder ein OTA-Update passt nicht zum eingereichten Binary.
Ordne eine Ablehnung deshalb zuerst der betroffenen Ebene zu. Ein Crash beim Login ist ein Binary- oder Backend-Problem. Ein nicht erreichbarer Kauf kann Produktkonfiguration oder Testzugang für das Prüfteam betreffen. Eine falsche Datenschutzantwort liegt in der Store-Konsole, kann aber durch ein eingebundenes SDK ausgelöst werden. Diese Trennung verhindert hektische Änderungen an der falschen Stelle.
| Ebene | Typische Nachweis | Erste Frage |
|---|---|---|
| Projektdateien und Build | Config Plugins, Permissions, SDKs, Bundle-Werte | Ist das Signal im eingereichten Artefakt? |
| Laufende App | Crash, Login, Kauf, Löschung, Berechtigungsdialog | Kann ein frischer Prüfer den Flow reproduzieren? |
| Store-Kontext | Screenshots, Privacy-Antworten, Hinweise für das Prüfteam, Produkte | Beschreiben die Angaben exakt diesen Build? |
2. Guideline 2.1: unvollständiger Build oder blockierter Testzugang für das Prüfteam
Guideline 2.1 trifft nicht nur abstürzende Apps. Apple erwartet einen finalen Build, vollständige Metadaten, funktionierende URLs und Zugang zu allen wesentlichen Funktionen. Häufig scheitern ansonsten stabile React-Native-Apps an einem abgelaufenen Testkonto, einem nicht erreichbaren Staging-Backend, einer Einmalcode-Anmeldung oder einem Feature Flag, das für das Review-Konto deaktiviert ist.
Vor dem Resubmit auf einem fremden Gerät prüfen:
- Erststart ohne gespeicherte Session
- Login mit exakt den hinterlegten Review-Daten
- Backend, Uploads und Medien im Review-Netz erreichbar
- Kernfunktion ohne interne Einladung testbar
- In-App Purchases sichtbar und aktuell
- Ablehnung von Kamera, Standort oder Push führt nicht in eine Sackgasse
- Support- und Privacy-URL öffnen öffentlich
3. Guideline 2.3: Store-Versprechen und App-Verhalten widersprechen sich
Apple nennt Beschreibung, Screenshots, Previews und Privacy-Angaben ausdrücklich als Metadaten, die die Kernerfahrung korrekt wiedergeben müssen. Ein häufiger Fehler entsteht, wenn Marketing-Screenshots aus einem neueren Branch stammen als das eingereichte Binary oder wenn ein geplanter Premium-Flow bereits beworben wird, im Review-Konto aber nicht erreichbar ist.
Vergleiche jede starke Behauptung mit einem reproduzierbaren Pfad. Aussagen wie vollständig anonym, offline, ohne Tracking oder KI-gestützt benötigen besondere Sorgfalt, weil SDKs, Netzwerkaufrufe oder eingeschränkte Funktionen die Aussage widerlegen können. Entferne interne Debug-Menüs, Platzhalter, Testpreise und andere Plattformlogos aus sichtbarer Store-Kommunikation.
Metadaten-Abgleich:
- Jeder Screenshot zeigt echte erreichbare UI
- Name und Untertitel versprechen keine fehlende Funktion
- Zusatzkäufe werden erkennbar erklärt
- What’s New nennt wesentliche Änderungen konkret
- Altersfreigabe passt zu Inhalten und UGC
- Datenschutzerklärung und Store-Label beschreiben dieselbe App-Version
4. Guideline 3.1: digitale Käufe, Restore und Review-Produkte
Für digitale Funktionen, Inhalte oder Abos ist der zulässige Zahlungsweg entscheidend. Ein Stripe-SDK oder Web-Checkout im Projekt ist nicht automatisch ein Verstoß; riskant wird es, wenn die iOS-App damit digitale In-App-Funktionalität freischaltet oder Nutzer in einem Storefront-Kontext auf einen unzulässigen externen Kaufweg lenkt. Regionale Ausnahmen und Entitlements müssen konkret geprüft werden.
Auch korrekt integrierte In-App Purchases können nach 2.1 scheitern, wenn Produkte nicht zur Review eingereicht, unsichtbar oder nicht testbar sind. Prüfe Laden, Kaufabbruch, erfolgreichen Kauf, Wiederherstellung, bereits aktives Abo und Neuinstallation. Beschreibe in den Hinweise für das Prüfteam, unter welchen Voraussetzungen ein Produkt erscheint.
- Produktstatus und Agreements in App Store Connect kontrollieren
- Testkonto erreicht Paywall ohne internen Schalter
- Restore Purchases ist sichtbar und funktioniert
- Preise und Laufzeit sind vor Abschluss klar
- Keine Produktionsgeheimnisse in App-Code oder Hinweise für das Prüfteam
- Sonderfälle und regionale Verfügbarkeit knapp dokumentieren
5. Guideline 4.2: zu wenig eigenständiger App-Wert
Guideline 4.2 betrifft Apps, die im Wesentlichen eine Website verpacken, nur Links oder Marketingmaterial zeigen oder keinen dauerhaften Nutzen bieten. Vibe-Coder trifft das besonders bei dünnen WebView-Hüllen und Template-Apps. Mehr native Buttons lösen das Problem nicht; Apple beurteilt die erlebbare Funktion und den spezifischen Nutzen.
Formuliere den wiederkehrenden Job der App in einem Satz und zeige, warum er auf dem Gerät sinnvoll ist. Offline-Zugriff, Kamera- oder Standort-Workflows, Benachrichtigungen, gerätespezifische Erfassung und eine durchdachte mobile Interaktion können Wert schaffen, müssen aber tatsächlich funktionieren. Erfinde für die Review keine Features, die nur dekorativ oder unfertig sind.
6. Guideline 5.1: Datenschutz, Permissions und Account-Löschung
Privacy-Probleme entstehen oft durch Abweichungen: Das Projekt enthält Analytics, Crash Reporting oder Auth-SDKs, die Datenschutzerklärung nennt sie nicht; ein Permission-Dialog erklärt nur die technische Ressource; App Privacy oder Data Safety behauptet keine Erhebung, obwohl Daten das Gerät verlassen. Drittanbieter-Code zählt zur Verantwortung des App-Anbieters.
Wenn die App Accounts erstellt, prüfe außerdem den vollständigen Löschweg. Apple erwartet, dass die Löschung innerhalb der App angestoßen werden kann. Ein bloßes Abmelden oder Deaktivieren genügt nicht. Erkläre notwendige Aufbewahrung, behandle aktive Abos bewusst und teste Bestätigung, Re-Authentifizierung sowie Fehlerzustände.
Nachweis für den Fix:
- Konkreter Purpose String je sensibler Permission
- SDK-Inventar mit Datentyp, Zweck und Empfänger
- Öffentliche Datenschutzerklärung mit Aufbewahrung und Löschung
- In-App-Pfad zur Account-Löschung
- Store-Antworten gegen tatsächliche Übertragung geprüft
- Neues Binary erstellt, wenn native Konfiguration geändert wurde
7. Von der Ablehnung zu einem belastbaren Resubmit
Lies zuerst die genaue Guideline, den beschriebenen Testweg und alle Anhänge. Reproduziere denselben Weg mit dem abgelehnten Build, bevor du Code änderst. Danach entscheide, ob ein neues Binary nötig ist oder ob ein reines Metadatenproblem im selben Build korrigiert werden kann. Apple erlaubt bei Metadatenproblemen ausdrücklich einen Resubmit des bestehenden Builds.
Eine gute Antwort nennt die Ursache, die konkrete Änderung und den Ort der Überprüfung. Beispiel: ‚Wir haben den abgelaufenen Demo-Account ersetzt. Unter Konto > Demo-Projekte ist der Export nun ohne Einladung erreichbar; getestet in Build 42.‘ Vermeide Diskussionen über das Framework und Aussagen wie ‚alles funktioniert jetzt‘ ohne Pfad oder Build-Bezug.
Resubmit-Protokoll:
- Guideline und Prüfer-Schritte notieren
- Problem im abgelehnten Build reproduzieren
- Ursache einer Nachweisebene zuordnen
- Fix und Regressionstest dokumentieren
- Build-Nummer und betroffenen Pfad nennen
- Kurze sachliche Antwort mit optionalem Screenshot senden
- Nur dann Appeal nutzen, wenn die Auslegung der Store-Regel sachlich strittig bleibt
Häufige Fragen
Werden React-Native-Apps häufiger abgelehnt?
Apple veröffentlicht keine belastbare Ablehnungsquote nach Framework. React Native ist nicht der Ablehnungsgrund; relevant sind Stabilität, native Konfiguration, Metadaten, Zahlungen, Datenschutz und ein vollständig prüfbarer Flow.
Brauche ich nach jeder Ablehnung ein neues Binary?
Nein. Reine Metadatenprobleme können je nach Status mit demselben Build erneut eingereicht werden. Änderungen an Code, SDKs, Permissions oder nativer Konfiguration erfordern dagegen ein neues Binary mit höherer Build-Nummer.
Kann LaunchLint eine App-Store-Freigabe garantieren?
Nein. Ein statische Prüfung kann reproduzierbare Hinweise in den Projektdateien und Fragen zu Store-Regeln finden, aber weder Backend noch menschliche Review-Entscheidungen vollständig beurteilen. Er reduziert Risiken und erzeugt prüfbare Fix-Aufgaben.
Wie antworte ich auf eine unklare Ablehnung?
Bitte über App Store Connect um den konkreten Testweg, reproduziere den genannten Zustand und antworte mit Build, Navigation und Nachweis. Bleibt die Richtlinienauslegung strittig, steht zusätzlich der formale Appeal-Prozess offen.