Écran d'accueil dans React Native : Guide complet pour 2026

Lorsque vous appuyez sur l'icône de votre application sur un appareil réel, l'utilisateur voit pendant une fraction de seconde une flèche blanche, un logo étiré ou un écran de démarrage bloqué qui disparaît avant que quoi que ce soit d'utile ne soit prêt. C'est généralement le moment où une application React Native cesse de ressembler à une application de production.

Un bon écran d'accueil dans React Native répare plus que la marque. Il couvre la période entre le démarrage natif et le premier cadre React significatif. Il oblige également à réfléchir de manière claire à l'ordre de démarrage, à la préparation des assets 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 avez mal calculé ce timing, les utilisateurs voient les fissures immédiatement.

Table des Matières

• Pourquoi une écran d'accueil professionnel est important
  • Ce que fait vraiment l'écran d'accueil
• Préparer les Atouts Parfaits de l'Ecran d'Accueil
  • Ce que préparer avant de coder
  • Les erreurs courantes des atouts
  • Un flux de travail d'export pratique
• Implémenter avec le Workflow de l'Ecran d'Accueil et du Client de Développement Expo Go
  • Configurer l'écran d'accueil natif de manière déclarative
  • Cacher l'écran d'accueil en fonction de la disponibilité, et non du temps
  • Ce que vous pouvez attendre dans les builds Expo Go et de développement
• Configurer pour les Projets React Native Bare CLI
  • Configuration Android dans un projet vierge
  • Configuration iOS dans un projet vierge
  • Un projet vierge CLI vous donne plus de contrôle sur la passation de main
  • Expo-géré par rapport à un projet vierge CLI
• Techniques avancées pour les écrans de démarrage animés et performants
  • L'animation doit suivre la réalité de démarrage
  • Traiter le lancement comme une orchestration
• Dépannage des problèmes courants des écrans de démarrage
  • Image d'écran de démarrage étirée ou floue
  • Écran blanc après que l'écran de démarrage se cache
  • Manque d'écran de démarrage sur une plateforme
  • La construction échoue après avoir ajouté la configuration de l'écran de démarrage

Why a Splash Screen Professionnel Compte

Un utilisateur appuie sur votre application à partir de l'écran d'accueil, et la séquence de démarrage montre une fenêtre blanche vide avant que le premier UI apparaisse. En production, cela se lit comme une 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.

Dans React Native, l'écran de démarrage est la première surface native que votre application contrôle. Il recouvre la passation de charge entre le démarrage du processus et le premier cadre React affiché. Cela le rend un outil de démarrage, et non seulement un atout de branding. Si vous le synchronisez bien, les utilisateurs voient une démarrage stable qui ressemble à une intention. Si vous le masquez trop tôt, ils voient des déplacements de mise en page, des polices manquantes ou une écran mort pendant l'authentification, la navigation ou la configuration à distance se rattrape.

Ce que fait vraiment l'écran de démarrage

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

• Couvrir le travail de démarrage natif vers JS : le chargement de polices, la restauration de session persistante, la lecture de drapeaux de fonctionnalité et l'état de navigation initial se disputent tous la première frame.
• Prévenir les bugs visuels : il évite les éclairs de blanc système, du texte non stylisé ou une vue racine partiellement montée.
• Maintenir la démarrage visuellement cohérent : la couleur de fond et le logo peuvent correspondre à la coque de l'application pour que la transition ressemble à une action contrôlée.
• Force les décisions de démarrage : les équipes doivent définir ce que « prêt » signifie avant de supprimer l'écran de démarrage.

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

C'est également là où les workflows Expo-managés et les workflows CLI bare commencent à diverger. Dans les projets Expo-managés, la configuration du splash est principalement déclarative, et la décision principale de l'ingénierie est quand appeler la fonction de masquage API en fonction de la prêt de l'application. Dans les projets React Native CLI bare, vous avez plus de contrôle sur la mise en œuvre native sur Android et iOS, ce qui vous donne plus de contrôle mais aussi plus de moyens de présenter des claquements de démarrage, des incohérences de thème ou des régressions spécifiques au plateau.

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 démarrage personnalisés ou d'un contrôle plus strict sur le chemin de démarrage.

Les équipes qui traitent le démarrage comme une partie de la qualité du produit le reviennent généralement en même temps que le travail UX plus large, et non comme un tâche native isolée. C'est le même esprit couvert dans le guide de Capgo à l'expérience utilisateur de l'application. Si vous évaluez également la pile React Native plus large pour une nouvelle application ou une migration, les solutions Nerdify pour les applications React Native offrent un aperçu utile axé sur la production.

