Guide complet de l'écran d'accueil en React Native pour 2026

You tap your app icon on a real device, and for a split second the user gets a white flash, a stretched logo, or a frozen launch screen that disappears before anything useful is ready. That’s usually the moment a React Native app stops feeling production-grade.

Un bon écran de démarrage dans React Native répare plus que la marque. Il couvre la lacune entre le démarrage natif et le premier cadre React rendu significatif. Il oblige également à réfléchir clairement à l'ordre de démarrage, à la préparation des actifs et à la différence entre ce qui se passe dans Expo Go, un client de développement, et une mise en magasin réelle. Si vous vous trompez dans la mise en page, les utilisateurs voient les fissures immédiatement.

Tableau de Contenu

• Pourquoi un écran de démarrage professionnel compte
  • Ce que fait vraiment l'écran de démarrage
• Préparer des actifs d'écran de démarrage parfaits
  • Ce que préparer avant de coder
  • Erreurs courantes sur les actifs
  • Flux de travail d'exportation pratique
• Mettre en œuvre avec le flux de travail du client de développement et d'Expo Go
  • Configurez la splash native de manière déclarative
  • Hide the splash based on readiness, not time
  • What to expect in Expo Go and dev builds
• Configuration pour les projets React Native Bare CLI
  • Configuration Android dans un projet Bare
  • Configuration iOS dans un projet Bare
  • Bare CLI vous donne plus de contrôle sur la prise en charge
  • Expo géré par rapport à Bare CLI
• Techniques avancées pour les écrans de démarrage animés et performants
  • L'animation doit suivre la réalité de démarrage
  • Traitez le lancement comme une orchestration
• Résolution de Problèmes Courants de l'Ecran d'Attente
  • Image d'écran de démarrage étirée ou floue
  • Écran blanc après la cacher de la splash
  • Écran d'accueil manquant sur une plateforme
  • Build breaks after adding splash configuration

Why a Professional Splash Screen Matters

Un utilisateur appuie sur votre application depuis l'écran d'accueil, et la séquence de lancement affiche une fenêtre blanche vide avant que le premier UI ne soit visible. En production, cela donne l'impression d'instabilité. Il ne fait pas de différence que React Native charge toujours le bundle JavaScript ou restaure l'état en arrière-plan. La première impression est déjà fausse.

In React Native, the splash screen is the first native surface your app controls. It covers the handoff between process start and the first usable React-rendered frame. That makes it a startup tool, not just a branding asset. If you time it well, users see a stable launch that feels intentional. If you hide it too early, they see layout shifts, missing fonts, or a dead-looking screen while auth, navigation, or remote config catches up.

Ce que fait vraiment l'écran d'accueil

L'écran d'accueil en production doit généralement gérer quatre préoccupations de démarrage :

• Couvrir le travail de démarrage native vers JS : font loading, persisted session restore, feature flag reads, and initial navigation state all compete for the first frame.
• Prévenir les glitches visuels : il évite les éclairs de blanc système, du texte non stylisé ou d'une vue racine partiellement montée.
• Maintenez la lancement visuellement cohérent : the background color and logo can match your app shell so the transition feels controlled.
• Forcer les décisions de démarrage : les équipes doivent définir ce que « prêt » signifie avant de supprimer l'écran de lancement.

Règle pratique : Cacher le splash lorsque la première écran réelle peut s'afficher proprement, pas après un délai arbitraire.

This is also where the Expo-managed and bare CLI workflows start to diverge. In Expo-managed projects, splash setup is mostly declarative, and the main engineering decision is when to call the hide API based on app readiness. In bare React Native CLI projects, you own more native setup on Android and iOS, which gives you more control but also more ways to introduce launch flicker, theme mismatches, or platform-specific regressions.

Cette trade-off compte dans les projets réels. Expo est plus rapide à configurer et plus facile à maintenir cohérent à travers les environnements. Les projets bare sont souvent la bonne choix lorsque l'application dépend déjà de modules natifs personnalisés, de comportements de lancement personnalisés ou d'un contrôle plus strict sur le chemin de démarrage.

Teams that treat launch as part of product quality usually review it alongside broader UX work, not as an isolated native task. That is the same mindset covered in Capgo’s guide to app user experienceSi vous évaluez également la pile React Native plus large pour une nouvelle application ou une migration, Nerfiez vos applications React Native fournit un aperçu produit centré sur l'utilité.

Préparation d'éléments d'écran d'accueil parfaits

Most splash screen bugs start in design files, not code. If the base asset is wrong, no amount of Android XML or iOS storyboard cleanup will save it.

