Écran de démarrage React Native : configuration Expo et Bare (2026)

Réponse rapide : Utiliser expo-splash-screen avec le plugin de configuration dans app.json ou app.config.js lorsque l’app s’exécute sur Expo (y compris les dev clients et les builds EAS). Appeler SplashScreen.preventAutoHideAsync() dans portée globale, puis SplashScreen.hideAsync() une fois les polices, l’authentification et la navigation prêtes. Sur React Native bare CLI, privilégiez react-native-bootsplash for new work; maintain legacy apps with react-native-splash-screen jusqu’à la migration. Gardez le splash natif statique, masquez-le dès que le premier écran réel peut s’afficher, et passez à splash animé branding dans le premier écran React. Vous construisez plutôt avec des technologies web ? Capacitor utilise @capacitor/splash-screen avec la même règle de disponibilité, et Capgo publie des mises à jour live de la couche web sans build store. Les assets natifs du splash nécessitent toujours un nouveau binaire.

Vous appuyez sur l’icône de votre application sur un appareil réel, et pendant une fraction de seconde, l’utilisateur voit un flash blanc, un logo étiré ou un écran de démarrage figé qui disparaît avant que quelque chose d’utile ne soit prêt. C’est ce vide que le react native splash screen setup est censé combler : l’interface de lancement native jusqu’à ce que JavaScript puisse afficher une première frame stable.

Table des matières

• Pourquoi un splash screen professionnel est essentiel
  • Ce que fait réellement le splash screen
• Préparer des assets de splash screen parfaits
  • Ce qu'il faut préparer avant de coder
  • Erreurs courantes avec les assets
  • Un workflow d'export pratique
• Implémentation avec le workflow Expo Go et Development Client
  • Configurer le splash screen natif de manière déclarative
  • Masquez le splash selon la disponibilité, pas selon le temps
  • Ce à quoi s'attendre avec Expo Go et les dev builds
• Configuration pour les projets Bare React Native CLI
  • Configuration Android dans un projet bare
  • Configuration iOS dans un projet bare
  • Le Bare CLI vous offre plus de contrôle sur le handoff
  • Expo-managed vs bare CLI
• Techniques avancées pour des splash screens animés et performants
  • L'animation doit refléter la réalité du démarrage
  • Considérez le lancement comme une orchestration
• React Native vs Capacitor : splash screens et déploiement de correctifs
  • Les splash screens dans Capacitor
  • Pourquoi les équipes web préfèrent Capacitor à React Native
• Dépannage des problèmes courants de splash screen
  • Image de splash étirée ou floue
  • Écran blanc après la disparition du splash
  • Splash screen manquant sur une plateforme
  • Le build échoue après l'ajout de la configuration splash
• Foire aux questions

Pourquoi un splash screen professionnel est essentiel

Un utilisateur lance votre application depuis l'écran d'accueil, et la séquence de démarrage affiche une image blanche vide avant l'apparition de la première interface. En production, cela passe pour de l'instabilité. Peu importe que React Native charge encore le bundle JavaScript ou restaure l'état en arrière-plan. La première impression est déjà ratée.

Avec React Native, le splash screen est la première surface native que votre application contrôle. Il couvre la transition entre le lancement du processus et la première image utilisable rendue par React. C'est donc un outil de démarrage, pas seulement un élément de branding. Si vous maîtrisez le timing, les utilisateurs voient un lancement stable qui semble maîtrisé. Si vous le masquez trop tôt, ils voient des sauts de mise en page, des polices manquantes ou un écran qui semble figé pendant que l'authentification, la navigation ou la config distante se chargent.

Ce que fait réellement le splash screen

Un splash screen de production doit généralement gérer quatre aspects au démarrage :

• Couvrez le temps de démarrage natif-vers-JS : le chargement des polices, la restauration de session, la lecture des feature flags et l'état de navigation initial se disputent tous la première frame.
• Prévenir les bugs visuels : cela évite les flashs blancs du système, le texte sans style ou une vue racine partiellement montée.
• Maintenir une cohérence visuelle au lancement : la couleur de fond et le logo peuvent s'accorder avec l'app shell pour une transition maîtrisée.
• Forcer des choix de démarrage : les équipes doivent définir ce que signifie « prêt » avant de retirer l'écran de lancement.