Préparer les Attributs de l'écran de démarrage parfait

La plupart des bogues d'écran de splash commencent dans les fichiers de conception, pas code. Si l'actif de base est incorrect, aucune quantité d'Android XML ou de storyboard iOS de nettoyage ne pourra le sauver.

La meilleure approche est de considérer l'écran de splash comme un système de disposition, et non une seule image d'écran complète. Utilisez une couleur de fond plus 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'appareils plus larges que de tenter de faire tenir une image d'affiche détaillée en tout lieu.

Ce à quoi se préparer avant de coder

Commencez par un fichier source propre depuis la conception. Le vecteur est idéal pour la transmission, même si l'actif de lancement exporté est un PNG.

Utilisez ce checklist :

• Artwork source : Conservez un logo ou une marque maître en SVG, AI ou un autre format source éditable afin que les exports restent cohérents.
• Couleur de fond : Définissez la couleur de fond exacte de l'écran de splash à l'avance et assurez-vous qu'elle correspond à la première page ou à la coque d'application.
• Marges de sécurité : Laissé 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 : Exporter les tailles d'image dont votre flux de travail a besoin, plutôt que de les étirer partout.
• Examen de la mode sombre : Si votre application prend en charge les surfaces sombres, confirmez que le logo est encore 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. Un carré de 1024x1024 PNG pour les icônes d'applications et note que EAS Build peut générer les tailles requises pour les projets créés avec __CAPGO_KEEP_0__ 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 visuels

Les plus courantes échecs visuels sont prévisibles :

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

Pour les équipes qui livrent des mises à jour visuelles fréquentes, la discipline de l'image compte au-delà du lancement. Les mêmes habitudes s'appliquent aux envois de bundles et à la taille des fichiers binaires, ce qui est pourquoi des guides comme optimiser les images pour les mises à jour sont utiles à consulter lors de la standardisation des exports d'actifs.

Un workflow d'export pratique

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

1. Concevoir une composition centrée sur un fond uni.
2. Exporter un logo PNG transparent Si votre workflow prend en charge une couleur de fond séparée.
3. Gardez les noms cohérents à travers les plateformes afin que les échanges d'actifs ne deviennent pas des conjectures.
4. Testez sur des simulateurs petits et grands tôt avant de brancher le cycle de vie de la splash.
5. Rebâtissez après les changements d'actifs car les ressources de lancement sont souvent stockées dans des caches natifs.

Ce dernier point compte plus que les gens ne l'attendent. Beaucoup d'issues de la splash screen qui ressemblent à des bogues de configuration sont simplement des actifs natifs périmés.

Mise en œuvre avec le workflow de l'Expo Go et du Client de Développement

Si vous utilisez Expo, commencez par expo-splash-screenCela convient au workflow géré, garde la plupart de la configuration déclarative et vous donne un contrôle explicite sur le moment où la splash doit partir.

La clé de comportement à comprendre est simple. Conservez l'écran de démarrage natif visible jusqu'à ce que le premier cadre UI significatif soit prêt. Expo's SplashScreen API preventAutoHideAsync() supporte exactement ce modèle à l'initialisation et hideAsync() une fois la charge critique terminée, et Expo avertit que cacher trop tôt peut brièvement exposer une écran vide dans les deux builds iOS et Android, comme documenté dans l' écran de démarrage Expo API.

Configurez l'écran de démarrage natif de manière déclarative

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

Un setup typique ressemble à ceci : app.json Expo’s

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

The champs exacts peuvent varier en fonction de la configuration du projet, mais le modèle reste le même. Vous définissez l'apparence de lancement natif dans la config, puis contrôlez la visibilité à partir de JavaScript.

Quelques choix pratiques sont importants ici :

• Utilisez une couleur de fond proche de votre écran initial afin que la transition se sente continue.
• Gardez l'image simple puisque les surfaces de lancement ne sont pas le lieu pour des œuvres d'art dense.
• Évitez les « retards de marquage fictifs » qui maintiennent les utilisateurs sur un logo lorsque l'application est déjà prête.

Cacher le splash en fonction de la disponibilité, et non en fonction du temps

Beaucoup de tutoriels se trompent souvent. Ils utilisent setTimeoutqui est facile à démontrer et incorrect pour la production.

Utilisez l'état de démarrage au lieu de cela. Un modèle courant de 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 modèle fiable.

