React Native App-Launch-Checkliste: von Tests bis Store-Freigabe

1. Was ein React Native App-Launch wirklich braucht

Eine React Native App-Launch-Checkliste ist kein einzelner Klick auf "Einreichen", sondern eine koordinierte Abfolge von finalen Regressionstests über die Store-Freigabe bis zu den ersten 48 Stunden in Produktion, in denen noch immer still etwas schiefgehen kann. Teams, die den Launch als Ereignis statt als Prozess behandeln, sind genau die, die von einem Crash-Anstieg drei Stunden nach Release oder einer Store-Ablehnung zwei Tage vor dem Marketing-Termin überrascht werden. Dieser Artikel behandelt die App-Launch-Checkliste als strukturierten Prozess: Testumfang, Crash-Monitoring, Performance-Profiling, Store-Compliance, Staged Rollout, Privacy-Erklärungen, finale Pre-Submission-Prüfung und die kritischen ersten Stunden nach dem Go-Live.

Als Abschlussartikel dieser Serie sei kurz erwähnt: Neben diesem Launch-Prozess gehört zu einer wirklich launch-reifen React Native App in der Regel auch ein konsistentes Design System für einheitliche UI über alle Screens hinweg, funktionierende In-App-Käufe beziehungsweise Subscription Commerce, sofern das Geschäftsmodell es verlangt, native Home-Screen-Widgets, falls das Produkt von OS-Level-Präsenz profitiert, und eine automatisierte CI/CD-Pipeline mit GitHub Actions und EAS, die Releases wiederholbar baut und signiert. Jedes dieser Themen ist eine eigene Disziplin und an anderer Stelle behandelt. Hier liegt der Fokus ausschließlich darauf, was zwischen "Feature complete" und "stabil live in Produktion" passiert.

2. Funktionale Tests und Regressionstests: die richtige Geräte-Matrix

Simulatoren lügen, zumindest in wichtigen Details. Der iOS Simulator und der Android Emulator laufen auf Desktop-CPU und -RAM ohne thermische Drosselung, ohne echtes GPS-Signal, ohne reale Kamera-Hardware und ohne echte Push-Zustellung über APNs oder FCM. Eine React Native App-Launch-Checkliste, die vor der Einreichung ausschließlich auf Simulatoren getestet wurde, hat effektiv genau die Bedingungen übersprungen, unter denen die meisten Nutzer die App tatsächlich betreiben. Konkret bedeutet das: mindestens zwei bis drei physische Geräte pro Plattform, gestaffelt nach High-End, Mid-Range und Low-End, bevor eine Einreichung zur Store-Freigabe überhaupt infrage kommt.

OS-Versions-Abdeckung ist der zweite Baustein der Geräte-Matrix. Sinnvoll ist, die letzten drei großen iOS-Versionen und die Android-API-Level abzudecken, die laut Store-Analytics rund 95 Prozent der aktiven Installationsbasis ausmachen. Wichtig dabei: explizit auf der ältesten noch unterstützten OS-Version testen, nicht nur auf der neuesten Beta, denn genau dort tauchen Layout-Brüche und veraltete API-Verhalten zuerst auf, die im Simulator mit der neuesten SDK-Version unsichtbar bleiben.

Low-End-Android-Performance-Tests sind der am häufigsten übersprungene Teil der Geräte-Matrix, gerade weil die Android-Fragmentierung so groß ist. Budget-Geräte mit 2 bis 3 GB RAM und schwächerer GPU zeigen JS-Thread-Blockaden, ruckelndes Listen-Scrollen und langsames Bild-Laden, die auf einem Flaggschiff-Testgerät nie auffallen würden. Ein Android-Go-Emulator-Profil oder ein reales Budget-Gerät aus der Samsung-A- oder Redmi-Reihe gehört deshalb fest in jede React Native App-Launch-Checkliste, nicht als optionaler Zusatztest.

3. Crash Reporting und Monitoring vor dem Launch