Règle pratique : Masquez le splash quand le premier écran réel peut s'afficher proprement, et non après un délai arbitraire.

C'est aussi là que les workflows Expo-managed et bare CLI commencent à diverger. Dans les projets Expo-managed, la configuration du splash est surtout déclarative, et la décision technique principale est de savoir quand appeler le hide API selon l'état de l'app. Dans les projets React Native bare CLI, vous gérez davantage la configuration native sur Android et iOS, ce qui offre plus de contrôle mais aussi plus de façons d'introduire du scintillement au lancement, des incohérences de thème ou des régressions spécifiques aux plateformes.

Ce compromis compte vraiment dans les projets réels. Expo est plus rapide à configurer et plus simple à garder cohérent d'un environnement à l'autre. Les projets Bare sont souvent le bon choix quand l'app dépend déjà de modules natifs personnalisés, d'un comportement de lancement personnalisé ou d'un contrôle plus strict du processus de démarrage.

Les équipes qui considèrent le lancement comme un élément de la qualité produit l'examinent généralement en même temps que le travail UX global, et non comme une tâche native isolée. C'est le même état d'esprit que celui présenté dans Le guide de l’expérience utilisateur d’app de Capgo. Si vous hésitez React Native contre Capacitor pour une app greenfield, lisez Comparaison entre React Native et Capacitor avant de figer vos outils de lancement. Les équipes Capacitor configurent les splash screens dans les projets natifs et avec @capacitor/splash-screen lors de l’initialisation de l’application, comme indiqué dans le guide d’initialisation de l’application Capacitor.

Préparer des assets de splash screen parfaits

La plupart des bugs de splash screen viennent des fichiers de design, pas de code. Si l'asset de base est incorrect, aucun nettoyage du XML Android ou du storyboard iOS ne le sauvera.

L'approche la plus sûre consiste à traiter le splash comme un système de mise en page, et non comme une image plein écran unique. Utilisez une couleur d'arrière-plan avec un logo ou une illustration centrée. Cela s'adapte de façon plus prévisible aux Android à écran allongé, aux iPhone, aux tablettes et aux orientations d'appareil plus larges, plutôt que de vouloir faire tenir partout une seule image détaillée de type affiche.

Ce qu'il faut préparer avant de coder

Commencez par un fichier source propre issu du design. Le vectoriel est idéal pour le handoff, même si l'asset de lancement exporté est un PNG.

Utilisez cette checklist :

• Visuel source : Conservez un logo ou une marque maîtresse en SVG, AI ou tout autre format source éditable pour garantir la cohérence des exports.
• Couleur d'arrière-plan : Définissez précisément la couleur d'arrière-plan du splash screen à l'avance et assurez-vous qu'elle corresponde à l'arrière-plan du premier écran ou de l'app shell.
• Marges de sécurité : Laissez suffisamment d'espace vide autour du logo pour qu'un recadrage agressif sur des ratios inhabituels n'empiète pas sur le design.
• Variantes de plateforme : Exportez les tailles d'image nécessaires à votre workflow plutôt que d'étirer un seul fichier partout.
• Vérification du mode sombre : Si votre application supporte les thèmes sombres, vérifiez que le logo reste bien lisible sur le fond choisi.

Les recommandations d’Expo sont utiles ici : elles rappellent que les assets de lancement font désormais partie du pipeline de build, et non d’un ajout de dernière minute. Sa documentation recommande un PNG carré de 1024×1024 pour les icônes d’application et précise qu’EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-app, ce qui montre comment la génération d'assets est passée à des outils modernes plutôt qu'à une répétition manuelle.

Erreurs courantes avec les assets

Les erreurs visuelles les plus courantes sont prévisibles :

Une image de splash ne doit pas comporter de texte dense, de détails minuscules ni d'arguments marketing. Les écrans de lancement s'affichent brièvement et sont rendus sous des contraintes natives strictes.

