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

Vous appuyez sur l'icône de votre application sur un appareil réel, et pendant une fraction de seconde, l'utilisateur voit une petite fenêtre blanche, 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 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 lacune entre le démarrage natif et le premier cadre React rendu utile. 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 faites erreur sur la synchronisation, les utilisateurs voient les fissures immédiatement.

Table des matières

• Pourquoi un écran d'accueil professionnel est important
  • Ce que fait vraiment l'écran d'accueil
• Préparer des actifs d'écran d'accueil parfaits
  • Ce que préparer avant de coder
  • Erreurs courantes sur les actifs
  • Flux de travail d'exportation pratique
• Mise en œuvre avec le workflow de l'écran d'accueil et du client de développement Expo Go
  • Configurer l'écran d'accueil natif de manière déclarative
  • Masquer le splash en fonction de la disponibilité, et non en fonction du temps
  • Ce que vous pouvez attendre dans Expo Go et les builds de développement
• Configuration pour les projets React Native Bare CLI protégés
  • Configuration Android dans un projet Bare
  • Configuration iOS dans un projet Bare
  • Bare CLI vous donne plus de contrôle sur la transmission
  • Expo géré par rapport à Bare CLI
• Techniques avancées pour les écrans splash animés et performants
  • L'animation doit suivre la réalité de lancement
  • Traiter le lancement comme une orchestration
• Résoudre les problèmes courants des écrans splash
  • Image d'écran stretchée ou floue
  • Ecran blanc après la splash se cache
  • Écran splash manquant sur une plateforme
  • La construction se brise après l'ajout de la configuration splash

Pourquoi un écran splash professionnel compte

Un utilisateur appuie sur votre application depuis 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 splash est la première surface native que votre application contrôle. Il recouvre la transition 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 mise en route stable qui ressemble à une intention. Si vous le cachez trop tôt, ils voient des déplacements de layout, des polices manquantes ou une écran mort pendant que l'authentification, la navigation ou la configuration distante rattrape.

Ce que l'écran splash fait réellement

Un écran splash de production doit généralement gérer quatre préoccupations de démarrage :

• Couvrir le travail de démarrage native vers JS : chargement de polices, restauration de session persistante, lecture de drapeaux de fonctionnalité et état de navigation initial se disputent tous la première frame.
• Empêcher les bugs visuels : il évite les éclairs de texte non stylisé, de la vue racine partiellement chargée ou de la couleur de fond blanche du système.
• Maintenez la mise en page visuelle cohérente : le code couleur de fond et le logo peuvent correspondre à votre coquille d'application pour que la transition se sente contrôlée.
• Forcer 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 : Cachez l'écran de démarrage 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-gérés et les workflows CLI sans Expo commencent à diverger. Dans les projets Expo-gérés, la configuration de l'écran de démarrage est principalement déclarative, et la décision principale de l'ingénieur est de savoir quand appeler la fonction de masquage API en fonction de la prêt de l'application. Dans les projets React Native sans Expo CLI , vous gérez plus de la mise en œuvre native sur Android et iOS, ce qui vous donne plus de contrôle mais aussi plus de moyens de faire apparaître des éclairs de démarrage, des incohérences de thème ou des régressions spécifiques au plateau.

Ce compromis compte dans les projets réels. Expo est plus rapide à configurer et plus facile à maintenir cohérent à travers les environnements. Les projets sans Expo 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 faisant partie de la qualité du produit le reviennent généralement en même temps que le travail de UX plus large, et non comme une tâche native isolée. C'est le même esprit que celui 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, Des solutions Nerdify pour les applications React Native donne un aperçu utile axé sur la production.

Préparation des Attributs de Splash Screen Parfaits

La plupart des bogues de splash screen commencent dans les fichiers de conception, pas code. Si l'atout de base est incorrect, aucun montant d'Android XML ou d'iOS storyboard de nettoyage ne pourra le sauver.

L'approche la plus sûre est de considérer la 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'appareil plus larges que d'essayer de faire tenir une affiche détaillée en un seul endroit.