Wer Crash Reporting erst nach dem Launch einrichtet, bekommt die ersten echten Absturzdaten aus verärgerten Store-Bewertungen statt aus einem Dashboard, und zu diesem Zeitpunkt ist schnelles Nachbessern kaum noch möglich. Crash-Monitoring ist deshalb kein Post-Launch-Nice-to-have, sondern ein fester Bestandteil jeder ernsthaften App-Launch-Checkliste, der spätestens im letzten Testing-Zyklus vor der Einreichung produktiv laufen muss, nicht erst nach der Store-Freigabe.

In der Praxis bedeutet das ein SDK wie Sentry oder Bugsnag, das vor dem ersten produktiven Release integriert wird, inklusive hochgeladener Source Maps für jeden Build. Ohne Source Maps zeigt ein Crash-Report nur minifizierten JS-Code als Stack-Trace, was Debugging faktisch unmöglich macht. Breadcrumbs, also automatisch mitgeschriebene Navigationsereignisse, API-Aufrufe und Nutzerinteraktionen vor dem Absturz, verwandeln einen nackten Stack-Trace in eine nachvollziehbare Geschichte, die zeigt, was der Nutzer unmittelbar vor dem Crash getan hat.

// sentry.ts — crash reporting setup before the first production release
import * as Sentry from '@sentry/react-native';

Sentry.init({
  dsn: 'https://examplePublicKey@o0.ingest.sentry.io/0',
  release: `myapp@${process.env.APP_VERSION}+${process.env.BUILD_NUMBER}`,
  dist: process.env.BUILD_NUMBER,
  tracesSampleRate: 0.2,
  enableAutoSessionTracking: true,
  attachStacktrace: true,
});

// Manual breadcrumb: record the user's last relevant action
export function trackCheckoutStep(step: string) {
  Sentry.addBreadcrumb({
    category: 'checkout',
    message: `Checkout step reached: ${step}`,
    level: 'info',
  });
}

Der Release- und Dist-Tag im Init-Aufruf ist kein Detail, sondern entscheidet, ob Crash-Reports später pro Version gefiltert werden können. Ohne diese Zuordnung landen Crashes aus drei verschiedenen Builds unsortiert im selben Bucket, und ein Alarm für sinkende Crash-Free-Rate lässt sich nicht sauber an eine konkrete Store-Freigabe koppeln.

4. Performance-Profiling: Startzeit, JS-Thread-FPS und Bundle-Größe

Die Startzeit, gemessen als Time to Interactive, prägt die erste Wahrnehmung einer App stärker als fast jede andere Metrik. Nutzer, die auf einen leeren oder ewig ladenden Splash-Screen starren, brechen ab oder deinstallieren, lange bevor sie das eigentliche Produkt gesehen haben. Eine App-Launch-Checkliste ohne dokumentierte Startzeit-Messung überspringt damit genau die Metrik, die Store-Bewertungen und Abbruchraten am direktesten beeinflusst.

Für die JS-Thread-Framerate während Scrollen und Navigation liefern Flipper und der React DevTools Profiler die entscheidenden Zahlen: Fällt die FPS-Kurve während einer Listen-Interaktion regelmäßig unter 50, ist das ein verlässliches Signal für teure Re-Renders oder blockierende Berechnungen auf dem JS-Thread. Native Tools wie Xcode Instruments und der Android Studio Profiler ergänzen das um die native Seite, etwa Speicherverbrauch und GPU-Auslastung, die vom JS-Profiler allein nicht sichtbar werden.

Die Bundle-Größe ist der dritte Hebel: ein aufgeblähtes JS-Bundle verlängert nicht nur den Download, sondern auch die Zeit, die Hermes zum Parsen und Ausführen beim Start braucht. react-native-bundle-visualizer zeigt als interaktive Treemap, welche Pakete den meisten Platz im Bundle beanspruchen, häufig überraschend große, kaum genutzte Abhängigkeiten.

#!/usr/bin/env bash
set -euo pipefail

# Visualize what is actually bloating the production JS bundle
npx react-native-bundle-visualizer