Pour les équipes qui publient fréquemment des mises à jour visuelles, la rigueur sur les images compte au-delà du lancement. Les mêmes réflexes s'appliquent aux bundles de livraison et à la taille du binaire, c'est pourquoi des guides comme optimiser les images des mises à jour méritent d'être revues lorsque vous standardisez les exports d'assets.

Un workflow d'export pratique

Une configuration efficace pour des projets réels ressemble à ceci :

1. Concevez une composition centrée sur un fond uni.
2. Exportez un logo PNG transparent si votre workflow permet d'utiliser une couleur de fond distincte.
3. Gardez une nomenclature cohérente sur toutes les plateformes, pour remplacer les assets sans deviner.
4. Testez tôt sur des simulateurs petits et hauts avant de câbler le cycle de vie du splash.
5. Recompiler après modification des assets car les ressources de lancement sont souvent stockées dans les caches natifs.

Ce dernier point compte plus que prévu. De nombreux problèmes d’écran de démarrage qui ressemblent à des erreurs de configuration ne sont en réalité que des assets natifs obsolètes.

Écran de démarrage Expo (expo-splash-screen)

Si vous recherchez écran de démarrage Expo ou écran de démarrage React Native Expo, commencez par le expo-splash-screen package. Il s’adapte aux workflows gérés et prebuild, conserve les assets de lancement dans la config et expose des API JavaScript pour contrôler la visibilité dans les builds store.

Le comportement clé à comprendre est simple. Gardez le splash natif visible jusqu’à ce que la première frame d’UI significative soit prête. Expo documente preventAutoHideAsync() afin que le splash configuré reste affiché jusqu’à ce que vous appeliez hideAsync(). Appelez preventAutoHideAsync() dans le scope global sans await, et non dans un hook, sinon le splash peut se masquer automatiquement avant l’exécution de votre code. Un masquage trop précoce peut exposer brièvement un écran blanc sur iOS et Android.

Maintenir le splash screen pendant le chargement (Expo)

C’est le schéma classique de l’écran de chargement React Native pattern : le splash natif couvre le chargement des polices, l’authentification persistée et la configuration distante pendant que React revient null. Quand isReady passe à true, appelez hideAsync(). L’option SplashScreen.setOptions() ajuste le comportement de fondu au masquage. Testez les assets du splash dans un client de développement, Aperçu, ou Production build ; la doc Expo indique que Expo Go n'est pas l'environnement de référence pour la configuration native du splash screen.

Configurer le splash screen natif de manière déclarative

Dans un projet Expo, la partie visuelle se trouve généralement dans app.json, app.config.js, ou app.config.ts au niveau de la expo-splash-screen plugin de configuration, comme décrit dans Guide de l’écran de démarrage et de l’icône d’app Expo.

Une configuration app.json typique ressemble à ceci :

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

Les champs exacts peuvent varier selon la configuration du projet, mais le principe reste le même. Vous définissez l'apparence du lancement natif dans la config, puis vous contrôlez la visibilité via JavaScript.

Quelques choix pratiques sont importants ici :

• Utilisez une couleur de fond proche de votre écran initial pour que la transition paraisse continue.
• Gardez l'image simple car les écrans de lancement ne sont pas faits pour des visuels trop denses.
• Évitez les faux délais de branding qui bloquent les utilisateurs sur un logo alors que l'app est déjà prête.

Masquez le splash selon la disponibilité, pas selon le temps

Beaucoup de tutoriels font souvent fausse route. Ils utilisent setTimeout, ce qui est facile à démontrer mais incorrect pour la production.

Utilisez plutôt l'état de démarrage. Un modèle courant au niveau racine ressemble à ceci :

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 pattern fiable.

Premièrement, preventAutoHideAsync() est appelé avant que l'app ne commence à rendre une UI significative. Deuxièmement, le masquage n'intervient qu'une fois la vue racine prête pour le layout, ce qui réduit le risque de flash entre le splash natif et l'arbre React.

Ne masquez pas le splash dès que votre travail asynchrone touche à sa fin. Masquez-le quand l'UI qui dépend de ce travail peut réellement s'afficher.

