Vous appuyez sur l'icône de votre application sur un appareil réel, et pendant une fraction de seconde, l'utilisateur obtient une flèche blanche, un logo étiré ou un écran de démarrage figé qui disparaît avant que quelque chose d'utile 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 de démarrage dans React Native répare plus que la marque. Il couvre l'écart entre le démarrage natif et le premier cadre React significatif. Il oblige également à réfléchir clairement à l'ordre de démarrage, à la préparation des actifs et à la différence entre ce qui se passe dans Expo Go, un client de développement, et une mise en magasin réelle. Si vous faites erreur sur le timing, les utilisateurs voient les fissures immédiatement.
Table des Matières
- Pourquoi un écran de démarrage professionnel compte
- Préparer des actifs d'écran de démarrage parfaits
- Implémenter avec le workflow de l'application Expo Go et du client de développement
- Configuration pour les projets React Native Bare CLI
- Le projet Bare __CAPGO_KEEP_0__ vous donne plus de contrôle sur la transmission
- Résolution des problèmes courants de l'écran de démarrage
Pourquoi un écran de démarrage professionnel compte
Un utilisateur appuie sur votre application depuis l'écran d'accueil, et la séquence de lancement 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, pas seulement un bien de marque. Si vous le synchronisez bien, les utilisateurs voient un lancement stable qui ressemble à une intention. Si vous le cachez trop tôt, ils voient des déplacements de mise en page, des polices manquantes ou une écran mort pendant que l'authentification, la navigation ou la configuration à distance rattrape.
Ce que l'écran de démarrage fait réellement
L'écran de démarrage de production doit généralement gérer quatre préoccupations de démarrage :
- Masquerer le travail de démarrage natif vers JS : La charge de police, la restauration de session persistante, la lecture des drapeaux de fonctionnalité et l'état de navigation initial se disputent tous la première frame.
- Prévenir les glissades visuelles : elle évite les flashes de blanc du système, le texte non stylisé ou la vue racine partiellement montée.
- Conserver l'apparence de lancement cohérente : la 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 signifie « prêt » avant de supprimer l'écran de lancement.
Règle pratique : Cachez l'écran de lancement lorsque la première écran réelle peut s'afficher proprement, et non après un délai arbitraire.
This is also where the Expo-managed and bare CLI workflows start to diverge. In Expo-managed projects, splash setup is mostly declarative, and the main engineering decision is when to call the hide API based on app readiness. In bare React Native CLI projects, you own more native setup on Android and iOS, which gives you more control but also more ways to introduce launch flicker, theme mismatches, or platform-specific regressions.
Cette trade-off compte dans les projets réels. Expo est plus rapide à configurer et plus facile à maintenir cohérent à travers les environnements. Les projets sans abri sont souvent la bonne choix lorsque l'application dépend déjà de modules natifs personnalisés, d'un comportement de lancement personnalisé ou d'un contrôle plus strict sur le chemin de démarrage.
Les équipes qui traitent le lancement 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 une tâche native isolée. C'est le même esprit qui est abordé dans Capgo’s guide to app user experience. Si vous évaluez également la pile React Native plus large pour une nouvelle application ou une migration, solutions Nerdify pour les applications React Native offre un aperçu produit axé sur la production.
Préparer les Atouts Parfaits de l'Ecran de Chargement
Most splash screen bugs start in design files, not code. If the base asset is wrong, no amount of Android XML or iOS storyboard cleanup will save it.
L'approche la plus sûre est de traiter l'écran de chargement comme un système de disposition, et non comme une image d'écran unique. 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 dans tous les endroits.
Ce à quoi se préparer avant de coder
Commencez avec un fichier source vierge issu de la conception. Le vecteur est idéal pour le transfert, même si l'actif de lancement exporté est un PNG.
Utilisez ce tableau de vérification :
- Artwork source : Conservez un logo maître ou marque en format SVG, AI ou autre format source éditable afin que les exports restent cohérents.
- Couleur de fond : Définissez la couleur de fond exacte de l'avant-plan dès le début et assurez-vous qu'elle correspond à la première écran ou à la coque d'application.
- Marges sûres : Laissez suffisamment d'espace vide autour du logo pour éviter que la mise en page ne soit coupée par des ratios d'aspect inhabituels.
- Variantes de plateforme : Exportez les tailles d'image nécessaires à votre flux de travail, plutôt que de les étirer partout.
- Examen de la mode sombre : Si votre application prend en charge les surfaces sombres, confirmez que le logo reste clair 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 construction, et non une pensée après coup. un carré de 1024 x 1024 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 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.
Les erreurs courantes d'actifs
Les échecs visuels les plus courants sont prévisibles :
| Problème | Cause probable | Approche améliorée |
|---|---|---|
| Logo flou | Exporté d'une image raster à faible résolution | Exporté à partir d'une résolution raster basse ; |
| Bords coupés | Artwork placé trop près des limites | Augmenter la marge de sécurité |
| Étirement | Image plein écran imposée à de nombreux rapports d'aspect | Utiliser une couleur de fond plus une image centrée |
| Transition incohérente | Fond d'écran de démarrage diffère de la première écran | Align launch and app shell colors |
Une image d'accueil ne doit pas comporter de texte dense, de détails minuscules ou de publicité. Les écrans de démarrage sont affichés brièvement et rendus sous des contraintes natives serrées.
For teams shipping frequent visual updates, image discipline matters beyond launch. The same habits apply to delivery bundles and binary size, which is why guides like optimiser les images pour les mises à jour sont dignes d'être examinés lors de la standardisation des exportations d'actifs.
Un workflow d'exportation pratique
Un ensemble de paramètres fonctionnant bien dans les projets réels ressemble à ceci :
- Concevez une composition centrée sur un fond uni.
- Exportez un logo PNG transparent si votre workflow prend en charge une couleur de fond séparée.
- Maintenez la cohérence des noms sur plusieurs plateformes afin d'éviter les suppositions.
- Testez sur les simulateurs petits et grands tôt avant de brancher la vie du cycle de splash.
- Rebâtissez après les changements d'actifs car les ressources de lancement sont souvent stockées dans des caches natifs.
Cela compte plus que ce que l'on pense. Beaucoup d'erreurs de splash screen qui ressemblent à des bugs de configuration sont simplement des assets natifs obsolètes.
Implémenter avec le flux de travail du client de développement et d'Expo Go
Si vous utilisez Expo, commencez par expo-splash-screenIl convient à la gestion gérée, garde la plupart de la configuration déclarative et vous donne un contrôl’explicite sur quand le splash doit disparaitre.
Le comportement clé à comprendre est simple. Conservez la splash native visible jusqu'à ce que le premier cadre UI significatif soit prêt. Expo's SplashScreen API supporte exactement ce modèl’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 builds iOS et Android, comme documenté dans le Ecran d'accueil Expo API.
Configurez l'écran d'accueil 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 typique app.json Un modèle typique ressemble à ceci :
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}La disposition exacte peut 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 comptent ici :
- Utilisez une couleur de fond proche de votre écran initial pour que la transition se sente continue.
- Gardez l'image simple car 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.
Masquer le splash en fonction de la disponibilité, pas du temps.
Beaucoup de tutoriels se trompent souvent. Ils utilisent setTimeout, qui est facile à démontrer et incorrect pour la production.
Utilisez l'état de démarrage au lieu de cela. Un modèle de base 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.
Premièrement preventAutoHideAsync() is called before the app starts rendering meaningful UI. Second, the hide happens only after the root view is ready to lay out, which reduces the chance of a flash between the native splash and the React tree.
N'occultez pas l'écran de chargement lorsque votre travail asynchrone commence à se terminer. Cachons-le lorsque l'interface utilisateur qui dépend de ce travail peut vraiment s'afficher.
Ne cachez pas le splash lorsque votre travail asynchrone commence à se terminer. Cacher-le lorsque l'interface utilisateur qui dépend de ce travail peut vraiment s'afficher.
Voici une vue d'ensemble utile du plus large écosystème de démarrage et de landing React Native ci-dessous :
What to expect in Expo Go and dev builds
Expo ajoute une complexité supplémentaire. Le comportement de la splash que vous attendez dans une build standalone 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 cassé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 natif de la splash.
- Les clients de développement sont plus proches de la réalité car ils incluent votre projet natif généré.
- Les builds standalone sont la vérification finale 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 cacher, ou tester dans un environnement qui ne reflète pas le comportement de la mise en production.
Configuration pour les projets React Native sans enveloppe CLI
Un projet React Native sans enveloppe 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ôl’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.
In CLI projets, je recommande généralement react-native-bootsplash pour le nouveau travail. Il convient mieux aux projets React Native actuels que les anciens bibliothèques d'écran 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-screendonc 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 seulement après que l'application puisse afficher une interface utilisateur significative.
Configuration Android dans un projet sans enveloppe
Android splash setup lives in a few places at once: theme resources, drawables, AndroidManifest.xml, and MainActivityC'est pourquoi de petites erreurs créent des éclairs visibles.
Le flux habituel est clair et direct.
- Générez les assets de splash pour les dossiers de ressources Android que vous prenez en charge.
- Définissez un thème de lancement avec la bonne couleur de fond et le drawable de splash.
- Appliquez ce thème à l'activité de démarrage dans
AndroidManifest.xml. - Initialisez l'écran de splash dans
MainActivity. - Cacherez-le depuis JavaScript après les tâches de démarrage qui bloquent la première mise à jour.
Une simplification MainActivity.kt Ce modèle ressemble souvent à ceci :
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}That snippet is intentionally generic because the exact call depends on the library. The native integration point is usually the easy part. The mistakes tend to come from resources and theme transitions.
Voici les problèmes Android qui apparaissent en production :
- Incompatibilité de thème : Si le thème de lancement utilise une couleur de fond différente de celle de votre première page d'application, les utilisateurs voient une lueur pendant le transfert.
- Conteneurs d'actifs incorrects : L'Android étirera ou flouera les actifs manquants dans les dossiers de densité attendus.
- Test avec Metro uniquement : Native resource changes usually need a clean rebuild. Hot reload will not validate launch behavior.
- Règles de lancement Android 12 : Les versions Android plus récentes appliquent leur propre comportement de splash avant que les paramètres personnalisés ne puissent s'appliquer.
- JS lent après la mise à l'écart : Si React cache le splash avant que la vue racine puisse peindre, les utilisateurs obtiennent une fenêtre vide 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
Le centre de gravité est situé au LaunchScreen.storyboard Sur iOS, le centre de gravité est AppDelegate. The platform expects the launch screen to be static and lightweight. Treat it like a snapshot of the first screen’s visual structure, not a mini onboarding flow.
La configuration fiable ressemble à ceci :
- Ajoutez les actifs à la bibliothèque d'actifs Xcode.
- Configurez
LaunchScreen.storyboardavec des contraintes simples. - Conservez la disposition statique. La couleur de fond, le logo et l'espace sécurisé 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 à afficher.
Teams new to iOS often overbuild the storyboard. That usually backfires. Complex constraints, multiple nested views, or attempts to animate the launch screen make the setup harder to maintain and easier to break across device sizes.
Un écran de démarrage simple est une meilleure option.
Bare CLI vous offre plus de contrôle sur la transmission de l'écran.
C'est la différence clé entre les projets Expo gérés et les projets CLI nu. Expo vous offre un chemin plus rapide vers une disposition par défaut correcte. Les projets nu vous donnent la responsabilité complète de la chaîne de pipeline de démarrage natif.
Cet échange de valeur 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 branding blanc sur blanc nécessitent souvent un 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 de React. Les compromis de performance sont similaires à ceux qui importent dans tout chemin de démarrage mobile. Le travail lourd pendant la première peinture est coûteux. Ce guide pour la performance d'animation dans les applications Capacitor aborde le même principe à partir d'une autre pile, et la leçon se transfère nettement vers React Native.
Expo-géré par rapport à CLI bare
La comparaison pratique est moins axée sur la mise en page des images et plus sur où la complexité de démarrage se situe.
| Point de décision | Expo-géré | CLI bare |
|---|---|---|
| Rapid configuration | Mise en place initiale plus rapide | Plus de travail natif |
| Personnalisation native | Plus de contraintes | Contrôle total |
| Flux de génération d'actifs | Plus déclaratif | Plus manuel |
| Surface de débogage | JS config plus couche native générée | Fichiers Android et iOS directs |
| Best fit | Équipes optimisant la vitesse et la cohérence | Équipes nécessitant un contrôle natif approfondi |
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, CLI est souvent la solution plus propre à long terme.
Les deux workflows peuvent déployer une écran de démarrage poli. La différence est qui contrôle la chaîne de lancement, votre framework ou votre équipe.
Techniques avancées pour des écrans d'accueil animés et performants
Les écrans d'accueil animés ont l'air soignés lorsqu'ils respectent la pipeline de démarrage. Ils ont l'air bon marché lorsqu'ils distraient de celle-ci.
C'est pourquoi je traite l'animation comme une couche d'amélioration, et non 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 doit se déplacer rapidement vers la première écran utilisable.
L'animation doit suivre la réalité de démarrage
Un modèle courant est de garder l'écran d'accueil natif simple, puis de lancer une animation légère personnalisée dans le premier écran React après le démarrage. Cela vous donne plus de flexibilité que de tenter d'animer la surface de lancement native réelle elle-même.
Lottie est une choix pratique pour ce type de transfert car il peut livrer du mouvement sans créer un empilement d'animation personnalisée lourd dans le premier écran. La partie importante est la séquence :
- L'écran d'accueil 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.
Cela ne fonctionne pas est le modèle setTimeout(2000) 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.
Traitez le démarrage comme une orchestration
A un modèle mental plus performant est l'orchestration du démarrage. La page de chargement doit couvrir les tâches exactes qui doivent être terminées avant que l'application puisse afficher du contenu significatif.
Ce qui inclut généralement une combinaison de :
- Authentification de démarrage : Récupération d'une session ou décision de rediriger vers la page de connexion.
- Accès aux lectures de stockage essentiel : Thème, langue, état de l'inscription et préférences critiques connues.
- Préparation des polices : Même si la première page repose sur une typographie personnalisée pour une stabilité de mise en page.
- Configuration distante qui contrôle l'interface utilisateur : Seulement si la première page ne peut pas rendre en toute sécurité sans cela.
Existe une autre nuance que de nombreux tutoriels manquent. Le comportement de l'écran de démarrage dépend de l'environnement. Le Analyse de la gestion de l'écran de démarrage d'Expo en développement et en production. met en évidence 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 mise en attente vieillissent mal. Ils masquent la séquence de démarrage réelle au lieu de s'aligner sur elle.
Une page de démarrage ne doit pas être utilisée pour simuler la rapidité. Elle doit être utilisée 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 de l'animation dans les applications Capacitor est un contexte utile car la même discipline s'applique. Gardez le travail de démarrage maigre, évitez les blocages inutiles et laissez l'animation soutenir la responsivité au lieu de la concurrencer.
Une note pratique pour les équipes qui délivrent des correctifs visuels en dehors de mises à jour binaires complètes : les plateformes comme Capgo gèrent les mises à jour de JavaScript, CSS, copie, configuration et ressources pour les applications Capacitor et Electron, mais les changements d'écran de démarrage natifs dans React Native appartiennent toujours au pipeline de construction natif car l'écran de démarrage réel apparaît avant que l'application JavaScript ne soit en cours d'exécution.
Résolution des problèmes courants de l'écran de démarrage
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 problèmes d'actifs, problèmes de timing, et problèmes d'intégration native.
La communauté a adopté un modèle répandu dans les dernières guides React Native : ajouter la bibliothèque, configurer les actifs de démarrage natifs, appeler show dans le démarrage, et masquer une fois l'application prête. Les configurations Android impliquent généralement MainActivity plus des ressources XML ou drawable, tandis que iOS se concentre sur LaunchScreen.storyboard , et AppDelegate. La même vue d'ensemble note que Expo recommande un carré 1024×1024 PNG pour les icônes d'applications et que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-app, comme résumé dans ce guide de l'écran de démarrage React Native.
image d'écran étirée ou floue
Symptôme : Le logo semble doux, 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.
Solution : 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 attendus.
Écran blanc après que l'écran de démarrage se cache
Symptôme : L'écran de démarrage natif disparaît, puis les utilisateurs voient une fenêtre vide avant la première écran.
Cause : Votre application cache le splash avant que le contenu UI principal ne puisse s'afficher.
Fix : Tie splash dismissal to readiness, not elapsed time. In Expo, that usually means holding the splash until your root view can lay out. In bare projects, use the equivalent pattern and make sure the first rendered screen doesn’t immediately block on more async work.
Écran d'accueil manquant sur une plateforme
Symptom: Splash écran manquant sur une plateforme
Symptôme : Une côté native n'était pas complètement configuré. Souvent, c'est une référence à un storyboard oubliée, un problème de câblage de thème ou un asset non ajouté au bon cible.
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 LaunchScreen.storyboardUne partie native n'était pas correctement configurée.
Build breaks after adding splash configuration
Symptôme : L'application s'est arrêtée de compiler après avoir introduit une bibliothèque ou changé les fichiers de splash.
Cause : Les fichiers de projet natif et la configuration générée peuvent diverger, surtout après des modifications de plugins 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 des plugins. Si vous êtes dans une application nue, passez en revue MainActivity, AppDelegate, noms de ressources, et toute modification de plist ou de manifeste pour de petites incohérences.
The fastest teams treat the splash screen as part of release engineering, not a one-time visual task. That matters even more when startup assets, UI text, or app-shell behavior need to change quickly after launch. Capgo 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.
une façon de continuer depuis L'écran de splash dans React Native : Guide complet pour 2026
Si vous utilisez Ecran de chargement dans React Native : Guide complet pour 2026 pour planifier les médias et le comportement de l'interface native, connectez-l’avec En utilisant @capgo/capacitor-activités en direct pour la capacité native dans En utilisant @capgo/capacitor-activités en direct, @capgo/capacitor-activités en direct pour le détail d'implémentation dans @capgo/capacitor-activités en direct, En utilisant @capgo/capacitor-joueur de vidéo pour la capacité native dans En utilisant @capgo/capacitor-joueur de vidéo, @capgo/capacitor-joueur de vidéo pour le détail d'implémentation dans @capgo/capacitor-joueur de vidéo, et En utilisant @capgo/capacitor-navigation native pour la capacité native dans En utilisant @capgo/capacitor-navigation native.