Ce à quoi se préparer avant de coder

Commencez avec un fichier source propre depuis la conception. Le vecteur est idéal pour la main levée, même si l'atout de lancement exporté est un PNG.

Utilisez ce tableau de bord :

• Artwork source : Conservez un logo maître ou une marque 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 de l'écran d'accueil exacte dès le début et assurez-vous qu'elle correspond à la couleur de fond de l'écran ou de la coque d'application.
• Marges sûres : Laissez suffisamment d'espace vide autour du logo afin que la mise en forme agressive sur des ratios d'aspect inhabituels ne coupe pas dans la conception.
• Variantes de plateforme : Exportez les tailles d'image dont votre flux de travail a besoin, plutôt que de faire étirer un seul fichier partout.
• Examen de la mode sombre : Si votre application prend en charge les surfaces sombres, confirmez que le logo reste lisible contre le fond choisi.

La guidance 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 production, et non une pensée après-coup. Ses documents recommandent un carre 1024×1024 PNG pour les icônes d'application et notent que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-appLes erreurs de mise en page les plus courantes sont prévisibles :

Les erreurs de mise en page les plus courantes

Le problème le plus courant

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, c'est pourquoi des guides comme optimiser les images pour les mises à jour sont dignes d'être consultés lors de la standardisation des exportations d'actifs.

Un workflow d'exportation pratique

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

1. Concevez une composition centrée. sur un fond uni.
2. Exporter un logo PNG transparent. si votre flux de travail prend en charge une couleur de fond séparée.
3. Considérez la cohérence des noms. à travers les plateformes afin que les échanges d'actifs ne deviennent pas des conjectures.
4. Testez sur les simulateurs petits et hauts tôt. avant de brancher le cycle de vie de l'écran d'accueil.
5. Rebâtissez après les modifications des actifs. car les ressources de lancement sont souvent stockées dans des caches natifs.

Cette dernière considération compte plus que ce que les gens attendent. Beaucoup d'issues d'écran d'accueil qui ressemblent à des bogues de configuration sont simplement des actifs natifs périmés.

Implémentez avec le flux de travail de l'Expo Go et du Client de Développement

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

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 supporte exactement ce modèle avec preventAutoHideAsync() à 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 le Expo splash screen API.

Configurez le splash natif de manière déclarative

Dans un projet Expo, la partie visuelle vit généralement dans app.json ou app.config.js.

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

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

Les 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 configuration, 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 car les surfaces d'appel ne sont pas le lieu de l'artwork dense.
• Évitez les « retards de marquage fictifs » qui maintiennent les utilisateurs sur un logo lorsque l'application est déjà prête.

Cacherez la splash en fonction de la disponibilité, et non en fonction du temps.

Beaucoup de tutoriels se perdent en chemin. 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 de niveau racine courant 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() 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, ce qui réduit la chance d'un flash entre l'écran de démarrage natif et l'arbre React.

N'oubliez pas de cacher l'écran de démarrage 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 signé-in, l'écran de démarrage devrait couvrir cette lacune.

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

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

Expo ajoute une complication supplémentaire. Le comportement de l'écran de démarrage que vous attendez dans une build autonome peut ne pas correspondre à ce que vous voyez dans Expo Go.

Cette incohérence confond beaucoup d'équipes. Vous modifiez la logique des actifs ou du 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 la splash native.
• 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 du thème et la correction des actifs.

Si votre splash continue à clignoter ou à rester, 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'arrêt, 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 nue vous donne un contrôle direct sur le comportement de lancement, ce qui est utile une fois que l'écran 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 implique une responsabilité native. Vous devez connecter 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 œuvre native est plus facile à raisonner lors des mises à niveau. Les anciens applications expédient toujours avec react-native-splash-screen, donc vous allez y rencontrer lors des travaux de maintenance, mais pour un nouveau setup, l'objectif reste le même. Afficher une surface de lancement native immédiatement, puis la cacher uniquement après que l'application puisse rendre une interface utilisateur significative.