Cette distinction est cruciale quand le démarrage inclut la restauration de l'auth, la configuration distante ou le chargement de polices. Si votre écran d'accueil dépend de polices personnalisées et d'un état connecté, le splash doit combler cette transition.

Voici un guide utile pour explorer l'écosystème de l'atterrissage et du démarrage de React Native :

Ce à quoi s'attendre avec Expo Go et les dev builds

Expo ajoute une complexité supplémentaire. Le comportement du splash screen attendu dans un build autonome peut différer de ce que vous voyez dans Expo Go.

Ce décalage déroute de nombreuses équipes. Vous modifiez l'asset ou la logique de timing, vous testez dans Expo Go, et vous concluez que la configuration est cassée alors que le vrai problème 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 mais il n'est pas la référence finale pour le comportement du splash natif.
• Les clients de développement sont plus proches de la réalité car ils incluent votre projet natif généré.
• Les builds autonomes sont la vérification finale pour le timing du lancement, le comportement du thème et l'exactitude des assets.

Si votre splash clignote ou reste affiché trop longtemps, le bug provient généralement de l'un de ces trois points : une disparition trop précoce, un rendu null trop longtemps après le hide, ou en testant dans un environnement qui ne reflète pas le comportement en release.

Splash screen CLI pour React Native bare

Une application React Native bare vous donne un contrôle direct sur le comportement au lancement. Pour les nouveaux projets bare CLI, react-native-bootsplash est l’option maintenue (releases actives jusqu’en 2026 et alignée sur la politique de support actuelle de React Native). De nombreuses applications en production publient encore react-native-splash-screen; traitez-le comme de la maintenance legacy sauf si vous êtes déjà intégré.

Écran de démarrage animé (React Native ou Expo) : iOS LaunchScreen.storyboard reste statique. Android 12+ peut afficher brièvement une icône vectorielle animée dans l'écran de démarrage système, mais expo-splash-screen and most bare CLI setups still use a PNG statique et transférez l'animation vers le premier écran React (par exemple Lottie). Masquez le splash natif une fois le démarrage terminé, puis lancez l'animation. Voir les performances d'animation dans les apps Capacitor pour appliquer la même discipline de démarrage sur une autre stack.

Dans les projets CLI, l'objectif du handoff natif reste le même : afficher l'UI de lancement immédiatement, puis ne la masquer qu'une fois qu'une UI utile peut s'afficher.

Configuration Android dans un projet bare

La configuration du splash Android se trouve à plusieurs endroits à la fois : les ressources de thème, les drawables, AndroidManifest.xml, et MainActivity. Cette dispersion explique pourquoi de petites erreurs provoquent des flashs visibles.

Le flux habituel est simple :

1. Générez les assets splash pour les dossiers de ressources Android pris en charge.
2. Définissez un thème de lancement avec la bonne couleur d’arrière-plan et le bon drawable splash.
3. Appliquez ce thème à l’activité launcher dans AndroidManifest.xml.
4. Initialisez l’écran splash dans MainActivity.
5. Masquez-le depuis JavaScript une fois les tâches de démarrage bloquant le premier rendu terminées.

Simplifié MainActivity.kt pattern simplifié ressemble souvent à ceci :

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

Cet extrait est volontairement générique, car l’appel exact dépend de la bibliothèque. L’intégration native est généralement la partie facile. Les erreurs viennent souvent des ressources et des transitions de thème.

Voici les problèmes Android qui apparaissent en production :

• Incohérence de thème : Si le thème de lancement utilise une couleur d’arrière-plan différente de votre premier écran, les utilisateurs voient un flash lors du passage de relais.
• Buckets d’assets incorrects : Android étirera ou floutera les assets absents des dossiers de densité attendus.
• Test avec Metro uniquement : Les changements de ressources natives nécessitent généralement un nouveau build propre. Le hot reload ne validera pas le comportement au lancement.
• Règles de lancement Android 12 : Les versions récentes d'Android appliquent d'abord leur propre comportement de splash, les configurations personnalisées doivent donc respecter ces contraintes de plateforme.
• JS lent après le masquage : Si React masque le splash avant que la vue racine puisse s'afficher, les utilisateurs voient une frame blanche au lieu d'une transition fluide.

