React Native Splash Screen: Expo und Bare Setup (2026)

Kurze Antwort: Nutzt expo-splash-screen mit dem Config-Plugin in einem app.json oder app.config.js wenn die App läuft auf Expo (einschließlich Dev Clients und EAS Builds). Rufe auf SplashScreen.preventAutoHideAsync() in einem globaler Scope, dann SplashScreen.hideAsync() wenn Schriften, Auth und Navigation bereit sind. Auf barem React Native CLI, bevorzuge react-native-bootsplash für neue Projekte; pflege Legacy-Apps mit react-native-splash-screen bis zur Migration. Halte die native Splash-Animation statisch, verstecke sie, sobald der erste echte Screen gerendert werden kann, und verschiebe animierte Splash- Branding in den ersten React-Screen. Bauen Sie stattdessen mit Web-Technologien? Capacitor verwendet @capacitor/splash-screen mit derselben Readiness-Regel, und Capgo liefert Live-Updates für die Web-Schicht ohne Store-Build. Native Splash-Assets brauchen weiterhin ein neues Binary.

Du tippst auf einem echten Gerät auf dein App-Icon, und für einen Sekundenbruchteil sieht der Nutzer einen weißen Flash, ein gestrecktes Logo oder einen eingefrorenen Startbildschirm, der verschwindet, bevor etwas Nützliches bereit ist. Genau diese Lücke soll react native splash screen das Setup abdecken: die native Launch-UI, bis JavaScript einen stabilen ersten Frame anzeigen kann.

Inhaltsverzeichnis

• Warum ein professioneller Splash Screen wichtig ist
  • Was der Splash Screen eigentlich macht
• Perfekte Splash-Screen-Assets vorbereiten
  • Was du vor dem Coden vorbereiten musst
  • Häufige Asset-Fehler
  • Ein praktischer Export-Workflow
• Implementieren mit dem Expo-Go- und Development-Client-Workflow
  • Native Splash Screens deklarativ konfigurieren
  • Blende den Splash-Screen nach Bereitschaft aus, nicht nach Zeit
  • Was dich in Expo Go und Dev Builds erwartet
• Konfiguration für Bare React Native CLI Projekte
  • Android-Setup in einem Bare-Projekt
  • iOS-Setup in einem Bare-Project
  • Bare CLI bietet mehr Kontrolle beim Handoff
  • Expo-managed vs. bare CLI
• Fortgeschrittene Techniken für animierte, performante Splash Screens
  • Animationen sollten zum Startup-Prozess passen
  • Betrachte den Launch als Orchestrierung
• React Native vs. Capacitor: Splash Screens und Fixes ausliefern
  • Splash-Screens in Capacitor
  • Warum Web-Teams Capacitor statt React Native wählen
• Häufige Splash-Screen-Probleme beheben
  • Verzerrtes oder unscharfes Splash-Bild
  • White screen after the splash hides
  • Splash Screen fehlt auf einer Plattform
  • Build bricht nach dem Hinzufügen der Splash-Konfiguration
• Häufig gestellte Fragen

Warum ein professioneller Splash Screen wichtig ist

Ein Nutzer tippt auf eure App auf dem Home-Bildschirm, und die Startsequenz zeigt einen leeren weißen Rahmen, bevor die erste UI erscheint. In der Produktion wirkt das instabil. Es ist egal, dass React Native noch das JavaScript-Bundle lädt oder im Hintergrund den Zustand wiederherstellt. Der erste Eindruck ist bereits falsch.

In React Native ist der Splash-Screen die erste native Oberfläche, die eure App kontrolliert. Er deckt den Übergang zwischen Prozessstart und dem ersten nutzbaren, von React gerenderten Frame ab. Das macht ihn zu einem Startup-Tool, nicht nur zu einem Branding-Asset. Wenn ihr den Timing richtig setzt, sehen Nutzer einen stabilen Start, der absichtlich wirkt. Wenn ihr ihn zu früh ausblendet, sehen sie Layout-Shifts, fehlende Fonts oder einen toten Bildschirm, während Auth, Navigation oder Remote Config aufholen.

Was der Splash Screen eigentlich macht

Ein produktionsreifes Splash-Screen-Setup muss in der Regel vier Startaspekte abdecken:

• Native-to-JS-Startarbeit abdecken: Font-Loading, das Wiederherstellen persistenter Sessions, das Auslesen von Feature Flags und der initiale Navigationszustand konkurrieren alle um den ersten Frame.
• Visuelle Artefakte verhindern: Es vermeidet systembedingtes Weißblitzen, ungestylten Text oder eine nur teilweise gemountete Root-View.
• Visuelle Konsistenz beim Start sicherstellen: Hintergrundfarbe und Logo können an die App-Shell angepasst werden, damit der Übergang kontrolliert wirkt.
• Startentscheidungen erzwingen: Teams müssen definieren, was „bereit“ bedeutet, bevor das Launch-Screen entfernt wird.