The safest approach is to treat the splash as a système de disposition, et non une image d'écran unique. Utilisez une couleur de fond ainsi qu'un logo ou une illustration centrée. Cela s'adapte plus prédicablement sur les appareils Android hauts, les iPhones, les tablettes et les orientations d'appareil plus larges que d'essayer de faire tenir une image d'affiche détaillée dans n'importe quel endroit.

Qu'est-ce qu'il faut préparer avant de coder

Commencez avec un fichier source vierge issu de la conception. Le vecteur est idéal pour le transfert, même si l'actif de lancement exporté est un PNG.

Utilisez ce tableau :

• Artwork source : Conservez un logo maître ou marque en format SVG, AI ou autre format source éditable afin que les exports restent cohérents.
• Color d'arrière-plan: Définissez d'abord la couleur exacte de l'arrière-plan de la splash et assurez-vous qu'elle correspond à la première page ou à la coque d'application.
• Marges sûres: Laisserez suffisamment d'espace vide autour du logo pour éviter que la mise en page ne soit coupée par des ratios d'aspect inhabituels.
• Variantes de plateforme: Exportez les tailles d'image nécessaires à votre flux de travail, plutôt que de les étirer partout.
• Examen de la mode sombre: Si votre application prend en charge les surfaces sombres, assurez-vous que le logo reste lisible contre le fond choisi.

La documentation d'Expo est utile ici car elle renforce l'idée que les actifs de lancement font désormais partie de la chaîne de construction, et non une pensée après coup. 1024×1024 PNG carré pour les icônes d'application et notez que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-appqui montre comment la génération d'actifs a migré vers les outils modernes, plutôt que la répétition manuelle.

Erreurs courantes d'actifs

Les principales erreurs visuelles sont prévisibles :

Une image d'accueil ne doit pas comporter de texte dense, de détails minuscules ou de publicité. Les écrans de démarrage sont affichés brièvement et rendus sous des contraintes natives serrées.

For teams shipping frequent visual updates, image discipline matters beyond launch. The same habits apply to delivery bundles and binary size, which is why guides like Optimiser les images pour les mises à jour sont à revoir lors de la standardisation des exports d'actifs.

Un workflow d'exportation pratique

Un ensemble qui fonctionne bien dans des projets réels ressemble à ceci :

1. Concevoir une composition centrée unique sur un fond neutre.
2. Exporter un logo PNG transparent. Si votre workflow prend en charge une couleur de fond séparée.
3. Maintenez la cohérence des noms across platforms so asset swaps don’t become guesswork.
4. Testez sur les simulateurs petits et grands tôt avant de brancher le cycle de splash.
5. Rebâtissez après les changements d'actifs because launch resources often sit in native caches.

Cela compte plus que ce que l'on pense généralement. Beaucoup d'erreurs de splash screen qui ressemblent à des bugs de configuration sont simplement des assets natifs obsolètes.

Implementing with the Expo Go and Development Client Workflow

Si vous utilisez Expo, commencez par expo-splash-screenIl convient à l'écoulement géré, garde la plupart de la configuration déclarative et vous donne un contrôl’explicite sur quand le splash doit disparaître.

Le comportement clé à comprendre est simple. Conservez le splash natif visible jusqu'à ce que le premier cadre UI significatif soit prêt. Expo's SplashScreen API prend en charge exactement ce modèl’avec preventAutoHideAsync() supporte exactement ce modèl’avec hideAsync() once critical loading has finished, and Expo warns that hiding too early can briefly expose a blank screen in both iOS and Android builds, as documented in the Écran d'accueil Expo API.

Expo splash screen __CAPGO_KEEP_0__

Dans un projet Expo, le côté visuel vit généralement dans app.json or app.config.js.

Un typique app.json Un exemple de configuration ressemble à ceci :

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

The exact fields can vary by project setup, but the pattern stays the same. You define the native launch appearance in config, then control visibility from JavaScript.

A quelques choix pratiques importent ici :

• Utilisez une couleur de fond proche de votre écran initial afin que la transition se sente continue.
• Gardez l'image simple Les surfaces de lancement ne sont pas le lieu pour des œuvres d'art denses.
• Évitez les « retards de branding » fictifs that hold users on a logo when the app is already ready.

Hide the splash based on readiness, not time

De nombreux tutoriels se trompent souvent. Ils utilisent setTimeoutqui est facile à démontrer et inapproprié pour la production.

Use startup state instead. A common root-level pattern looks like this:

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>
  );
}

Deux détails rendent ce modèle fiable.