Configuration Android dans un projet nu

La configuration de l'écran de splash Android vit dans quelques endroits à la fois : les ressources de thème, les drawables, AndroidManifest.xml, et MainActivity. Cette division est pourquoi les petites erreurs créent des éclairs visibles.

Le flux habituel est direct :

1. Générez des atouts de splash pour les dossiers de ressources Android que vous supportez.
2. Définez un thème de lancement avec la couleur de fond correcte et le drawable de splash.
3. Appliquez ce thème à l'activité de lancement dans AndroidManifest.xml.
4. Initialisez l'écran de splash dans MainActivity.
5. Cachez-le après les tâches de démarrage qui bloquent la première mise en page sont terminées.

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

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

Ce morceau 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.

Voici les problèmes Android qui se produisent en production :

• Incohérence 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.
• Bacs d'actifs incorrects : Android étirera ou flouera les actifs qui manquent des dossiers de densité attendus.
• Testez uniquement avec Metro : Les changements de ressources natives nécessitent généralement une reconstruction propre. La reprise chaude ne valide pas le comportement de lancement.
• 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 de plateforme pour les configurations personnalisées.
• JS lent après cacher : Si React cache le splash avant que la vue racine puisse peindre, les utilisateurs obtiennent une fenêtre blanche au lieu d'une transition fluide.

Cette dernière considération 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 s'attend à ce 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.
• Maintenez la disposition statique. La couleur de fond, le logo et l'espace sécurisé sont généralement suffisants.
• Ajoutez l'appel de démarrage natif de la bibliothèque en AppDelegate.
• Cachez le splash uniquement depuis JavaScript après que l'application soit complètement prête à afficher.

Les équipes nouvelles à iOS ont souvent tendance à surconstruire l'histoire de bord. Cela se retourne souvent contre elles. Les contraintes complexes, les vues imbriquées multiples ou les tentatives d'animation de l'écran de démarrage rendent la configuration plus difficile à maintenir et plus facile à briser sur les tailles d'appareil.

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

Le CLI nu vous donne plus de contrôle sur la transmission de données

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

Ce compromis devient utile lorsque le démarrage fait plus que charger un bundle. Les applications avec la restauration d'authentification, les lectures de stockage chiffré, l'initialisation de SDK natif personnalisée ou les règles de marquage blanc de la marque nécessitent souvent le contrôle supplémentaire. Les projets nu vous permettent d'aligner la synchronisation du splash 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, maintenez le splash natif statique et déplacez la motion dans la première écran React. Les compromis de performance sont similaires à ceux qui importent dans tout chemin de démarrage mobile. Ce guide sur la performance de l'animation dans les applications Capacitor couvre le même principe depuis une autre pile, et la leçon s'applique de manière propre à React Native.

Expo-géré versus CLI non géré

La comparaison pratique est moins axée sur la mise en page d'image 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 du démarrage 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 lissé. La différence est qui contrôle la pipeline 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 lissés lorsqu'ils respectent la pipeline de démarrage. Ils ressemblent à des écrans bon marché lorsqu'ils distraient de celle-ci.

That’s why I consider l’animation as a layer of enhancement, 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.

L’animation doit suivre la réalité de démarrage

Un modèle courant est de garder l’affichage de splash 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 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’affichage de splash natif 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 ancien. Sur un appareil rapide, cela fait attendre l’application pour rien. Sur un appareil lent, cela remplace souvent un état de chargement par un autre. setTimeout(2000) Considérez le lancement comme une orchestration

Un modèle mental meilleur est l’orchestration de démarrage

__CAPGO_KEEP_0__ __CAPGO_KEEP_0__. La page de démarrage 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 page de connexion.
• Lecture de stockages essentiels : Thème, langue, état d'abonnement et préférences critiques connues.
• Préparation de polices : Surtout 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 : Seulement si la première page ne peut pas rendre en toute sécurité sans cela.