Praktische Regel: Das Splash-Screen erst ausblenden, wenn der erste echte Screen sauber gerendert werden kann – nicht nach einer willkürlichen Verzögerung.

Hier beginnen die Expo-managed- und bare CLI-Workflows auch zu divergieren. In Expo-managed-Projekten ist das Splash-Setup größtenteils deklarativ, und die wichtigste Engineering-Entscheidung ist, wann die API-Methode basierend auf der App-Bereitschaft aufgerufen wird. In bare React Native CLI-Projekten übernimmst du mehr natives Setup auf Android und iOS, was dir mehr Kontrolle gibt, aber auch mehr Möglichkeiten bietet, Launch-Flicker, Theme-Mismatches oder plattformspezifische Regressionen einzuführen.

Dieser Trade-off ist in realen Projekten entscheidend. Expo ist schneller zu konfigurieren und leichter über Umgebungen hinweg konsistent zu halten. Bare-Projekte sind oft die richtige Wahl, wenn die App bereits von benutzerdefinierten nativen Modulen, benutzerdefiniertem Launch-Verhalten oder strengerer Kontrolle über den Startpfad abhängt.

Teams, die den Launch als Teil der Produktqualität betrachten, prüfen ihn in der Regel zusammen mit breiteren UX-Arbeiten und nicht als isolierte native Aufgabe. Das ist dieselbe Denkweise, die in Capgo’s Guide zur App-User-Experienceabgedeckt wird. Wenn du React Native gegen Capacitor für eine Greenfield-App abwägst, lies React Native vs. Capacitor im Vergleich bevor du das Launch-Tooling festlegst. Capacitor-Teams konfigurieren Splash-Screens in nativen Projekten und mit @capacitor/splash-screen während der App-Initialisierung, wie beschrieben im Capacitor App-Initialisierungsguide.

Perfekte Splash-Screen-Assets vorbereiten

Die meisten Splash-Screen-Bugs entstehen in Design-Dateien, nicht in code. Wenn das Basis-Asset falsch ist, hilft auch kein Android-XML- oder iOS-Storyboard-Cleanup.

Der sicherste Ansatz ist, den Splash als Layout-Systemzu behandeln, nicht als einzelnes Vollbild-Image. Verwende eine Hintergrundfarbe plus ein zentriertes Logo oder eine Illustration. Das skaliert auf hohen Android-Geräten, iPhones, Tablets und in breiteren Orientierungen vorhersehbarer, als ein detailliertes Poster-Image überall unterzubringen.

Was du vor dem Coden vorbereiten musst

Beginne mit einer sauberen Quelldatei aus dem Design. Vektor ist ideal für den Handoff, auch wenn das exportierte Launch-Asset ein PNG ist.

Nutze diese Checkliste:

• Quellgrafik: Halte ein Master-Logo oder -Markenzeichen in SVG, AI oder einem anderen editierbaren Quellformat vor, damit die Exporte konsistent bleiben.
• Hintergrundfarbe: Definiere die exakte Splash-Hintergrundfarbe im Voraus und stelle sicher, dass sie zum Hintergrund des ersten Screens oder der App-Shell passt.
• Sichere Ränder: Lass genug Leerraum um das Logo, damit aggressives Zuschneiden bei ungewöhnlichen Seitenverhältnissen nicht in das Design greift.
• Plattform-Varianten: Exportiere die Bildgrößen, die dein Workflow benötigt, statt eine Datei überall zu strecken.
• Dark-Mode-Check: Wenn deine App dunkle Oberflächen unterstützt, bestätige, dass das Logo vor dem gewählten Hintergrund noch klar lesbar ist.

Die Anleitung von Expo ist hier hilfreich, da sie unterstreicht, dass Launch-Assets nun Teil der Build-Pipeline sind und kein nachträglicher Gedanke. Die Doku empfiehlt ein quadratisches 1024×1024 PNG für App-Icons und merkt an, dass EAS Build die erforderlichen Größen für Projekte generieren kann, die mit erstellt wurden npx create-expo-app, was zeigt, wie die Asset-Generierung in moderne Tools übergegangen ist, statt manuell wiederholt zu werden.

Häufige Asset-Fehler

Die häufigsten visuellen Fehler sind vorhersehbar:

Ein Splash-Bild sollte keinen dichten Text, winzige Details oder Marketing-Texte enthalten. Startscreens werden nur kurz angezeigt und unter engen nativen Einschränkungen gerendert.

Für Teams, die häufig visuelle Updates veröffentlichen, ist Bild-Disziplin über den Start hinaus wichtig. Die gleichen Gewohnheiten gelten für Delivery-Bundles und Binärgröße, weshalb Guides wie Bilder für Updates optimieren sich lohnen, wenn du Asset-Exports standardisierst.

Ein praktischer Export-Workflow