# Generate the raw bundle and a size-only report for CI comparisons
npx react-native bundle \
  --platform android \
  --dev false \
  --entry-file index.js \
  --bundle-output /tmp/index.android.bundle \
  --sourcemap-output /tmp/index.android.bundle.map

du -h /tmp/index.android.bundle

5. App Store Review Guidelines und Play Store Richtlinien für React Native Apps

Seit iOS 17 verlangt Apple ein PrivacyInfo.xcprivacy-Manifest für Apps und für Drittanbieter-SDKs, die sogenannte "Required Reason APIs" nutzen, etwa UserDefaults, Speicherplatz-Abfragen oder aktive Tastatur-Erkennung. Viele native Module in einer React Native App lösen diese Anforderung aus, ohne dass es im jeweiligen Paket dokumentiert wäre, und eine fehlende oder unvollständige Privacy-Manifest-Deklaration führt inzwischen zu automatischen Ablehnungen bei der Store-Freigabe, noch bevor ein menschlicher Reviewer die App überhaupt öffnet.

{
  "NSPrivacyTracking": false,
  "NSPrivacyTrackingDomains": [],
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypeCrashData",
      "NSPrivacyCollectedDataTypeLinked": false,
      "NSPrivacyCollectedDataTypeTracking": false,
      "NSPrivacyCollectedDataTypePurposes": ["NSPrivacyCollectedDataTypePurposeAppFunctionality"]
    }
  ],
  "NSPrivacyAccessedAPITypes": [
    {
      "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
      "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
    }
  ]
}

Auf Android verlangt das Play-Console-Pendant, das Data Safety Form, eine ebenso präzise Selbstauskunft: welche Datentypen die App sammelt, ob sie geteilt werden und zu welchem Zweck. Eine App-Launch-Checkliste muss diese Deklaration gegen den tatsächlichen Code abgleichen, denn abweichende Angaben werden inzwischen aktiv über automatisierte Scans und Nutzerbeschwerden aufgedeckt und führen zur Sperrung bestehender Store-Einträge, nicht nur zur Ablehnung neuer Einreichungen.

<!-- AndroidManifest.xml — permissions must match the Data Safety form exactly -->
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

<application>
  <meta-data
    android:name="com.google.android.gms.permission.AD_ID"
    android:value="false" />
</application>

Permission-Usage-Strings wie NSCameraUsageDescription oder NSLocationWhenInUseUsageDescription müssen konkret erklären, wofür die App die Berechtigung tatsächlich braucht. Generische Formulierungen wie "Diese App benötigt Zugriff auf Ihre Kamera" führen regelmäßig zu Rückfragen im Review und verzögern die Store-Freigabe um Tage. Screenshots und Metadaten müssen zudem pro unterstütztem Store-Locale eigens erstellt werden, denn automatisch skalierte Standard-Screenshots ohne lokalisierten Text werden von Reviewern zunehmend beanstandet, besonders wenn die App selbst vollständig lokalisiert ist.

6. Staged Rollout: Blast Radius eines schlechten Release begrenzen

Ein kritischer Bug, der gleichzeitig an 100 Prozent der Nutzer ausgeliefert wird, verwandelt einen kleinen Codefehler sofort in einen Massen-Support-Vorfall. Ein Staged Rollout begrenzt genau diesen Blast Radius, indem ein neues Release zunächst nur einem kleinen Prozentsatz der Nutzerbasis zugänglich gemacht wird, bevor die restliche Basis folgt. Diese Strategie ist der Unterschied zwischen "fünf Prozent der Nutzer sehen einen Bug für eine Stunde" und "alle Nutzer sehen einen Bug, bis ein Hotfix durch den kompletten Review-Prozess ist".

Die Play Console bietet dafür einen prozentualen Rollout direkt in der Release-Verwaltung, typischerweise beginnend bei 5 bis 10 Prozent mit stufenweiser Erhöhung nach Beobachtungsfenstern von einigen Stunden. App Store Connect bietet mit Phased Release einen automatischen siebentägigen Rampen-Mechanismus, der sich jederzeit pausieren lässt, sobald die Crash-Free-Rate unter den definierten Schwellenwert fällt.