Tout d’abord, preventAutoHideAsync() __CAPGO_KEEP_0__ est appelé avant que l’application ne commence à afficher une interface utilisateur significative.

Ensuite, la cacher se produit uniquement après que la vue racine soit prête à organiser les éléments, ce qui réduit la chance d’un éclair entre l’écran de splash natif et l’arbre React.

N’effacez pas l’écran de splash lorsque votre travail asynchrone commence à se terminer. Cacher-le lorsque l’interface utilisateur qui dépend de ce travail peut vraiment s’afficher.

Cette distinction compte le plus lorsque le démarrage inclut la restauration d’authentification, la configuration à distance ou le chargement de polices.

Si votre écran d’accueil dépend de polices personnalisées et d’un état connecté, l’écran de splash doit couvrir cette lacune.

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

Ce que vous pouvez attendre dans Expo Go et les builds de développement

Expo ajoute une complexité supplémentaire. Le comportement de l’écran de splash que vous attendez dans une build autonome peut ne pas correspondre à ce que vous voyez dans Expo Go.

• Ce désaccord confond beaucoup d’équipes. Vous modifiez l’asset ou la logique de timing, 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, mais ce n’est pas l’autorité finale sur le comportement de l’écran de splash natif.
• Les clients de développement sont plus proches de la réalité car ils incluent votre projet native généré.
• Les builds autonomes sont la dernière vérification pour le timing de lancement, le comportement de la thématique et la correction des actifs.

Si votre splash continue de clignoter ou de s'éterniser, le bug est généralement l'un des trois choses : cacher trop tôt, rendre null pour trop longtemps après la mise à l'obscurité, ou tester dans un environnement qui ne reflète pas le comportement de la mise en ligne.

Configuration pour les projets React Native Bare CLI

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

Dans les projets CLI , je recommande généralement react-native-bootsplash pour de nouveaux travaux. Il convient mieux aux projets React Native actuels que les anciens bibliothèques de splash, et la mise en place native est plus facile à raisonner pendant les mises à niveau. Les anciens applications continuent de livrer avec react-native-splash-screen, donc vous rencontrerez cela dans le travail de maintenance, mais pour un setup frais, l'objectif reste le même. Montrez une surface de lancement native immédiatement, puis cachez-la uniquement après que l'application puisse rendre une interface utilisateur significative.

Configuration Android dans un projet vierge

La configuration de l'écran d'accueil Android se trouve dans plusieurs endroits à la fois : les ressources de thème, les drawables, et . C'est pourquoi de petites erreurs créent des éclairs visibles. AndroidManifest.xmlLe flux habituel est direct : MainActivityGénérez les atouts de l'écran d'accueil pour les dossiers de ressources Android que vous supportez.

Définez un thème de lancement avec la couleur de fond correcte et le drawable de l'écran d'accueil.

1. Appliquez ce thème à l'activité de lancement dans
2. Initialisez l'écran d'accueil dans
3. Cacherez-le depuis JavaScript après les tâches de démarrage qui bloquent la première mise à jour. AndroidManifest.xml.
4. Un modèle simplifié MainActivity.
5. se présente souvent sous cette forme :

__CAPGO_KEEP_0__ MainActivity.kt __CAPGO_KEEP_1__

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

That snippet 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 la plus facile. Les erreurs tendent à provenir des ressources et des transitions de thème.

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

• Erreur de thème : Si le thème de lancement utilise une couleur de fond différente de votre première écran d'application, les utilisateurs voient un flash lors de la prise en main.
• Conteneurs d'actifs incorrects : Android étirera ou flouera les actifs qui manquent dans les dossiers de densité attendus.
• Test avec Metro uniquement : Les modifications des ressources natives nécessitent généralement une reconstruction propre. La rechargement chaud ne valide pas le comportement de lancement.
• Règles de lancement Android 12 : Les versions Android plus récentes appliquent d'abord leur propre comportement de splash, donc les paramétrages personnalisés doivent respecter ces contraintes de plateforme.
• JS lent après la mise à l'écran : Si React cache le splash avant que la vue racine puisse peindre, les utilisateurs obtiennent un cadre vide au lieu d'une transition fluide.

Cela 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 vierge

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

La configuration fiable ressemble à ceci :

• Ajoutez des actifs au catalogue d'actifs 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.
• Insérez l'appel de démarrage natif de la bibliothèque dans AppDelegate.
• Cacher le splash uniquement depuis JavaScript après que l'application soit complètement prête à rendre.