Ein Setup, das in echten Projekten gut funktioniert, sieht so aus:

1. Erstelle eine zentrierte Komposition auf einem einfarbigen Hintergrund.
2. Exportiere ein transparentes Logo als PNG, falls dein Workflow eine separate Hintergrundfarbe unterstützt.
3. Achte auf konsistente Benennungen über alle Plattformen hinweg, damit Asset-Swaps kein Rätselraten werden.
4. Teste frühzeitig auf kleinen und hohen Simulatoren, bevor du den Splash-Lifecycle implementierst.
5. Rebuild nach Asset-Änderungen durchführen, da Launch-Ressourcen oft in nativen Caches liegen.

Dieser letzte Punkt ist wichtiger, als viele denken. Viele Probleme mit dem Splash Screen, die wie Konfigurationsfehler aussehen, sind in Wirklichkeit nur veraltete native Assets.

Expo Splash Screen (expo-splash-screen)

If you are searching for expo splash screen oder react native expo splash screensuchst, beginne mit dem expo-splash-screen Paket. Es funktioniert mit Managed- und Prebuild-Workflows, hält Launch-Assets in der Config und bietet JavaScript-APIs, um die Sichtbarkeit in Store-Builds zu steuern.

Das wichtigste Verhalten ist einfach zu verstehen. Halte den nativen Splash sichtbar, bis der erste sinnvolle UI-Frame bereit ist. Expo dokumentiert preventAutoHideAsync() so, dass der konfigurierte Splash angezeigt bleibt, bis du hideAsync(). Aufrufen preventAutoHideAsync() im globalen Scope ohne await, nicht in einem Hook, sonst kann der Splash vor dem Start von code automatisch ausgeblendet werden. Ein zu frühes Ausblenden kann auf iOS und Android kurz einen leeren Bildschirm zeigen.

Splash während des Ladens anzeigen (Expo)

Dies ist das übliche React Native Ladebildschirm Muster: Der native Splash deckt das Laden von Fonts, persistente Auth und Remote Config ab, während React null. When isReady true wird, rufe hideAsync()auf. Optional SplashScreen.setOptions() passt das Fade-Verhalten beim Ausblenden an. Teste Splash-Assets in einem Entwickler-Client, Preview, oder Produktion build; Expo dokumentiert, dass Expo Go ist nicht die maßgebliche Umgebung für die native Splash-Konfiguration.

Native Splash Screens deklarativ konfigurieren

In einem Expo-Projekt liegt die visuelle Gestaltung normalerweise in app.json, app.config.js, oder app.config.ts unter der expo-splash-screen Config-Plugin, wie beschrieben in Expos Guide zu Splash Screen und App-Icon.

Ein typisches app.json Setup sieht so aus:

{
  "expo": {
    "plugins": [
      [
        "expo-splash-screen",
        {
          "backgroundColor": "#111111",
          "image": "./assets/splash-icon.png",
          "imageWidth": 200
        }
      ]
    ]
  }
}

Die genauen Felder können je nach Projekt-Setup variieren, aber das Muster bleibt gleich. Du definierst das native Launch-Aussehen in der Config und steuerst die Sichtbarkeit dann aus JavaScript.

Einige praktische Entscheidungen sind hier wichtig:

• Nutze eine Hintergrundfarbe, die deinem Startbildschirm ähnelt, damit der Übergang flüssig wirkt.
• Halte das Bild einfach. da Launch-Screens nicht für komplexe Grafiken gedacht sind.
• Vermeide künstliche Branding-Verzögerungen. die Nutzer auf einem Logo festhalten, obwohl die App schon bereit ist.

Blende den Splash-Screen nach Bereitschaft aus, nicht nach Zeit

Viele Tutorials führen in die Irre. Sie nutzen setTimeout, was zwar leicht zu demonstrieren, aber falsch für die Produktion ist.

Nutze stattdessen den Startup-State. Ein gängiges Root-Level-Pattern sieht so aus:

import { useCallback, useEffect, useState } from 'react';
import { View } from 'react-native';
import * as SplashScreen from 'expo-splash-screen';

SplashScreen.preventAutoHideAsync();

export default function App() {
  const [isReady, setIsReady] = useState(false);

  useEffect(() => {
    async function prepare() {
      try {
        // Load fonts
        // Restore auth state
        // Read persisted settings
      } finally {
        setIsReady(true);
      }
    }

    prepare();
  }, []);

  const onLayoutRootView = useCallback(async () => {
    if (isReady) {
      await SplashScreen.hideAsync();
    }
  }, [isReady]);

  if (!isReady) {
    return null;
  }

  return (
    <View style={{ flex: 1 }} onLayout={onLayoutRootView}>
      {/* Your real app UI */}
    </View>
  );
}

Zwei Details machen dieses Pattern zuverlässig.