Ce dernier 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 bare

Sur iOS, le centre de gravité est LaunchScreen.storyboard plus un petit hook natif dans AppDelegate. La plateforme attend un écran de lancement statique et léger. Considérez-le comme un instantané de la structure visuelle du premier écran, pas comme un mini flux d'onboarding.

La configuration fiable se présente ainsi :

• Ajoutez les assets au catalogue d’assets Xcode.
• Configurer LaunchScreen.storyboard avec des contraintes simples.
• Gardez la mise en page statique. La couleur de fond, le logo et des marges de sécurité suffisent généralement.
• Ajoutez l'appel de bootstrap natif de la bibliothèque dans AppDelegate.
• Masquez le splash depuis JavaScript uniquement une fois que l'application est entièrement prête à s'afficher.

Les équipes qui débutent sur iOS surchargent souvent le storyboard. Ça se retourne généralement contre elles. Des contraintes complexes, de multiples vues imbriquées ou des tentatives d'animation de l'écran de démarrage rendent la configuration plus difficile à maintenir et plus fragile selon la taille des appareils.

Un écran de démarrage simple est le choix le plus sûr.

Le Bare CLI vous offre plus de contrôle sur le handoff

C'est la différence clé entre Expo-managed et bare CLI. Expo vous offre un chemin plus rapide vers une configuration par défaut correcte. Bare vous laisse l'entière responsabilité du pipeline de démarrage natif.

Ce compromis devient utile quand le démarrage fait plus que charger un bundle. Les apps qui restaurent l'authentification, lisent un stockage chiffré, initialisent nativement SDK ou appliquent des règles de marque blanche ont souvent besoin de ce contrôle supplémentaire. Les projets bare vous permettent d'aligner le timing du splash sur ce travail au lieu de tout faire passer par une configuration de plus haut niveau.

Si vous prévoyez d'ajouter une transition animée après le lancement, gardez le splash natif statique sur iOS et privilégiez un asset statique sur Android, sauf si vous configurez délibérément l'icône animée d'Android 12. Déplacez l'animation vers le premier écran React. Les compromis de performance sont similaires à ceux qui comptent dans tout chemin de démarrage mobile. Un travail lourd lors du premier rendu coûte cher. Cela guide sur la performance des animations dans les apps Capacitor reprend le même principe sur une autre stack, et la leçon s'applique parfaitement à React Native.

Expo-managed vs bare CLI

La comparaison concrète porte moins sur l'affichage de l'image que sur l'endroit où se situe la complexité du démarrage.

Si l’application est déjà sur Expo et que les exigences de lancement sont standard, y rester fait généralement gagner du temps. Si le chemin de démarrage dépend de l’ordre d’initialisation natif, de thèmes personnalisés ou de logique de démarrage spécifique à la plateforme, le bare CLI est souvent le choix le plus propre à long terme.

Les deux workflows peuvent livrer un splash screen soigné. La différence, c'est qui contrôle le pipeline de lancement : votre framework ou votre équipe.

Techniques avancées pour des splash screens animés et performants

Les splash screens animés paraissent soignés lorsqu'ils respectent le pipeline de démarrage. Ils font bas de gamme lorsqu'ils en détournent l'attention.

C'est pourquoi je considère l'animation comme une couche d'amélioration, et non comme la base. La priorité reste le timing. Si l'app n'est pas prête, le splash reste. Si l'app est prête, la transition doit rapidement mener au premier écran utilisable.

L'animation doit refléter la réalité du démarrage

Une approche courante consiste à garder un splash natif simple, puis à lancer une animation de marque légère sur le premier écran React après le lancement. Cela offre plus de flexibilité que de tenter d'animer directement la véritable surface de lancement native.

Lottie est un choix pratique pour ce type de transition, car il permet d'intégrer du mouvement sans construire une lourde stack d'animation personnalisée dès le premier écran. L'important, c'est le séquençage :

• Le splash natif reste visible pendant les tâches critiques de démarrage.
• React monte le premier véritable écran ou un écran de transition contrôlé.
• L'animation optionnelle ne s'exécute que si elle ne bloque pas l'interaction plus longtemps que nécessaire.