Les équipes nouvelles à iOS ont souvent tendance à surconstruire l'histoire de l'application. Cela se retourne souvent contre elles.

Une écran de démarrage simple est la meilleure option.

Le CLI sans décorations vous donne plus de contrôle sur la transmission de données.

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

Cette compensation devient utile lorsque l'application fait plus que charger un bundle. Les applications avec la restauration d'authentification, les lectures de stockage chiffré, l'initialisation de SDK natif personnalisé ou les règles de branding blanc sur blanc ont souvent besoin de ce contrôle supplémentaire. Les projets non décorés vous permettent d'aligner la synchronisation de l'écran de démarrage avec ce travail au lieu de forcer tout à travers une configuration de niveau supérieur.

Si vous prévoyez d'ajouter une transition animée après le démarrage, gardez l'écran de démarrage natif statique et déplacez la motion dans la première écran de React. Les compromis de performance sont similaires à ceux qui comptent dans tout chemin de démarrage mobile. Guide à la performance de l'animation dans les applications Capacitor Cette comparaison pratique est moins liée à la mise en page des images et plus liée à où la complexité du démarrage se situe.

Expo-managed versus bare CLI

__CAPGO_KEEP_0__ Expo-géré

Si l'application est déjà en 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 bare est souvent la meilleure option à long terme.

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

Techniques avancées pour des écrans d'accueil animés et performants

Les écrans d'accueil animés ressemblent à des écrans d'accueil poli lorsqu'ils respectent la chaîne d'initialisation. Ils ressemblent à des écrans d'accueil bon marché lorsqu'ils distraient de celle-ci.

C'est pourquoi je traite l'animation comme une couche d'amélioration, et non comme la base. Le premier travail est toujours la synchronisation. Si l'application n'est pas prête, l'écran d'accueil reste. Si l'application est prête, la transition devrait se déplacer rapidement vers la première écran utilisable.

L'animation doit suivre la réalité de l'initialisation

Un modèle courant est de garder l'écran d'accueil natif simple, puis de lancer 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 natif vraie elle-même.

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

• Le splash natif reste visible pendant le travail critique de démarrage.
• React monte la première écran réel ou un écran de transition contrôlé.
• 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 vieux setTimeout(2000) pattern. Sur un appareil rapide, cela fait attendre l'application pour aucune raison. Sur un appareil lent, cela remplace souvent un état de chargement par un autre.

Traitez le lancement comme une orchestration

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

Cela inclut généralement une combinaison de :

• Authentification de démarrage : Récupération d'une session ou décision de routage vers la connexion.
• Accès aux lectures de stockage essentielles : Thème, localisation, état de configuration et dernières préférences critiques connues.
• Préparation de la police : En particulier si la première écran dépend de la typographie personnalisée pour la stabilité de la disposition.
• Configuration à distance qui gère l'interface utilisateur : Seulement si la première écran ne peut pas rendre en toute sécurité sans cela.

Il y a une autre nuance que de nombreux tutoriels manquent. Le comportement de l'écran d'accueil change en fonction de l'environnement. La discussion du traitement de l'écran d'accueil d'Expo en développement et en production souligne que le comportement peut ne pas apparaître de la même manière dans Expo Go que dans les builds autonomes, et que la gestion automatique de la visibilité change une fois que vous prenez le contrôle manuel. C'est une raison pour laquelle les exemples basés sur la mise en attente vieillissent mal. Ils cachent la séquence de démarrage réelle au lieu de s'aligner sur elle.

Un écran de lancement ne doit pas être utilisé pour simuler la vitesse. Il doit être utilisé pour empêcher les utilisateurs de voir une interface utilisateur non terminée.

Si vous ajoutez de la motion dans un empilement hybride ou évaluez une performance de rendu plus large, cette guide à la performance de l'animation dans les applications Capacitor est utile en raison du contexte 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 contredire.

Une note pratique pour les équipes qui expédient des correctifs visuels en dehors des mises à jour binaires complètes : les plateformes telles que Capgo gèrent les mises à jour de JavaScript, CSS, de la copie, de la configuration et des actifs pour Capacitor et les applications Electron, mais les changements de splash natifs dans React Native appartiennent encore au pipeline de construction native car l'écran splash réel apparaît avant que l'application JavaScript ne soit en cours d'exécution.

Résoudre les problèmes courants de l'écran splash

La plupart des problèmes d'écran splash se classent dans un petit ensemble de récidivistes. La correction devient plus facile une fois que vous séparez les problèmes d'actifs, les problèmes de timing, et les problèmes d'intégration native.