Erstens, preventAutoHideAsync() wird aufgerufen, bevor die App relevante UI rendert. Zweitens erfolgt das Ausblenden erst, wenn die Root-View bereit zum Layouten ist, was die Gefahr eines Flackerns zwischen nativem Splash und React-Tree reduziert.

Verstecke den Splash Screen nicht, sobald deine asynchronen Aufgaben fast fertig sind. Blende ihn erst aus, wenn die darauf basierende UI tatsächlich gerendert werden kann.

Dieser Unterschied ist entscheidend, wenn der Startup Auth-Restoration, Remote Config oder Font-Loading beinhaltet. Wenn dein Home-Screen von Custom Fonts und dem Login-Status abhängt, sollte der Splash diese Lücke füllen.

Ein hilfreicher Walkthrough durch das breitere React-Native-Ökosystem für Landing und Startup findest du unten:

Was dich in Expo Go und Dev Builds erwartet

Expo bringt eine zusätzliche Komplikation mit sich. Das Splash-Verhalten, das du in einem Standalone-Build erwartest, weicht möglicherweise von dem ab, was du in Expo Go siehst.

Diese Diskrepanz verwirrt viele Teams. Du änderst das Asset oder die Timing-Logik, testest in Expo Go und schließt daraus, dass die Konfiguration fehlerhaft ist – obwohl das eigentliche Problem darin liegt, dass die Entwicklungsumgebung sich nicht wie ein Produktions-Binary verhält.

Nutze dieses mentale Modell:

• Expo Go ist praktisch für Iterationen ist aber nicht die letzte Instanz für natives Splash-Verhalten.
• Entwickler-Clients sind der Realität näher weil sie dein generiertes natives Projekt enthalten.
• Standalone-Builds sind die finale Prüfung für Launch-Timing, Theme-Verhalten und Asset-Korrektheit.

Wenn dein Splash immer noch aufblitzt oder hängen bleibt, liegt der Bug meist an einem von drei Dingen: zu frühes Ausblenden, Rendering null zu lange nach dem Ausblenden, oder beim Testen in einer Umgebung, die das Release-Verhalten nicht widerspiegelt.

Bare React Native CLI Splash-Screen

Eine bare React Native App gibt dir direkte Kontrolle über das Launch-Verhalten. Für neue bare CLI Projekte, react-native-bootsplash ist die gepflegte Option (aktive Releases bis 2026 und abgestimmt auf die aktuelle React Native Support-Policy). Viele Produktions-Apps shippen immer noch react-native-splash-screen; behandle es als Legacy-Wartung es sei denn, du bist bereits integriert.

Animierter Splash Screen (React Native oder Expo): iOS LaunchScreen.storyboard bleibt statisch. Android 12+ kann kurz ein animiertes Vektor-Icon im System-Splash zeigen, aber expo-splash-screen und die meisten reinen CLI-Setups nutzen noch ein statisches PNG und verlagern die Animation auf den ersten React-Screen (z. B. Lottie). Verstecke den nativen Splash, sobald der Startup-Prozess fertig ist, und animiere dann dort. Siehe Animations-Performance in Capacitor Apps für dieselbe Startup-Disziplin auf einem anderen Stack.

In CLI-Projekten bleibt das Ziel der nativen Übergabe unverändert: Die Launch-UI sofort anzeigen und erst verbergen, wenn eine sinnvolle UI gerendert werden kann.

Android-Setup in einem Bare-Projekt

Die Android-Splash-Konfiguration ist an mehreren Stellen gleichzeitig verteilt: Theme-Resources, Drawables, AndroidManifest.xml, und MainActivity. Diese Aufteilung ist der Grund, warum kleine Fehler zu sichtbarem Flackern führen.

Der übliche Workflow ist unkompliziert:

1. Erstelle Splash-Assets für die von dir unterstützten Android-Ressourcenordner.
2. Definiere ein Launch-Theme mit der passenden Hintergrundfarbe und dem Splash-Drawable.
3. Wende dieses Theme auf die Launcher-Activity in AndroidManifest.xml.
4. Initialisiere den Splash Screen in MainActivity.
5. Blende ihn per JavaScript aus, sobald die Startup-Tasks, die den ersten Render blockieren, erledigt sind.

Ein vereinfachtes MainActivity.kt Pattern sieht oft so aus:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // initialize splash handling here depending on the library
}

Das Snippet ist absichtlich generisch gehalten, da der exakte Aufruf von der Library abhängt. Die native Integration ist meist der einfache Teil. Fehler entstehen eher bei den Ressourcen und Theme-Übergängen.

Hier sind die Android-Probleme, die in der Produktion auftreten:

• Theme-Mismatch: Wenn das Launch-Theme eine andere Hintergrundfarbe nutzt als dein erster App-Screen, sehen Nutzer beim Übergang ein kurzes Flackern.
• Falsche Asset-Buckets: Android dehnt oder verwischt Assets, die in den erwarteten Density-Ordnern fehlen.
• Nur mit Metro testen: Native Ressourcenänderungen erfordern meist einen Clean Rebuild. Hot Reload validiert das Launch-Verhalten nicht.
• Android 12 Launch-Regeln: Neuere Android-Versionen wenden zuerst ihr eigenes Splash-Verhalten an, daher müssen eigene Setups diese Plattform-Vorgaben beachten.
• Langsames JS nach dem Ausblenden: Wenn React den Splash ausblendet, bevor die Root-View rendern kann, sehen Nutzer einen leeren Frame statt eines flüssigen Übergangs.

Dieser letzte Punkt ist wichtiger als das Bild selbst. Timing-Probleme werden meist als Performance-Probleme wahrgenommen.

iOS-Setup in einem Bare-Project

Bei iOS liegt der Fokus auf LaunchScreen.storyboard plus einem kleinen Native-Hook in AppDelegate. Die Plattform erwartet, dass der Launch Screen statisch und leichtgewichtig ist. Behandle ihn wie einen Snapshot der visuellen Struktur des ersten Screens, nicht wie einen Mini-Onboarding-Flow.

Das zuverlässige Setup sieht so aus:

• Assets zum Xcode Asset Catalog hinzufügen.
• Konfigurieren LaunchScreen.storyboard mit einfachen Constraints.
• Halte das Layout statisch. Hintergrundfarbe, Logo und sichere Abstände reichen meist aus.
• Füge den nativen Bootstrap-Aufruf der Library in AppDelegate.
• Blende den Splash erst über JavaScript aus, wenn die App vollständig bereit zum Rendern ist.

Teams, die neu bei iOS sind, überladen das Storyboard oft. Das geht meist nach hinten los. Komplexe Constraints, mehrfach verschachtelte Views oder der Versuch, den Launch Screen zu animieren, machen das Setup wartungsintensiver und fehleranfälliger über verschiedene Displaygrößen hinweg.

Ein schlichter Launch Screen ist die sicherere Wahl.

Bare CLI bietet mehr Kontrolle beim Handoff

Das ist der Hauptunterschied zwischen Expo-managed und bare CLI. Expo bietet einen schnelleren Weg zu korrekten Defaults. Bare gibt dir die volle Verantwortung für die native Launch-Pipeline.

Dieser Trade-off lohnt sich, wenn beim Startup mehr passiert als nur ein Bundle zu laden. Apps mit Auth-Restoration, Lesezugriffen auf verschlüsselten Storage oder custom nativer SDK-Initialisierung brauchen diese zusätzliche Kontrolle. Bare-Projekte erlauben es dir, das Splash-Timing mit dieser Arbeit abzustimmen, statt alles über High-Level-Konfiguration zu erzwingen.

Falls du nach dem Launch eine Animation planst, halte den nativen Splash auf iOS statisch und nutze auf Android vorzugsweise ein statisches Asset, außer du konfigurierst das Android 12 Animated Icon gezielt. Verlagere die Bewegung in den ersten React-Screen. Die Performance-Trade-offs sind ähnlich wie bei jedem mobilen Startup-Pfad. Heavy Work beim ersten Paint ist teuer. Dies Leitfaden zur Animations-Performance in Capacitor Apps behandelt dasselbe Prinzip in einem anderen Stack, und die Erkenntnisse lassen sich direkt auf React Native übertragen.

Expo-managed vs. bare CLI

Beim praktischen Vergleich geht es weniger um die Bildanzeige als darum, wo die Startup-Komplexität liegt.

Wenn die App bereits in Expo läuft und die Launch-Anforderungen Standard sind, spart das Dortbleiben in der Regel Zeit. Hängt der Startup-Pfad von der Reihenfolge der nativen Initialisierung, eigenen Themes oder plattformspezifischer Boot-Logik ab, ist Bare CLI oft die sauberere langfristige Wahl.

Beide Workflows können einen ausgefeilten Splash Screen ausliefern. Der Unterschied ist, wer die Launch-Pipeline verantwortet: euer Framework oder euer Team.

Fortgeschrittene Techniken für animierte, performante Splash Screens

Animierte Splash-Screens wirken hochwertig, wenn sie sich in die Startup-Pipeline einfügen. Sie wirken billig, wenn sie davon ablenken.

Deshalb behandle ich Animation als Enhancement-Layer, nicht als Fundament. Die erste Aufgabe ist weiterhin das Timing. Wenn die App nicht bereit ist, bleibt der Splash. Wenn die App bereit ist, sollte der Übergang schnell zum ersten nutzbaren Screen führen.

Animationen sollten zum Startup-Prozess passen

Ein gängiges Muster ist es, den nativen Splash einfach zu halten und dann eine leichte Branding-Animation im ersten React-Screen nach dem Launch abzuspielen. Das bietet mehr Flexibilität, als zu versuchen, die eigentliche native Launch-Oberfläche zu animieren.