#!/usr/bin/env bash
set -euo pipefail

# Bump build number and start a conservative staged rollout on Play Console
VERSION_CODE=$(date +%Y%m%d%H)
sed -i "s/versionCode .*/versionCode ${VERSION_CODE}/" android/app/build.gradle

# Upload the release and start at a low rollout percentage
bundle exec fastlane supply \
  --track production \
  --rollout 0.10 \
  --aab android/app/build/outputs/bundle/release/app-release.aab

echo "[OK] Staged rollout started at 10% for versionCode ${VERSION_CODE}"

Entscheidend ist, den Rollout nicht als reinen Zeitplan zu behandeln, sondern an ein Monitoring-Gate zu koppeln: Erst wenn die Crash-Free-Rate der ausgelieferten Kohorte über einem definierten Schwellenwert bleibt, wird der nächste Prozentsatz freigegeben. Ohne diese Kopplung ist Staged Rollout nur eine verzögerte Vollverteilung, kein echter Sicherheitsmechanismus.

7. App Tracking Transparency und Privacy Nutrition Labels

App Tracking Transparency ist auf iOS verpflichtend, sobald eine App Nutzer über andere Apps oder Websites hinweg trackt, etwa über die IDFA für Attribution oder Werbenetzwerke. Timing und Formulierung des ATT-Prompts beeinflussen die Opt-in-Rate massiv: Ein Prompt direkt beim ersten App-Start ohne Kontext erzielt regelmäßig niedrigere Zustimmungsraten als einer, der nach einer kurzen Erklärung des Nutzens erscheint. Wichtig ist zudem, dass der Prompt tatsächlich vor dem ersten Tracking-Aufruf erscheint, nicht nur vor der SDK-Initialisierung, denn viele Analytics-SDKs sammeln bereits vor dem expliziten Tracking-Consent Basisdaten.

Die Privacy Nutrition Labels im App Store und das Data Safety Form bei Google müssen exakt widerspiegeln, was der Code tatsächlich tut, nicht was ursprünglich geplant war. Ein häufiger Fehler in einer React Native App-Launch-Checkliste: Ein Analytics-SDK wird während der Entwicklung eingebunden, aber nie in die Privacy-Deklaration übernommen, weil die Deklaration einmalig beim ersten Release ausgefüllt und danach nicht mehr aktualisiert wurde. Beide Stores prüfen diese Angaben inzwischen zunehmend automatisiert gegen das tatsächliche Netzwerkverhalten der App, und eine Abweichung gefährdet nicht nur die aktuelle Store-Freigabe, sondern den gesamten bestehenden Store-Eintrag.

8. Die finale Pre-Submission-Checkliste

Kurz vor der Einreichung entscheidet eine Handvoll unscheinbarer Details darüber, ob die Store-Freigabe reibungslos verläuft oder an einem vermeidbaren Detail scheitert. Version- und Build-Nummer müssen konsequent erhöht werden, denn beide Stores lehnen doppelte Build-Nummern automatisch ab, was besonders bei parallelen Feature-Branches passiert, wenn zwei Builds unabhängig voneinander dieselbe Nummer tragen. Ein Changelog beziehungsweise Release Notes sollten vor der Einreichung geschrieben werden, nicht danach unter Zeitdruck, da unvollständige Release Notes bei manchen Review-Teams selbst zu Rückfragen führen.

Deep Links und Universal Links müssen auf einem echten Gerät getestet werden, nicht nur im Simulator, da die Domain-Verifizierung über die apple-app-site-association-Datei und die Android App Links Assoziation reale DNS- und HTTPS-Anfragen benötigen, die viele Simulator-Umgebungen anders auflösen als ein physisches Gerät im Mobilfunknetz. Ebenso gehört eine Prüfung der Push-Notification-Zertifikate beziehungsweise des FCM-Server-Keys in jede App-Launch-Checkliste: Ein abgelaufenes APNs-Zertifikat fällt oft erst auf, wenn die erste Produktions-Push-Kampagne lautlos ins Leere läuft.