Ce qui ne fonctionne pas, c'est l'ancien setTimeout(2000) schéma. Sur un appareil rapide, cela fait attendre l'app sans raison. Sur un appareil lent, cela ne fait souvent que remplacer un état de chargement par un autre.

Considérez le lancement comme une orchestration

Un meilleur modèle mental : l'orchestration au démarrage. Le splash screen doit couvrir les tâches précises qui doivent être terminées avant que l'app puisse afficher un contenu utile.

Cela inclut généralement un mélange de :

• Bootstrap de l'auth : Restaurer une session ou décider s'il faut rediriger vers la connexion.
• Lectures de stockage essentielles : Thème, locale, état de l'onboarding et dernières préférences critiques connues.
• Polices prêtes : Surtout si le premier écran dépend d'une typographie personnalisée pour stabiliser la mise en page.
• Config distante qui conditionne l'UI : Uniquement si le premier écran ne peut pas s'afficher correctement sans lui.

Il existe une autre nuance que de nombreux tutoriels ignorent. Le comportement du splash screen change selon l'environnement. Le discussion de la gestion du splash screen avec Expo en développement et en production souligne que le comportement peut différer entre Expo Go et les builds standalone, et que la gestion automatique de la visibilité change dès que vous prenez le contrôle manuel. C'est l'une des raisons pour lesquelles les exemples basés sur des délais vieillissent mal. Ils masquent la séquence de démarrage réelle au lieu de s'y aligner.

Un écran de lancement ne devrait pas servir à simuler de la vitesse. Il doit servir à empêcher les utilisateurs de voir une interface inachevée.

Si vous ajoutez du mouvement dans une stack hybride ou si vous évaluez les performances de rendu globales, ce guide sur les performances d'animation dans les apps Capacitor est un contexte utile car la même discipline s'applique. Gardez le travail au démarrage léger, évitez les blocages inutiles et laissez l'animation soutenir la réactivité au lieu de lui faire concurrence.

Une note pratique pour les équipes qui déploient des correctifs visuels en dehors des releases binaires complètes : les plateformes telles que Capgo gèrent les mises à jour du JavaScript, du CSS, du texte, de la config et des assets pour les apps Capacitor et Electron, mais les changements de splash natif dans React Native font toujours partie du pipeline de build natif car le véritable splash screen apparaît avant que l'app JavaScript ne soit lancée.

React Native vs Capacitor : splash screens et déploiement de correctifs

Si vous lisez ceci parce que vous démarrez une nouvelle application, ou parce que votre équipe a déjà une application web en React, Vue, Angular ou Svelte, il est utile de comparer le fonctionnement des splash screens dans Capacitor. Le concept d’écran de démarrage natif est le même, mais le workflow quotidien est plus simple pour les équipes web.

Les splash screens dans Capacitor

Les applications Capacitor utilisent le plugin officiel @capacitor/splash-screen . Vous le configurez une fois dans capacitor.config.ts et le masquez de votre code web lorsque l’application est prête :

// 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()

La règle de préparation de ce guide est identique : gardez le splash natif statique, masquez-le dès que le premier écran réel peut s’afficher, et exécutez toute animation dans le premier écran de votre application. Pour les assets natifs, @capacitor/assets génère les fichiers d’icônes et de splash pour Android et iOS à partir de vos images source (par exemple icon-only.png et splash.png dans un assets dossier). Le processus étape par étape est détaillé dans l'initialisation de l'application Capacitor.

Pourquoi les équipes web préfèrent Capacitor à React Native

• Réutilisez l’application que vous avez déjà : Capacitor enveloppe votre application web existante dans un shell natif : vos composants, votre CSS et vos outils de build continuent de fonctionner. React Native vous oblige à réécrire l’interface en composants React Native.
• Tout framework : React, Vue, Angular, Svelte ou du JavaScript pur : tout fonctionne. Vous n’êtes pas lié à React.
• Accès natif quand vous en avez besoin : les plugins officiels et communautaires couvrent la caméra, les notifications push, la biométrie et bien plus, et vous pouvez écrire votre propre plugin Swift ou Kotlin.
• Live updates pour la couche applicative : par Capgo, vous envoyez aux utilisateurs des correctifs JavaScript, HTML, CSS et assets au prochain lancement, avec des canaux, des déploiements progressifs et un rollback en un clic, sans attendre la revue du store à chaque modification de la couche web. Les changements natifs, y compris l’écran de démarrage natif lui-même, passent toujours par les stores. Voir la documentation des live updates de Capgo.