Lottie ist eine praktische Wahl für diese Art von Handoff, weil es Motion liefern kann, ohne im ersten Screen einen schweren eigenen Animations-Stack aufzubauen. Wichtig ist die Sequenzierung:

• Der native Splash bleibt während der kritischen Startup-Arbeit sichtbar.
• React mountet den ersten echten Screen oder einen kontrollierten Übergangs-Screen.
• Eine optionale Animation wird nur abgespielt, wenn sie die Interaktion nicht länger als nötig blockiert.

Was nicht funktioniert, ist das alte setTimeout(2000) Muster. Auf einem schnellen Gerät lässt das die App ohne Grund warten. Auf einem langsamen Gerät ersetzt es oft nur einen Ladezustand durch einen anderen.

Betrachte den Launch als Orchestrierung

Ein besseres mentales Modell ist Startup-Orchestrierung. Der Splash Screen sollte genau die Aufgaben abdecken, die abgeschlossen sein müssen, bevor die App relevante Inhalte anzeigen kann.

Das umfasst meist eine Mischung aus:

• Auth-Bootstrap: Session wiederherstellen oder entscheiden, ob zum Sign-in weitergeleitet wird.
• Wichtige Storage-Reads: Theme, Locale, Onboarding-Status und zuletzt bekannte kritische Einstellungen.
• Font-Readiness: Besonders, wenn der erste Screen für ein stabiles Layout auf eigene Schriftarten angewiesen ist.
• Remote Config, die das UI steuert: Nur wenn der erste Screen ohne ihn nicht sicher gerendert werden kann.

Es gibt noch eine Nuance, die in vielen Tutorials fehlt: Das Verhalten des Splash Screens ändert sich je nach Umgebung. Diskussion über das Splash-Handling von Expo in Entwicklung und Produktion weist darauf hin, dass das Verhalten in Expo Go anders sein kann als in Standalone-Builds und dass sich die automatische Sichtbarkeitsverwaltung ändert, sobald man die manuelle Kontrolle übernimmt. Das ist ein Grund, warum zeitbasierte Beispiele schnell veralten. Sie verbergen die tatsächliche Startup-Sequenz, statt sich an ihr auszurichten.

Ein Launch Screen sollte nicht dazu dienen, Geschwindigkeit vorzutäuschen. Er sollte verhindern, dass Nutzer unfertige UI sehen.

Wenn du Animationen in einem Hybrid-Stack hinzufügst oder die allgemeine Rendering-Performance bewertest, ist dieser Guide zur Animations-Performance in Capacitor-Apps ein hilfreicher Kontext, da dieselbe Disziplin gilt. Halte die Arbeit beim Start schlank, vermeide unnötiges Blocking und lass Animationen die Responsiveness unterstützen, statt mit ihr zu konkurrieren.

Ein praktischer Hinweis für Teams, die visuelle Fixes außerhalb vollständiger Binary-Releases ausliefern: Plattformen wie Capgo verwalten JavaScript-, CSS-, Text-, Config- und Asset-Updates für Capacitor und Electron-Apps, aber native Splash-Änderungen in React Native gehören weiterhin in die Native-Build-Pipeline, weil der echte Splash Screen erscheint, bevor die JavaScript-App läuft.

React Native vs. Capacitor: Splash Screens und Fixes ausliefern

Wenn du diesen Artikel liest, weil du eine neue App startest oder dein Team bereits eine Web-App in React, Vue, Angular oder Svelte hat, lohnt sich ein Vergleich, wie Splashscreens in Capacitor. Das Konzept des nativen Startbildschirms ist dasselbe, aber der Workflow im Alltag ist für Web-Teams einfacher.

Splash-Screens in Capacitor

Capacitor-Apps nutzen das offizielle @capacitor/splash-screen Plugin. Du konfigurierst es einmal in capacitor.config.ts und blendest es in deinem Web-code aus, sobald die App bereit ist:

// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli'

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example',
  webDir: 'dist',
  plugins: {
    SplashScreen: {
      launchAutoHide: false,
      backgroundColor: '#ffffff',
    },
  },
}

export default config

// main.ts, after your router, fonts, and auth are ready
import { SplashScreen } from '@capacitor/splash-screen'

await SplashScreen.hide()

Die Readiness-Regel aus dieser Anleitung ist dieselbe: Halte den nativen Splash statisch, blende ihn aus, sobald der erste echte Screen gerendert werden kann, und lass Animationen im ersten Screen deiner App laufen. Für native Assets @capacitor/assets generiert die Icon- und Splash-Dateien für Android und iOS aus deinen Quell-Icons und Splash-Bildern (zum Beispiel icon-only.png und splash.png in einem assets Ordner). Der schrittweise Ablauf wird in Capacitor App-Initialisierung.

Warum Web-Teams Capacitor statt React Native wählen