Als letztes Gate vor der Einreichung sollte eine Ziel-Crash-Free-Session-Rate definiert sein, etwa 99,5 Prozent über die letzte interne oder TestFlight-Testphase, bevor überhaupt zur öffentlichen Store-Freigabe eingereicht wird. Diese Kennzahl ist der objektivste Indikator dafür, ob ein Release tatsächlich stabil genug ist, unabhängig davon, wie gut sich der letzte manuelle Testdurchlauf angefühlt hat.

9. Die ersten 48 Stunden: Monitoring und Rollout im Vergleich

Der Launch endet nicht mit der Store-Freigabe, sondern beginnt dort erst richtig. In den ersten 24 bis 48 Stunden entscheidet sich, ob ein Release tatsächlich stabil ist oder ob ein selten getroffener Codepfad erst unter echter Nutzerlast bricht. Ein definierter Schwellenwert für die Crash-Free-Rate, etwa ein Alarm bei einem Abfall unter 99 Prozent, sollte in dieser Phase aktiv überwacht werden, idealerweise mit einer festen Bereitschaftsrotation, die auf einen solchen Alarm auch außerhalb der Bürozeiten reagieren kann.

Für den Fall, dass tatsächlich etwas kaputt ist, braucht jede App-Launch-Checkliste eine Rollback-Strategie, die schneller wirkt als ein erneuter Store-Review-Zyklus. Ein Remote-Feature-Flag-Dienst erlaubt, ein fehlerhaftes Feature serverseitig abzuschalten, ohne einen neuen Build einreichen zu müssen. Für rein JavaScript-seitige Fehler bietet EAS Update einen noch direkteren Weg: ein Hotfix-Bundle lässt sich innerhalb weniger Minuten an bereits installierte Apps ausliefern, komplett am App-Store-Review vorbei, solange keine nativen Code-Änderungen involviert sind.

Die Tabelle zeigt den klaren Trade-off: Staged Rollout kostet Zeit bis zur vollständigen Verteilung, kauft dafür aber genau die Reaktionszeit, die im Ernstfall über einen kontrollierten Vorfall oder eine eskalierte Support-Krise entscheidet. Für jede App mit relevanter Nutzerbasis ist dieser Zeitverlust ein günstiger Preis gegenüber dem Risiko eines unkontrollierten Vollausfalls.

10. Zusammenfassung

Diese Artikelserie hat React Native App-Entwicklung von mehreren Seiten beleuchtet, von der eigenen Komponenten-Bibliothek über Subscription Commerce und native Widgets bis zur CI/CD-Pipeline. All das läuft am Ende auf denselben Moment zu: den Launch. Eine solide React Native App-Launch-Checkliste ist der Rahmen, der aus einer technisch fertigen App tatsächlich ein stabiles, store-konformes Produkt macht. Sie beginnt bei einer realistischen Geräte-Matrix mit echten Low-End-Geräten, führt über Crash-Monitoring und Performance-Profiling vor dem ersten produktiven Release, und endet nicht mit der Einreichung, sondern mit einer durchdachten Staged-Rollout-Strategie und aktivem Monitoring in den ersten 48 Stunden.

Der rote Faden dieser Checkliste ist Kontrolle über Risiko: Jeder Schritt, von der Privacy-Manifest-Deklaration bis zum Rollback über einen Feature-Flag oder EAS Update, reduziert die Wahrscheinlichkeit, dass ein einzelner Fehler zu einem unkontrollierten Vorfall eskaliert. Store-Freigabe ist damit kein Endpunkt, sondern ein Kontrollpunkt in einem Prozess, der erst mit stabilen Crash-Free-Raten in Produktion tatsächlich abgeschlossen ist.

11. FAQ: React Native App-Launch-Checkliste und Store-Freigabe