Pour comparer en détail les performances, l’outillage et l’adéquation avec votre équipe, lisez Comparaison entre React Native et Capacitor. Si vous utilisez Expo aujourd’hui et envisagez un changement, Alternative à Expo passe en revue les options.

Dépannage des problèmes courants de splash screen

La plupart des problèmes de splash screen reviennent toujours aux mêmes causes. La solution devient plus simple dès que l’on distingue les problèmes d’assets, les problèmes de timing, et les problèmes d’intégration native.

Les schémas communautaires des guides récents sur React Native convergent vers le même flux de base : ajouter la bibliothèque, configurer les assets de lancement natifs, appeler show au démarrage, et masquer une fois l’app prête. Les configurations Android impliquent généralement MainActivity ainsi que du XML ou des ressources drawable, tandis qu’iOS mise sur LaunchScreen.storyboard et AppDelegate. Le même aperçu indique qu’Expo recommande un carré PNG de 1024×1024 pour les icônes d’application et qu’EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-app, comme récapitulé dans ce guide sur le splash screen React Native.

Image de splash étirée ou floue

Symptôme : Le logo semble flou, rogné ou mal mis à l'échelle.

Cause : L'image de base n'a pas été exportée correctement, ou la mise en page dépend d'un raster plein écran qui s'adapte mal.

Solution : Remplacez l'illustration de type affiche par un logo centré sur un fond uni. Réexportez depuis la source de design originale, régénérez les assets selon la densité, et vérifiez que vos drawables Android ou votre asset catalog iOS contiennent les fichiers attendus.

Écran blanc après la disparition du splash

Symptôme : Le splash natif disparaît, puis les utilisateurs voient un cadre vide avant le premier écran.

Cause : Votre application masque le splash avant que l'interface racine ne puisse afficher de contenu utile.

Solution : Liez le masquage du splash à l'état de préparation, et non au temps écoulé. Avec Expo, cela signifie généralement maintenir le splash jusqu'à ce que votre vue racine puisse faire son layout. Dans les projets bare, utilisez le pattern équivalent et assurez-vous que le premier écran rendu ne bloque pas immédiatement sur d'autres tâches asynchrones.

Splash screen manquant sur une plateforme

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

Cause : Un côté natif n'était pas entièrement configuré. Il s'agit souvent d'une référence de storyboard oubliée, d'un problème de liaison de thème ou d'un asset non ajouté à la bonne cible.

Solution : Vérifiez les fichiers spécifiques à chaque plateforme un par un. Sur Android, inspectez le thème de lancement et les références de ressources. Sur iOS, confirmez LaunchScreen.storyboard, l'adhésion au catalogue d'assets et les paramètres de la cible de l'app dans Xcode.

Le build échoue après l'ajout de la configuration splash

Symptôme : L'application ne compile plus après l'ajout d'une bibliothèque ou la modification des fichiers splash.

Cause : Les fichiers du projet natif et la configuration générée peuvent se désynchroniser, surtout après des changements de plugins ou d'assets.

Solution : Nettoyez le build, réinstallez les dépendances si nécessaire, puis recompilez entièrement le projet natif. Si vous utilisez Expo avec des couches natives générées, régénérez-les avec précaution et vérifiez la configuration des plugins. Si vous êtes sur une application bare, examinez MainActivity, AppDelegate, les noms de ressources et toute modification de plist ou de manifest pour les petits écarts.

Les équipes les plus rapides traitent l'écran splash comme un élément de l'ingénierie de release, pas comme une tâche visuelle ponctuelle. C'est d'autant plus important quand les assets de démarrage, les textes de l'UI ou le comportement de l'app-shell doivent changer vite après le lancement. Capgo permet aux équipes Capacitor et Electron de déployer des correctifs JS, CSS, de textes, de config et d'assets dès le prochain lancement, avec des contrôles de déploiement progressif et la prise en charge du rollback : utile quand le problème vient de la couche applicative et non de l'écran de lancement natif.