Les modèles de la communauté dans les guides React Native récents se sont concentrés sur le même flux de base : ajouter la bibliothèque, configurer les actifs de lancement natifs, appeler show au cours du démarrage, et masquer une fois que l'application est prête. Les configurations Android sont couramment impliquées MainActivity plus les ressources XML ou drawable, tandis que iOS se concentre sur LaunchScreen.storyboard et AppDelegateLa même note d'aperçu indique que Expo recommande une icône carrée 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 le résume ce guide de l'écran de démarrage React Native.

Image d'écran étirée ou floue

Symptôme : L'icône a l'air molle, coupée ou étrangement échelonnée.

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'affiche par un logo centré sur un fond plat. Réexportez à partir de la source de conception originale, régénérez les actifs spécifiques à la densité et vérifiez que vos fichiers Android drawables ou votre catalogue d'actifs iOS contiennent les fichiers prévus.

Écran blanc après la splash cache

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

Cause: Votre application cache la splash avant que l'UI de base puisse rendre un contenu significatif.

Fix: Attachez la disparition de la splash à la disponibilité, et non à la durée. Dans Expo, cela signifie généralement garder la splash jusqu'à ce que votre vue de base puisse organiser l'espace. Dans les projets bare, utilisez le modèle équivalent et assurez-vous que la première écran rendu ne bloque pas immédiatement sur plus de travail asynchrone.

Écran de splash manquant sur une plateforme

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

Cause : Une partie du côté natif n'était pas configurée en entier. Il s'agit souvent d'une référence à un storyboard oubliée, d'une question de câblage de thème ou d'un élément non ajouté à la cible correcte.

Fix : Vérifiez les fichiers spécifiques à la plateforme un par un. Sur Android, inspectez le thème de démarrage et les références aux ressources. Sur iOS, confirmez la pertinence de l'asset catalog, ainsi que les paramètres de cible de l'application dans Xcode. LaunchScreen.storyboardBuild breaks after adding splash configuration

Symptom :

L'application s'est arrêtée de compiler après avoir introduit une bibliothèque ou modifié les fichiers de splash. Cause :

Les fichiers du projet natif et les configurations générées peuvent diverger, surtout après des modifications de plugins ou d'éléments. Fix :

Nettoyez la build, réinstallez les dépendances si nécessaire, et rebuild le projet natif en entier. Si vous êtes dans Expo avec des couches natives générées, régénérez avec soin et vérifiez la configuration du plugin. Si vous êtes dans une application nue, passez en revue Cause: __CAPGO_KEEP_0__ wasn’t fully configured. Often it’s a forgotten __CAPGO_KEEP_1__ reference, __CAPGO_KEEP_2__ wiring issue, or __CAPGO_KEEP_3__ not added to the correct target. MainActivity, AppDelegateLes meilleures équipes considèrent l'écran de démarrage comme faisant partie de l'ingénierie de la mise en production, et non comme une tâche visuelle ponctuelle. Cela compte encore plus lorsque les actifs de démarrage, le texte de l'interface utilisateur ou le comportement de la coquille de l'application doivent changer rapidement après le lancement.

Les équipes qui traitent rapidement l'écran de démarrage comme faisant partie de l'ingénierie de la mise en production, et non comme une tâche visuelle ponctuelle. Cela compte encore plus lorsque les actifs de démarrage, le texte de l'interface utilisateur ou le comportement de la coquille de l'application doivent changer rapidement après le lancement. Capgo gives Capacitor and Electron teams a way to ship JavaScript, CSS, copy, config, and asset fixes on the next launch with rollout controls and rollback support, which is useful when the problem is in the app layer rather than the native launch screen itself.

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

Si vous utilisez Écran de démarrage dans React Native : Guide complet pour 2026 pour planifier les médias natifs et le comportement de l'interface utilisateur, connectez-le avec Utilisez @capgo/capacitor-live-activités pour la capacité native dans Utilisez @capgo/capacitor-live-activités @capgo/capacitor-live-activités pour le détail d'implémentation dans @capgo/capacitor-live-activités, En utilisant @capgo/capacitor-player vidéo natif pour la capacité native dans En utilisant @capgo/capacitor-player vidéo natif @capgo/capacitor-player vidéo natif pour le détail d'implémentation dans @capgo/capacitor-player vidéo natif, et En utilisant @capgo/capacitor-navigation native pour la capacité native dans En utilisant @capgo/capacitor-navigation native.