Premièrement, preventAutoHideAsync() is called before the app starts rendering meaningful UI. Second, the hide happens only after the root view is ready to lay out, which reduces the chance of a flash between the native splash and the React tree.

Don’t hide the splash when your async work starts finishing. Hide it when the UI that depends on that work can actually render.

That distinction matters most when startup includes auth restoration, remote configuration, or font loading. If your home screen depends on custom fonts and a signed-in state, the splash should cover that gap.

Un guide utile de l'écosystème React Native plus large et du démarrage est disponible ci-dessous :

What to expect in Expo Go and dev builds

Expo adds one extra wrinkle. The splash behavior you expect in a standalone build may not match what you see in Expo Go.

Cette incohérence confond beaucoup d'équipes. Vous modifiez la logique ou les actifs, testez dans Expo Go et concluez que la configuration est brisée lorsque le problème réel est que l'environnement de développement ne se comporte pas comme un binaire de production.

Utilisez ce modèle mental :

• Expo Go est pratique pour l'itération but it isn’t the final authority on native splash behavior.
• Development clients are closer to reality car ils incluent votre projet native généré.
• Les builds autonomes sont la vérification finale for launch timing, theme behavior, and asset correctness.

Si votre splash continue de clignoter ou de rester affiché, le bug est généralement l'un des trois : cacher trop tôt, le rendu null for too long after hide, or testing in an environment that doesn’t reflect release behavior.

Configuration pour les projets React Native Bare CLI

Un projet React Native Bare vous donne un contrôle direct sur le comportement de lancement, ce qui est utile une fois que la page de démarrage doit correspondre au travail de démarrage réel au lieu de montrer un logo pour un délai fixe. Ce contrôl’implique la responsabilité native. Vous devez brancher Android et iOS correctement, reconstruire souvent et tester la transmission entre l'interface de lancement native et la première écran React sur des appareils réels.

In CLI projects, I usually recommend react-native-bootsplash for new work. It fits current React Native projects better than older splash libraries, and the native setup is easier to reason about during upgrades. Older apps still ship with react-native-splash-screen, so you will run into it in maintenance work, but for a fresh setup the goal stays the same. Show a native launch surface immediately, then hide it only after the app can render meaningful UI.

Configuration Android dans un projet nu

Android splash setup lives in a few places at once: theme resources, drawables, AndroidManifest.xmlet MainActivity. C'est pourquoi les petites erreurs créent des éclairs visibles.

Le flux habituel est simple :

1. Generate splash assets for the Android resource folders you support.
2. Définissez un thème de lancement avec la couleur de fond et l'image de splash correctes.
3. Appliquez ce thème à l'activité de lancement dans AndroidManifest.xml.
4. Initialisez la page de chargement dans MainActivity.
5. Cacher après les tâches de démarrage qui bloquent la première mise en page soient terminées.

A simplifié MainActivity.kt Ce modèle simplifié ressemble souvent à ceci :

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

Cette ligne de code est intentionnellement générique car l'appel exact dépend de la bibliothèque. Le point d'intégration natif est généralement la partie facile. Les erreurs tendent à provenir des ressources et des transitions de thème.

Ici sont les problèmes Android qui se produisent en production :

• Mauvaise correspondance de thème : S'il utilise un fond d'écran différent de la première page de votre application, les utilisateurs voient un éclairage pendant le transfert.
• Conteneurs d'actifs incorrects : Android étirera ou flouera les actifs manquants dans les dossiers de densité attendus.
• Seul test avec Metro : Native resource changes usually need a clean rebuild. Hot reload will not validate launch behavior.
• Règles de lancement Android 12 : Les versions Android plus récentes appliquent leur propre comportement de splash en premier, il faut donc respecter ces contraintes du système d'exploitation.
• Slow JS après cacher : Si React cache la splash avant que la vue racine puisse peindre, les utilisateurs obtiennent une fenêtre blanche au lieu d'une transition fluide.

Cette dernière point compte plus que l'image elle-même. Les problèmes de timing sont généralement perçus comme des problèmes de performance.

Configuration iOS dans un projet nu

Sur iOS, le centre de gravité est LaunchScreen.storyboard plus une petite fonction native dans AppDelegateLa plateforme attend que l'écran de démarrage soit statique et léger. Traitez-le comme une capture de la structure visuelle de la première page, pas comme un mini flux de prise en main.

La configuration fiable ressemble à ceci :