Foire aux questions

Comment ajouter un splash screen dans Expo (expo splash screen) ?
Ajouter le expo-splash-screen plugin pour app.json ou app.config.js, définissez backgroundColor et image, recompiler un binaire natif, appeler preventAutoHideAsync() dans le scope global, et hideAsync() lorsque le premier écran est prêt. Validez dans un client de dev ou un build de production, pas seulement dans Expo Go.

Comment garder l’écran de démarrage visible pendant le chargement de mon app React Native ?
Dans Expo, preventAutoHideAsync() plus le retour null jusqu’à la fin du travail asynchrone, puis hideAsync(). Avec react-native-splash-screen, appelez SplashScreen.show(this) sous Android MainActivity ou [RNSplashScreen show] sur iOS AppDelegate, puis SplashScreen.hide() depuis JavaScript une fois prêt. Avec react-native-bootsplash, initialisez nativement selon la plateforme, puis appelez BootSplash.hide() après le même contrôle de disponibilité.

Quelle est la différence entre react-native-splash-screen et react-native-bootsplash ?
Bootsplash est activement maintenu et fournit un générateur pour les assets de lancement. react-native-splash-screen reste courant dans les anciens dépôts mais reçoit un entretien plus lent ; privilégiez bootsplash pour les nouvelles apps bare CLI.

Comment configurer un écran de démarrage sur React Native natif sans Expo ?
Installer react-native-bootsplash, générer les assets, appeler RNBootSplash.init(this, R.style.BootTheme) sur Android ou RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) sur iOS, puis BootSplash.hide() depuis le JS une fois le démarrage terminé. Les projets legacy peuvent utiliser SplashScreen.show(this) / [RNSplashScreen show] par SplashScreen.hide() à la place. Recompilez après toute modification des assets natifs.

Puis-je utiliser un splash screen animé dans React Native ou Expo ?
Activé iOS, gardez l’écran de lancement statique. Sur Android 12+, le splash système peut afficher une icône animée, mais la plupart des équipes gardent expo-splash-screen ou les assets bootsplash statiques, masquent l’écran une fois prêt, puis animent en React (par exemple avec Lottie). Ne vous fiez pas à setTimeout pour simuler un temps de chargement.

En quoi la configuration du splash screen diffère-t-elle entre React Native et Capacitor ?
React Native utilise expo-splash-screen ou des bibliothèques CLI brutes avant l'exécution du JS. Capacitor utilise des écrans de lancement natifs ainsi que @capacitor/splash-screen dans la pile WebView. Voir Comparaison entre React Native et Capacitor et l'initialisation de l'application Capacitor.

Déployez votre application Capacitor plus vite avec Capgo

Vous développez avec Capacitor, ou vous prévoyez de porter une web app sur mobile ? Créez un compte Capgo gratuit et déployez votre premier live update en quelques minutes. Capgo livre les correctifs JavaScript, CSS et d'assets à vos utilisateurs dès le prochain lancement, avec des déploiements progressifs et un rollback instantané, pour qu'un bug dans votre couche applicative n'ait jamais à attendre la validation des stores.

Continuer depuis React Native Splash Screen (Expo et CLI bare)

Si vous utilisez ce guide pour planifier le comportement des médias et de l'interface natifs, connectez-l’à Utiliser @capgo/capacitor-live-activities pour la capacité native dans Utiliser @capgo/capacitor-live-activities @capgo/capacitor-live-activities pour le détail d'implémentation dans @capgo/capacitor-live-activities Utiliser @capgo/capacitor-video-player pour la fonctionnalité native dans la section Utiliser @capgo/capacitor-video-player, @capgo/capacitor-video-player pour les détails d'implémentation dans @capgo/capacitor-video-player, et Utilisation de @capgo/capacitor-native-navigation pour la fonctionnalité native dans Using @capgo/capacitor-native-navigation.