App Store Review Guidelines: Häufige Ablehnungsgründe für React Native Apps

1. Warum React Native Apps oft an denselben Guidelines scheitern

Die App Store Review Guidelines gelten für jede App gleichermaßen, unabhängig vom verwendeten Framework. Trotzdem tauchen bei React Native und Expo Projekten immer wieder dieselben Ablehnungsgründe auf, weil bestimmte Muster im Cross-Platform-Umfeld häufiger vorkommen als bei rein nativen Apps: unvollständige Übersetzung von UI-Komponenten in native Bedienelemente, fehlende Berücksichtigung von Drittanbieter-SDKs bei Datenschutzangaben, oder eine Architektur, die aus Reviewer-Sicht wie eine reine WebView wirkt.

Wer die App Store Review Guidelines als Checkliste behandelt, die erst kurz vor der Einreichung durchgegangen wird, verliert wertvolle Zeit durch Ablehnungen, die sich mit etwas Vorlaufzeit leicht hätten vermeiden lassen. Die folgenden Abschnitte gehen die für React Native Teams relevantesten Guidelines im Detail durch und zeigen konkret, welche Ablehnungsgründe dahinterstehen und wie man ihnen vorbeugt.

2. Guideline 2.1: App Completeness - Crashes und Platzhalter

Guideline 2.1 App Completeness ist einer der häufigsten Ablehnungsgründe in den App Store Review Guidelines und betrifft Apps, die auf den Testgeräten des Reviewers abstürzen, Platzhalterinhalte wie Lorem-Ipsum-Text zeigen oder Funktionen enthalten, die im aktuellen Build sichtbar, aber nicht nutzbar sind. Für React Native Apps sind Crashes beim Kaltstart auf älteren iOS-Versionen ein besonders häufiger Auslöser, weil sich viele Entwicklerteams primär auf den neuesten Geräten testen und ältere Reviewer-Testgeräte übersehen.

Ein zweiter Auslöser unter Guideline 2.1 sind Login-Flows ohne funktionierenden Demo-Zugang: Verlangt eine App eine Anmeldung, muss in den App-Review-Notizen ein funktionierendes Test-Konto hinterlegt werden, da Reviewer sich nicht selbst registrieren können oder dürfen. Fehlt dieser Zugang oder funktioniert er nicht, wird die App unabhängig von ihrer sonstigen Qualität als unvollständig abgelehnt - ein Ablehnungsgrund, der sich mit einer sorgfältig gepflegten Demo-Umgebung vollständig vermeiden lässt.

{
  "app_review_notes": "Demo account for review: demo@example.com / Demo1234! - This account has pre-populated sample data and does not require email verification.",
  "attachment": "screen-recording-of-core-flow.mp4"
}

3. Guideline 2.3.1: Genaue Metadaten und Screenshots

Guideline 2.3.1 verlangt, dass Screenshots, Beschreibung und Vorschauvideo exakt widerspiegeln, was die App tatsächlich tut. Dieser Ablehnungsgrund tritt bei React Native Apps oft dann auf, wenn Screenshots aus einer älteren Version stammen oder Funktionen zeigen, die erst in einem zukünftigen Release aktiv werden. Die App Store Review Guidelines unterscheiden hier nicht zwischen Absicht und Versehen - ausschlaggebend ist allein, ob die Darstellung zum eingereichten Build passt.

Besonders bei Apps mit Feature-Flags oder serverseitig gesteuerten Funktionen entsteht dieser Ablehnungsgrund unbeabsichtigt: Ein Reviewer sieht eine Funktion in den Marketing-Screenshots, die für den eigenen Account (noch) nicht freigeschaltet ist, weil das Feature-Flag serverseitig deaktiviert ist. Für React Native Teams empfiehlt es sich, Screenshots direkt aus dem eingereichten Build zu generieren und in den App-Review-Notizen zu erklären, falls bestimmte Funktionen serverseitig gesteuert werden.

4. Guideline 4.2: Minimum Functionality und der Web-Wrapper-Verdacht

Guideline 4.2 Minimum Functionality ist für React Native und insbesondere für Expo-Projekte mit starker WebView-Nutzung einer der sensibelsten Ablehnungsgründe. Apple lehnt Apps ab, die "im Wesentlichen eine Website in einer App-Hülle" sind, ohne native Funktionalität zu bieten, die über das hinausgeht, was eine mobile Webseite ebenfalls leisten könnte. Da React Native Apps aus nativem Code kompiliert werden, greift diese Guideline eigentlich selten zu Unrecht - trifft aber Apps, die primär eine WebView einbetten und kaum native Features wie Kamera, Push Notifications oder Offline-Funktionalität nutzen.