• Ajoutez des assets au catalogue d'assets Xcode.
• Configurez LaunchScreen.storyboard avec des contraintes simples.
• Conservez la disposition statique. Couleur de fond, logo et espacement sûr sont généralement suffisants.
• Ajoutez l'appel de démarrage natif de la bibliothèque AppDelegate.
• Cacher la splash uniquement depuis JavaScript après que l'application soit complètement prête à afficher.

Teams new to iOS often overbuild the storyboard. That usually backfires. Complex constraints, multiple nested views, or attempts to animate the launch screen make the setup harder to maintain and easier to break across device sizes.

Un écran de démarrage simple est une meilleure option.

Bare CLI vous donne plus de contrôle sur la passation de main

C'est la différence clé entre Expo-géré et CLI nu. Expo vous offre un chemin plus rapide vers une configuration par défaut correcte. Le nu vous donne la responsabilité complète de la chaîne de pipeline de démarrage natif.

That trade-off becomes useful when startup is doing more than loading a bundle. Apps with auth restoration, encrypted storage reads, custom native SDK initialization, or white-label branding rules often need the extra control. Bare projects let you align the splash timing with that work instead of forcing everything through higher-level configuration.

Si vous prévoyez d'ajouter une transition animée après le démarrage, gardez la splash native statique et déplacez la motion dans la première écran de React. Les compromis de performance sont similaires à ceux qui importent dans toute voie de démarrage mobile. Le travail lourd pendant la première peinture est coûteux. Cela guide to animation performance in Capacitor apps couvre le même principe à partir d'une autre pile, et la leçon s'applique proprement à React Native.

Expo-géré versus CLI nu

La comparaison pratique est moins axée sur la mise en page des images et plus sur où la complexité de démarrage réside.

Si l'application est déjà dans Expo et que les exigences de lancement sont standard, rester là sauve généralement du temps. Si le chemin d'initialisation dépend de l'ordre d'initialisation natif, de thèmes personnalisés ou de logique de démarrage spécifique au plateau, le CLI nu est souvent la meilleure option à long terme.

Les deux workflows peuvent livrer un écran de démarrage poli. La différence est qui contrôle la chaîne de lancement, votre framework ou votre équipe.

Techniques avancées pour des écrans de démarrage animés et performants

Les écrans d'accueil animés ont l'air soignés lorsqu'ils respectent la chaîne d'initialisation. Ils ont l'air bon marché lorsqu'ils la dérangent.

That’s why I treat animation as an enhancement layer, not the foundation. The first job is still timing. If the app isn’t ready, the splash stays. If the app is ready, the transition should move quickly into the first usable screen.

Animation devrait suivre la réalité de démarrage

Un modèle courant consiste à garder l'animation native simple, puis à exécuter une animation légère personnalisée dans la première écran React après le lancement. Cela vous donne plus de flexibilité que de tenter d'animer la surface de lancement native réelle elle-même.

Lottie est un choix pratique pour ce type de transfert de main car il peut livrer du mouvement sans créer un empilement d'animation personnalisée lourd dans la première écran. La partie importante est la séquence :

• L'animation native reste visible pendant le travail critique de démarrage.
• React monte la première écran réel ou une transition contrôlée.
• L'animation facultative ne joue que si elle ne bloque pas l'interaction plus longtemps que nécessaire.

Ce qui ne fonctionne pas, c'est le modèle setTimeout(2000) Le modèl’ancien. Sur un appareil rapide, cela fait attendre l'application pour rien. Sur un appareil lent, il remplace souvent un état de chargement par un autre.

Traitez le lancement comme une orchestration

Un modèle mental meilleur est démarrage orchestration. L'écran de chargement doit couvrir les tâches exactes qui doivent se terminer avant que l'application puisse afficher du contenu significatif.

That usually includes some mix of:

• Authentification de démarrage : Récupération d'une session ou décision de rediriger vers la page de connexion.
• Accès aux données de stockage essentielles : Thème, langue, état d'abonnement et préférences critiques connues.
• Préparation des polices de caractères : En particulier si la première page dépend de polices personnalisées pour la stabilité de la disposition.
• Configuration distante qui contrôle l'interface utilisateur : Only if the first screen cannot safely render without it.

Existe une autre nuance que de nombreux tutoriels ignorent. Le comportement de l'écran d'accueil change en fonction de l'environnement. La discussion of Expo splash handling in development and production points out that behavior may not appear the same in Expo Go as it does in standalone builds, and that automatic visibility management changes once you take manual control. That’s one reason delay-based examples age badly. They hide the actual startup sequence instead of aligning with it.

A launch screen shouldn’t be used to fake speed. It should be used to prevent users from seeing unfinished UI.

