Qu'est-ce que React Native ?

Qu'est-ce que React Native ?

React Native est un framework mobile cross-platform qui permet aux développeurs de construire des apps iOS et Android en utilisant JavaScript et React. La sortie est de vrais binaires natifs — pas des web views dans un wrapper. Les composants UI se mappent à des widgets natifs spécifiques à la plateforme (UIKit sur iOS, Views Android sur Android), et votre JavaScript tourne sur un thread séparé qui communique avec l'UI native via un bridge ou, dans les versions plus récentes, le plus efficace JSI (JavaScript Interface).

Créé par Facebook (maintenant Meta) en 2015 depuis un projet de hackathon, React Native a résolu une vraie douleur : la même équipe produit devant expédier et maintenir deux codebases complètement séparés pour iOS (Swift/Objective-C) et Android (Kotlin/Java). Avec React Native, ~85-95% du code est partagé. Les gros utilisateurs en production incluent les apps propres de Meta, Microsoft Office mobile, Discord (à l'origine), Shopify, Coinbase et l'app de Walmart — aux côtés de milliers d'apps plus petites.

Comment fonctionne React Native (l'architecture)

Le modèle mental :

• Thread JavaScript. Votre code React Native tourne ici. Les règles standard de rendu React s'appliquent — arbre de composants, state, effects.
• Thread UI natif. Rend les widgets de plateforme réels (UIView sur iOS, View sur Android). Le thread JS ne touche pas ça directement ; il envoie des instructions.
• Bridge / JSI. La couche de communication entre les deux threads. Le "bridge" original (jusqu'à ~2022) sérialisait les messages en JSON — lent pour les animations et éléments interactifs. La nouvelle architecture JSI (par défaut dans React Native moderne) donne à JavaScript un accès synchrone direct aux modules natifs, dramatiquement plus rapide.
• Modules natifs. Code spécifique à la plateforme (Swift, Kotlin) accessible depuis JavaScript. Utilisez ceux-ci pour les choses que React Native n'expose pas par défaut — Bluetooth, APIs de caméra natives, auth biométrique.

Le résultat : l'UI a l'air et le ressenti natifs (parce qu'elle L'EST), les animations peuvent atteindre 60fps sur du matériel moderne, et la majorité de la logique d'application reste dans le codebase JavaScript partagé.

Ce pour quoi React Native est bon

• Développement UI cross-platform. Un codebase JavaScript, vraies UIs natives sur les deux plateformes. Le ratio de code partagé est véritablement élevé (typiquement 85-95%).
• Hot reload et itération rapide. Les changements de code apparaissent dans l'app en cours dans les secondes. Le développement natif avec rebuilds complets Xcode/Android Studio prend des minutes par itération.
• Expertise React existante. Les équipes web utilisant React peuvent expédier mobile sans apprendre Swift ou Kotlin de zéro. Le modèle mental React se transfère directement.
• Mises à jour over-the-air. Des outils comme EAS Update d'Expo (ou CodePush, déprécié en 2024 mais encore utilisé) vous permettent de pousser des mises à jour JS-only sans passer par la review App Store / Play Store. Corrections de bugs critiques en heures, pas semaines.
• La plupart des catégories d'app. Apps CRUD, apps sociales, e-commerce, apps de contenu, outils de productivité — tous de bons fits.

Là où React Native lutte

• Apps performance-intensives. AR/VR, graphiques avancés, visualisation complexe de données en temps réel, logique de jeu lourde — celles-ci ont souvent besoin de code natif. Le bridge JS (ou même JSI) ajoute du overhead qui compte au bord.
• Fonctionnalités UI natives qui retardent par rapport à la plateforme. Quand iOS ou Android expédient de nouvelles APIs (ex. Vision Pro, nouveaux composants Material 3), React Native prend souvent des mois pour les exposer. Les développeurs natifs les expédient le jour un.
• Taille d'app plus grande. Le bundling du runtime JavaScript ajoute 5-15 Mo à votre binaire. Compte pour les utilisateurs des marchés émergents avec des plans stockage/données stricts.
• Débogage à travers le bridge. Quand quelque chose crash, le stack trace peut couvrir JS, le code de bridge natif et le code de plateforme. L'outillage s'est amélioré (Flipper, React DevTools) mais c'est plus dur que du natif pur.
• Déclin de l'écosystème de librairies. Beaucoup de librairies React Native sont abandonnées ou non maintenues. Tout ce qui n'est pas officiellement supporté par Expo ou l'équipe core de Meta a un risque élevé.

React Native vs Flutter vs Natif

Les trois chemins principaux de développement mobile en 2026 :

• React Native : JavaScript + React, vrais widgets natifs. Meilleur pour les équipes avec expertise React existante. Mature, mais l'architecture a évolué à travers la douleur.
• Flutter : Langage Dart + moteur de rendu custom (pas de widgets natifs, dessine tout lui-même). Pixel-parfait à travers les plateformes mais ressenti légèrement moins "natif". Croît vite avec le fort investissement de Google.
• Natif (Swift/Kotlin) : Deux codebases. Performance la plus haute, fonctionnalités de plateforme les plus récentes le jour un. Meilleur pour les équipes riches en ressources expédiant de l'UX spécifique à la plateforme ou des apps performance-critiques.

La règle 80/20 : la plupart des apps produit n'ont pas besoin de performance native. React Native ou Flutter économise assez de temps d'ingénierie pour justifier les (petits) compromis.

React Native et Expo

Expo est un framework managé par-dessus React Native qui gère les parties les plus douloureuses : infrastructure de build, mises à jour OTA, modules natifs, notifications push, splash screens. La meilleure pratique moderne est "commencez avec Expo sauf si vous avez une raison spécifique de ne pas" — même les projets dirigés par Meta utilisent de plus en plus l'outillage d'Expo. Le compromis : Expo empaquette un ensemble fixe de modules natifs, donc si vous avez besoin de quelque chose qu'ils n'expédient pas, vous éjectez vers React Native nu.

Gotchas courants de React Native

• Différences UI iOS et Android subtiles. Le même composant React rend légèrement différemment sur chaque plateforme — rendu de texte, comportement de scroll, couleurs par défaut. Testez sur les deux ; ne supposez pas la parité.
• La gestion des permissions diffère. iOS demande les permissions au premier usage ; Android les pré-demande souvent dans le manifest. L'API React Native lisse ça mais n'unifie pas complètement le comportement.
• La navigation est une librairie séparée. React Native n'expédie pas d'opinion. React Navigation est le standard de facto, mais l'API est large et a des breaking changes entre versions majeures.
• Le déploiement iOS requiert un Mac. Pas moyen d'y échapper — construire des bundles iOS pour l'App Store requiert Xcode, qui ne tourne que sur macOS. Les équipes Linux/Windows utilisent des services de build cloud (EAS Build, Bitrise) pour iOS.
• Les crash logs nécessitent un upload de symboles. Les crashes React Native peuvent être durs à lire sans uploader des source maps à votre reporter de crashes (Sentry, Crashlytics). Facile à oublier ; cher à déboguer sans.

FAQ : React Native

React Native est-il toujours pertinent en 2026 ?

Oui. La réécriture d'architecture (renderer Fabric + JSI) expédiée en 2023-2024 a adressé des problèmes de performance de longue date. Des apps majeures (Meta, Microsoft, Shopify) maintiennent activement les investissements React Native. L'outillage d'Expo a rendu l'onboarding beaucoup plus fluide. Le mobile cross-platform est un marché en état stationnaire et React Native est l'un des deux leaders aux côtés de Flutter.

Quelle est la différence entre React Native et React (web) ?

Même core React (composants, state, hooks), différents targets de rendu. React pour le web rend à des éléments DOM (<div>, <span>). React Native rend à des primitives UI natives (<View>, <Text>). Vous partagez la logique de composants et la gestion d'état ; les composants UI eux-mêmes ne sont pas directement partagés entre web et mobile (utilisez React Native Web si vous voulez partager l'UI, avec des caveats).

Puis-je partager du code entre web (React) et mobile (React Native) ?

Logique métier, hooks et gestion d'état : oui, facilement. Composants UI : seulement avec React Native Web (rend les composants RN sur le web). Beaucoup d'équipes prennent une approche de partage 60-70% — partagent la logique, écrivent l'UI spécifique à la plateforme pour chaque target.

React Native est-il bon pour les apps performance-sensitives ?

De plus en plus oui. La nouvelle architecture (Fabric + JSI, par défaut depuis RN 0.74) a significativement réduit le overhead du bridge. Pour AR/VR, animations complexes à 120fps ou rendu 3D, le natif gagne toujours. Pour la plupart des apps produit, React Native est assez rapide pour que la performance ne soit pas le limiteur.

Combien de temps faut-il pour construire une app React Native ?

Setup initial (Expo) : 1-2 jours pour une app qui tourne avec auth et quelques écrans. Équivalent natif pur : 1-2 semaines. L'accélération cross-platform compose — ce qui prend 4 mois en natif pur prend 2-3 en React Native pour des apps produit typiques.

Puis-je migrer une app native existante vers React Native ?

La migration incrémentale est possible — React Native supporte l'embedding dans une app native existante (intégration "brownfield"). Beaucoup de grandes apps (Microsoft Office, Walmart) ont utilisé cette approche. C'est dur mais faisable ; budgetez des mois, pas des semaines.

Comment LoadFocus teste les apps React Native

Les apps React Native qui parlent à des backends (95%+ d'entre elles) ont besoin de monitoring d'API et de tests de charge. Le monitoring d'API LoadFocus valide le backend que vos clients mobiles frappent — des APIs lentes font sentir lente même la meilleure UI React Native. Les tests de charge valident que votre backend tient quand votre app lance et devient virale. Les tests UI de l'app React Native elle-même utilisent des outils différents (Detox, Maestro) — mais la couche réseau bénéficie absolument du monitoring synthétique.