• Wiederverwendung der vorhandenen App: Capacitor kapselt Ihre bestehende Web-App in eine native Hülle, sodass Ihre Komponenten, CSS und Build-Tools weiter funktionieren. React Native erfordert das Neuschreiben der UI in React-Native-Komponenten.
• Jedes Framework: React, Vue, Angular, Svelte oder reines JavaScript funktionieren alle. Sie sind nicht an React gebunden.
• Native Zugriffe, wenn Sie sie brauchen: offizielle und Community-Plugins decken Kamera, Push, Biometrie und mehr ab, und Sie können eigene Swift- oder Kotlin-Plugins schreiben.
• Live Updates für die App-Ebene: mit Capgo, Sie pushen JavaScript-, HTML-, CSS- und Asset-Fixes an Nutzer beim nächsten Start, mit Channels, gestaffelten Rollouts und One-Click-Rollback, ohne auf Store-Reviews bei jeder Web-Ebenen-Änderung zu warten. Native Änderungen, einschließlich des nativen Splash Screens selbst, werden weiterhin über die Stores ausgeliefert. Siehe die Capgo Live-Update-Dokumentation.

Für einen vollständigen Vergleich von Performance, Tooling und Team-Passung lesen Sie React Native vs. Capacitor im Vergleich. Wenn du heute Expo nutzt und über einen Wechsel nachdenkst, Alternative zu Expo geht die Optionen durch.

Häufige Splash-Screen-Probleme beheben

Die meisten Splash-Screen-Probleme lassen sich auf wenige wiederkehrende Ursachen zurückführen. Die Lösung wird einfacher, wenn man zwischen Asset-Problemen,, Timing-Problemen, und und nativen Integrationsproblemen.

unterscheidet. Die Community-Muster in aktuellen React Native Guides laufen auf denselben Kernablauf hinaus: Library hinzufügen, native Launch-Assets konfigurieren, den Splash-Screen show beim Start aufrufen und ausblenden, sobald die App bereit ist. Android-Setups beinhalten häufig MainActivity XML- oder Drawable-Ressourcen, während iOS auf native Launch-Assets setzt LaunchScreen.storyboard und AppDelegate. In derselben Übersicht heißt es, dass Expo ein quadratisches 1024×1024 PNG für App-Icons empfiehlt und dass EAS Build die benötigten Größen für Projekte generieren kann, die mit npx create-expo-app, wie zusammengefasst in diesem React Native Splash-Screen-Guide.

Verzerrtes oder unscharfes Splash-Bild

Symptom: Das Logo wirkt unscharf, abgeschnitten oder seltsam skaliert.

Ursache: Das Basisbild wurde nicht korrekt exportiert oder das Layout basiert auf einem Fullscreen-Raster, das sich nicht gut anpasst.

Lösung: Ersetze Poster-Artwork durch ein zentriertes Logo auf einfarbigem Hintergrund. Exportiere erneut aus der ursprünglichen Designquelle, generiere die Assets für die jeweiligen Bildschirmdichten neu und prüfe, ob deine Android-Drawables oder der iOS Asset Catalog die gewünschten Dateien enthalten.

Weißer Bildschirm, nachdem der Splash verschwindet

Symptom: Der native Splash verschwindet, und Nutzer sehen einen leeren Frame vor dem ersten Screen.

Ursache: Deine App blendet den Splash Screen aus, bevor die Root-UI sinnvolle Inhalte rendern kann.

Lösung: Kopple das Ausblenden des Splash Screens an die Bereitschaft, nicht an die verstrichene Zeit. In Expo heißt das meist, den Splash so lange zu halten, bis deine Root-View das Layout aufbauen kann. In Bare-Projekten nutzt du das entsprechende Pattern und stellst sicher, dass der erste gerenderte Screen nicht sofort durch weitere async Tasks blockiert wird.

Splash Screen fehlt auf einer Plattform

Symptom: Android zeigt ihn an, iOS nicht – oder umgekehrt.

Ursache: Eine native Seite war nicht vollständig konfiguriert. Oft liegt es an einer vergessenen Storyboard-Referenz, Problemen beim Theme-Wiring oder einem Asset, das nicht dem richtigen Target hinzugefügt wurde.

Lösung: Prüfe die plattformspezifischen Dateien einzeln. Kontrolliere bei Android das Launch-Theme und die Resource-Referenzen. Bei iOS bestätige LaunchScreen.storyboarddie Asset-Catalog-Mitgliedschaft sowie die App-Target-Einstellungen in Xcode.

Build bricht nach dem Hinzufügen der Splash-Konfiguration ab

Symptom: Die App kompiliert nicht mehr, nachdem eine Bibliothek hinzugefügt oder Splash-Dateien geändert wurden.

Ursache: Native Projektdateien und generierte Konfiguration können aus dem Takt geraten, besonders nach Plugin- oder Asset-Änderungen.