Um diesen Ablehnungsgrund zu vermeiden, sollte eine App aktiv nachweisen, dass sie genuine native Plattform-Integration bietet: Push Notifications, native Navigation statt einer eingebetteten Webseite, Zugriff auf Gerätefunktionen wie Kamera oder Standort, und ein UI, das sich an native Bedienmuster hält statt an ein responsives Webdesign. In den App-Review-Notizen kann es zusätzlich helfen, explizit zu erläutern, welche nativen Module und Capabilities die App gegenüber einer reinen Webseite bietet.

5. Guideline 5.1.1: Datenschutz, Privacy Manifest und ATT

Guideline 5.1.1 Data Collection and Storage ist in den letzten Jahren zu einem der technisch anspruchsvollsten Ablehnungsgründe geworden, seit Apple das Privacy Manifest (`PrivacyInfo.xcprivacy`) für bestimmte Drittanbieter-SDKs verpflichtend gemacht hat. Für React Native Apps bedeutet das: Jede eingebundene native Bibliothek, die zu den von Apple gelisteten "commonly used third-party SDKs" gehört, muss ein eigenes Privacy Manifest mitliefern - fehlt dieses, weist App Store Connect den Build bereits vor der eigentlichen Reviewer-Prüfung zurück.

Zusätzlich verlangt Guideline 5.1.1 einen App Tracking Transparency (ATT) Prompt, sobald eine App Werbe-IDs oder Nutzerdaten geräteübergreifend zu Tracking-Zwecken verwendet. Ein häufiger Ablehnungsgrund entsteht, wenn ein Analytics- oder Werbe-SDK in einer React Native App Tracking-Funktionalität mitbringt, das Team dies aber übersieht, weil es im eigenen JavaScript-Code nicht sichtbar ist. Eine vollständige Prüfung aller nativen Abhängigkeiten auf Privacy-Manifest-Pflicht und Tracking-Verhalten vor jeder Einreichung ist daher unverzichtbar.

{
  "NSPrivacyTracking": true,
  "NSPrivacyTrackingDomains": ["analytics.example.com"],
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypeDeviceID",
      "NSPrivacyCollectedDataTypeLinked": true,
      "NSPrivacyCollectedDataTypeTracking": true,
      "NSPrivacyCollectedDataTypePurposes": ["NSPrivacyCollectedDataTypePurposeThirdPartyAdvertising"]
    }
  ]
}

// Request App Tracking Transparency before using any advertising
// identifier - required whenever a bundled SDK tracks across apps
import AppTrackingTransparency

func requestTrackingIfNeeded() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            print("Tracking authorized, IDFA available")
        case .denied, .restricted, .notDetermined:
            print("Tracking not authorized, fall back to contextual ads")
        @unknown default:
            break
        }
    }
}

6. Guideline 3.1.1: In-App Purchase bei digitalen Gütern

Guideline 3.1.1 In-App Purchase verlangt, dass digitale Inhalte und Funktionen, die innerhalb der App freigeschaltet werden, ausschließlich über Apples In-App-Purchase-System abgewickelt werden. Ein häufiger Ablehnungsgrund bei React Native Apps mit Abo-Modellen ist ein Link zu einer externen Zahlungsseite im Browser, um Apples 30-prozentige Provision zu umgehen - dieses Muster wird von Apple aktiv gesucht und konsequent abgelehnt, auch wenn der Link nur dezent platziert ist.

Physische Güter und Dienstleistungen außerhalb der App sind von dieser Regel ausgenommen, was in der Praxis oft zu Unsicherheit führt: Eine React Native App, die sowohl physische Produkte verkauft als auch digitale Premium-Funktionen anbietet, muss beide Zahlungswege sauber trennen. Bibliotheken wie `react-native-iap` kapseln die native StoreKit-Integration, ersetzen aber nicht die inhaltliche Prüfung, welche Funktionen überhaupt über In-App Purchase abgewickelt werden müssen, um diesen Ablehnungsgrund zu vermeiden.

// Never link external payment for digital goods in a review build,
// even behind a feature flag - reviewers actively look for this
function SubscriptionScreen() {
  const handlePurchase = async () => {
    // Correct: route through native StoreKit / Play Billing
    await requestSubscription('premium_monthly');
    // Wrong: Linking.openURL('https://example.com/checkout')
  };
  return <PurchaseButton onPress={handlePurchase} />;
}

7. Human Interface Guidelines: Native UI-Patterns korrekt umsetzen