Si vous ajoutez de la motion dans un stack hybride ou évaluez une performance de rendu plus large, this guide to animation performance in Capacitor apps est un contexte utile car la même discipline s'applique. Gardez le travail de démarrage léger, évitez les blocages inutiles et laissez l'animation soutenir la responsivité au lieu de la concurrencer.

One practical note for teams shipping visual fixes outside full binary releases: platforms such as Capgo handle JavaScript, CSS, copy, config, and asset updates for Capacitor and Electron apps, but native splash changes in React Native still belong to the native build pipeline because the true splash screen appears before the JavaScript app is running.

Résolution de Problèmes Courants de l'Ecran d'Attente

Most splash problems fall into a small set of repeat offenders. The fix gets easier once you separate les problèmes d'actifs, les problèmes de timing, et problèmes d'intégration native.

Community patterns across recent React Native guides have converged on the même flux de base : ajoutez la bibliothèque, configurez les actifs de lancement natifs, appelez show during startup, and hide once the app is ready. Android setups commonly involve MainActivity plus de ressources XML ou drawable, tandis que iOS se concentre sur LaunchScreen.storyboard et AppDelegateLa même note d'aperçu indique que Expo recommande un carré 1024×1024 PNG pour les icônes d'applications et que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-app, comme résumé en guide de l'écran d'accueil React Native.

ce guide de l'écran de démarrage React Native

Symptom: Le logo semble flou, coupé ou étrangement échelonné.

La cause : L'image de base n'a pas été exportée correctement, ou la disposition repose sur un raster plein écran qui ne s'adapte pas bien.

Fix: Remplacez l'artwork de style poster par un logo centré sur un fond plat. Réexportez à partir de la source de conception originale, régénérez les densités spécifiques, et vérifiez que vos fichiers Android drawables ou votre catalogue d'actifs iOS contiennent les fichiers attendus.

Écran blanc après la splash masque

Symptôme : La splash native disparaît, puis les utilisateurs voient une fenêtre vide avant la première écran.

La cause : Votre application cache l'écran de démarrage avant que le contenu UI principal ne puisse s'afficher.

Fix: Tie splash dismissal to readiness, not elapsed time. In Expo, that usually means holding the splash until your root view can lay out. In bare projects, use the equivalent pattern and make sure the first rendered screen doesn’t immediately block on more async work.

Ecran d'attente manquant sur une plateforme

Symptôme : Android le montre, iOS non, ou l'inverse.

Cause : One native side wasn’t fully configured. Often it’s a forgotten storyboard reference, theme wiring issue, or asset not added to the correct target.

Solution : Check platform-specific files one by one. On Android, inspect the launch theme and resource references. On iOS, confirm LaunchScreen.storyboardParamètres de catalogue d'actifs et de cibles d'applications dans Xcode.

Build breaks after adding splash configuration

Symptôme : The app stopped compiling after introducing a library or changing splash files.

Cause : Les fichiers du projet natif et la configuration générée peuvent diverger, surtout après des modifications de plugin ou d'actifs.

Fix : Clean the build, reinstall dependencies if needed, and rebuild the native project fully. If you’re in Expo with generated native layers, regenerate carefully and verify plugin config. If you’re in a bare app, review MainActivity, AppDelegate, resource names, and any plist or manifest edits for small mismatches.

The fastest teams treat the splash screen as part of release engineering, not a one-time visual task. That matters even more when startup assets, UI text, or app-shell behavior need to change quickly after launch. Capgo offre à l'équipe Capacitor et Electron un moyen de livrer des fixes JavaScript, CSS, texte, configuration et actifs sur le prochain lancement avec des contrôles de déploiement et un support de retrait, ce qui est utile lorsque le problème se situe dans la couche de l'application plutôt que dans l'écran de démarrage natif lui-même.

Continuez avec L'écran de démarrage dans React Native : Guide complet pour 2026

Si vous utilisez L'écran de démarrage dans React Native : Guide complet pour 2026 planer la média et le comportement d'interface native, connectez-l’avec En utilisant @capgo/capacitor-activités en direct pour la capacité native dans Utiliser @capgo/capacitor-activités en direct, @capgo/capacitor-activités en direct pour le détail d'implémentation dans @capgo/capacitor-activités en direct, Utiliser @capgo/capacitor-joueur de vidéo pour la capacité native dans Utiliser @capgo/capacitor-joueur de vidéo, @capgo/capacitor-joueur de vidéo pour le détail d'implémentation dans @capgo/capacitor-joueur de vidéo, et Utiliser @capgo/capacitor-navigation native pour la capacité native dans Utiliser @capgo/capacitor-navigation native.