Lösung: Build bereinigen, bei Bedarf Abhängigkeiten neu installieren und das native Projekt vollständig neu bauen. Bei Expo mit generierten Native-Layern: vorsichtig regenerieren und Plugin-Konfiguration prüfen. Bei einer Bare App: prüfen MainActivity, AppDelegate, Ressourcennamen und alle plist- oder Manifest-Änderungen bei kleinen Abweichungen.

Die schnellsten Teams sehen den Splash Screen als Teil des Release Engineering, nicht als einmalige Designaufgabe. Das zählt noch mehr, wenn Startup-Assets, UI-Texte oder App-Shell-Verhalten nach dem Launch schnell geändert werden müssen. Capgo ermöglicht es Capacitor- und Electron-Teams, JavaScript, CSS, Texte, Configs und Asset-Fixes mit Rollout-Steuerung und Rollback-Support beim nächsten Start auszuliefern – ideal, wenn das Problem in der App-Schicht statt im nativen Launch Screen liegt.

Häufig gestellte Fragen

Wie füge ich einen Splash Screen in Expo hinzu (expo splash screen)?
Füge den expo-splash-screen Plugin, um app.json oder app.config.js, setzen backgroundColor und image, ein natives Binary neu bauen, aufrufen preventAutoHideAsync() im globalen Scope, und hideAsync() wenn der erste Screen bereit ist. Validiere in einem Dev-Client oder Production-Build, nicht nur in Expo Go.

Wie halte ich den Splash Screen sichtbar, während meine React Native-App lädt?
In Expo, preventAutoHideAsync() plus Rückgabe null bis die asynchrone Arbeit abgeschlossen ist, dann hideAsync(). Mit react-native-splash-screen, rufe SplashScreen.show(this) unter Android MainActivity oder [RNSplashScreen show] unter iOS AppDelegate, dann SplashScreen.hide() von JavaScript aus, sobald bereit. Mit react-native-bootsplash, nativ pro Plattform initialisieren, dann aufrufen BootSplash.hide() nach demselben Readiness-Gate.

Was ist der Unterschied zwischen react-native-splash-screen und react-native-bootsplash?
Bootsplash wird aktiv gepflegt und bietet einen Generator für Launch-Assets. react-native-splash-screen ist in älteren Repos noch verbreitet, wird aber langsamer gepflegt; für neue Bare-CLI-Apps lieber bootsplash verwenden.

Wie richte ich einen Splash Screen in Bare React Native ohne Expo ein?
Installieren react-native-bootsplash, Assets generieren, aufrufen RNBootSplash.init(this, R.style.BootTheme) auf Android oder RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) auf iOS, dann BootSplash.hide() aus JS, wenn der Start abgeschlossen ist. Legacy-Projekte können SplashScreen.show(this) / [RNSplashScreen show] mit SplashScreen.hide() verwenden. Nach Änderungen an nativen Assets neu bauen.

Kann ich einen animierten Splash-Screen in React Native oder Expo verwenden?
An iOS, den Startbildschirm statisch halten. Auf Android 12+, kann der System-Splash ein kurzes animiertes Icon verwenden, aber die meisten Teams halten expo-splash-screen oder Bootsplash-Assets statisch, verstecken sie, wenn bereit, und animieren sie dann in React (z. B. Lottie). Nicht darauf verlassen, setTimeout um Ladezeiten vorzutäuschen.

Wo unterscheidet sich das Splash-Setup zwischen React Native und Capacitor?
React Native nutzt expo-splash-screen oder Bare-CLI-Bibliotheken, bevor JS läuft. Capacitor nutzt native Launch Screens sowie @capacitor/splash-screen im WebView-Stack. Siehe React Native vs. Capacitor im Vergleich und Capacitor App-Initialisierung.

Bring deine Capacitor App mit Capgo schneller live

Baust du mit Capacitor oder willst du eine Web-App auf Mobile bringen? Erstelle ein kostenloses Capgo-Konto und schiebe in wenigen Minuten dein erstes live update. Capgo liefert JavaScript-, CSS- und Asset-Fixes an deine Nutzer beim nächsten Start, mit gestaffelten Rollouts und sofortigem Rollback, damit ein Bug in deiner App-Schicht nie auf die Store-Prüfung warten muss.

Weiter geht's: React Native Splash Screen (Expo und bare CLI)

Wenn du es nutzt diesem Guide , um natives Media- und Interface-Verhalten zu planen, verbinde es mit @capgo/capacitor-live-activities verwenden für die native Funktion in „@capgo/capacitor-live-activities verwenden“, @capgo/capacitor-live-activities für die Implementierungsdetails in @capgo/capacitor-live-activities, Verwendung von @capgo/capacitor-video-player für die native Funktion bei Verwendung von @capgo/capacitor-video-player, @capgo/capacitor-video-player für die Implementierungsdetails in @capgo/capacitor-video-player und Verwendung von @capgo/capacitor-native-navigation für die native Funktion bei Verwendung von @capgo/capacitor-native-navigation.