Auch wenn Human Interface Guidelines (HIG) Verstöße seltener zu einer harten Ablehnung führen als die zuvor genannten Guidelines, tauchen sie regelmäßig als sekundärer Ablehnungsgrund in Kombination mit anderen Problemen auf. Typische Muster bei React Native Apps sind eigene, nicht-native Navigationsleisten, die sich optisch stark von iOS-Standardkomponenten unterscheiden, oder Gesten, die etablierte System-Gesten wie das Zurückwischen vom Bildschirmrand überschreiben.

Für React Native Teams lohnt es sich, Bibliotheken zu verwenden, die native Navigationskomponenten kapseln, statt eigene UI-Elemente von Grund auf nachzubauen. Das reduziert nicht nur das Risiko HIG-bezogener Ablehnungsgründe, sondern verbessert auch die tatsächliche Nutzererfahrung, da native Komponenten Barrierefreiheits-Features wie VoiceOver automatisch mitbringen, die bei komplett selbst gebauten UI-Elementen oft nachträglich implementiert werden müssen.

8. Resolution Center und Appeal-Prozess

Wird eine App trotz sorgfältiger Vorbereitung abgelehnt, ist das Resolution Center in App Store Connect der zentrale Kommunikationskanal mit dem Reviewer. Hier lässt sich klären, ob eine Ablehnung auf einem Missverständnis beruht - etwa wenn der Reviewer eine Funktion nicht gefunden hat, die tatsächlich vorhanden ist - oder ob eine echte Anpassung nötig ist. Die App Store Review Guidelines sehen ausdrücklich vor, dass Entwickler zusätzliche Erklärungen und Bildschirmaufnahmen nachreichen können, bevor ein Build komplett neu eingereicht werden muss.

Erscheint eine Ablehnung inhaltlich falsch, etwa weil eine Guideline offensichtlich fehlinterpretiert wurde, steht zusätzlich der offizielle App Review Board Appeal-Prozess zur Verfügung, der unabhängig vom ursprünglichen Reviewer entscheidet. Dieser Weg sollte jedoch nur für tatsächlich strittige Fälle genutzt werden - bei klaren Ablehnungsgründen wie fehlendem Privacy Manifest oder Web-Wrapper-Verdacht ist eine direkte Behebung des Problems meist schneller als ein Appeal-Verfahren.

#!/usr/bin/env bash
# Pre-submission checklist for App Store review, run before every upload
set -euo pipefail

echo "Checking for expired provisioning profiles..."
eas credentials --platform ios --non-interactive || true

echo "Checking PrivacyInfo.xcprivacy exists for known third-party SDKs..."
find ios -name "PrivacyInfo.xcprivacy" -print

echo "Checking for hardcoded external payment links..."
grep -R "checkout" src/ || echo "No external checkout links found"

echo "Reminder: verify demo account credentials are still valid."

9. Häufige Ablehnungsgründe im Überblick

Die folgende Übersicht fasst die in diesem Artikel behandelten App Store Review Guidelines und ihre typischen Auslöser zusammen, damit sie sich vor jeder Einreichung als Checkliste nutzen lässt.

Diese fünf App Store Review Guidelines decken den Großteil aller React-Native-spezifischen Ablehnungsgründe ab. Wer sie systematisch vor jeder Einreichung prüft, statt erst nach einer Ablehnung zu reagieren, reduziert die durchschnittliche Zeit bis zur erfolgreichen Veröffentlichung erheblich.

10. Zusammenfassung

Die App Store Review Guidelines bestrafen bei React Native Apps meist dieselben wenigen strukturellen Schwächen: unvollständige Builds ohne funktionierenden Demo-Zugang, veraltete Screenshots, eine zu web-lastige Architektur ohne genuine native Integration, fehlende Privacy Manifests für Drittanbieter-SDKs und externe Zahlungswege für digitale Güter. Jeder dieser Ablehnungsgründe lässt sich mit einem systematischen Pre-Submission-Check zuverlässig vermeiden.

Der entscheidende Unterschied zwischen Teams mit häufigen Ablehnungen und Teams mit reibungslosen Releases liegt selten am technischen Können, sondern daran, ob die App Store Review Guidelines als fester Bestandteil des Release-Prozesses behandelt werden oder erst nach der ersten Ablehnung überhaupt gelesen werden. Wer Privacy Manifests, Demo-Zugänge und native Integrationsnachweise von Anfang an mitdenkt, reduziert die Anzahl der Review-Zyklen spürbar.

11. FAQ: App Store Review Guidelines für React Native Apps