Il y a une autre nuance que de nombreux tutoriels manquent. Le comportement de la page de démarrage change en fonction de l'environnement. La discussion du traitement de la page de démarrage d'Expo en développement et en production pointe que le comportement peut ne pas apparaître de la même manière dans Expo Go que dans les builds standalone, 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 delay vieillissent mal. Ils masquent 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 un UI non terminé.

Si vous ajoutez de la motion dans un stack hybride ou évaluez la performance de rendu plus large, ce guide à la performance d'animation dans les applications Capacitor 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.

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

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

La plupart des problèmes de splash se répartissent en un petit ensemble de récidivistes. La correction devient plus facile une fois que vous séparez les problèmes d'assets, les problèmes de timinget les problèmes d'intégration native protégés.

Les modèles de communauté dans les guides React Native récents convergent vers le même flux de base : ajouter la bibliothèque, configurer les actifs de lancement natifs, appeler show au démarrage, et masquer une fois l'application prête. Les configurations Android impliquent généralement MainActivity ou les ressources XML ou drawable, tandis que iOS se concentre sur LaunchScreen.storyboard et AppDelegate. La même vue souligne que Expo recommande un carré 1024×1024 PNG pour les icônes d'application et que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-app, comme résumé dans ce guide de l'écran de démarrage React Native.

l'image d'écran étirée ou floue

Symptôme : Le logo semble flou, coupé ou étrangement agrandi.

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.

Réparation : 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 actifs spécifiques à la densité et vérifiez que vos fichiers Android drawables ou votre catalogue d'actifs iOS contiennent les fichiers souhaités.

Écran blanc après que le splash se cache

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

Cause : Votre application cache le splash avant que l'interface utilisateur de base puisse afficher du contenu significatif.

Réparation : Tie the splash dismissal à la disponibilité, et non au temps écoulé. Dans Expo, cela signifie généralement conserver le splash jusqu'à ce que votre vue racine puisse s'organiser. Dans les projets bare, utilisez le modèle équivalent et assurez-vous que la première écran affiché 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 native n'était pas complètement configurée. C'est souvent une référence storyboard oubliée, un problème de mise en page de thème ou un élément non ajouté à la cible correcte.

Solution : Vérifiez les fichiers spécifiques à la plateforme les uns après les autres. Sur Android, inspectez le thème de lancement et les références de ressources. Sur iOS, confirmez la pertinence de l'élément dans le catalogue d'actifs et les paramètres de cible de l'application dans Xcode. LaunchScreen.storyboardLa compilation échoue après avoir ajouté une configuration d'écran de splash

Symptôme :

L'application a cessé de compiler après avoir introduit une bibliothèque ou changé les fichiers d'écran de splash. __CAPGO_KEEP_0__

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: Nettoyez la construction, réinstallez les dépendances si nécessaire, et reconstruisez 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 MainActivity, AppDelegateLes équipes les plus rapides traitent l'écran de démarrage comme une partie de l'ingénierie de la mise en production, et non comme une tâche visuelle unique. 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_KEEP_0__ fournit à Capgo et aux équipes Electron un moyen de livrer des correctifs JavaScript, CSS, copie, configuration et actifs sur le prochain lancement avec des contrôles de déploiement et un support de reversion, 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. 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.

Si vous utilisez

L'écran de démarrage dans React Native : Guide complet pour 2026 pour planifier le comportement de la média et de l'interface native, connectez-le avec __CAPGO_KEEP_0__ Utiliser @capgo/capacitor-activités-en-vrai-temps pour la capacité native dans Utiliser @capgo/capacitor-activités-en-vrai-temps @capgo/capacitor-activités-en-vrai-temps pour le détail d'implémentation dans @capgo/capacitor-activités-en-vrai-temps Utiliser @capgo/capacitor-lecteur-de-videos pour la capacité native dans Utiliser @capgo/capacitor-lecteur-de-videos @capgo/capacitor-lecteur-de-videos pour le détail d'implémentation dans @capgo/capacitor-lecteur-de-videos, et Utiliser @capgo/capacitor-navigation-native pour la capacité native dans Utiliser @capgo/capacitor-navigation-native.