Chapitre 1.1 — Pourquoi React Native
Où on en est : premier chapitre du cours. Aucun outil installé, aucun code écrit — on décide en connaissance de cause pourquoi React Native, avant de s’y engager pour 20 parties.
⏱️ TL;DR — React Native permet d’écrire des apps réellement natives (pas des pages web déguisées) avec React et TypeScript. Il est porté par Meta, utilisé par des milliers d’apps majeures, et pour un dev React c’est de très loin le chemin le plus court vers le mobile : ~80 % de vos réflexes sont directement réutilisables. Ses concurrents sérieux sont Flutter et le natif pur — on les compare honnêtement ci-dessous.
🎯 Objectifs
- Savoir situer React Native face à Flutter, Kotlin natif, et les PWA/hybrides.
- Comprendre ce que « natif » veut dire concrètement (et pourquoi une WebView n’est pas native).
- Mesurer ce que votre expérience React/Next.js vous fait gagner — et ce qu’elle ne couvre pas.
- Connaître les apps réelles qui tournent en React Native en 2026.
Le problème que React Native résout
Pour livrer une app Android et iOS en 2026, quatre grandes familles d’approches :
| Approche | Langage | UI | Exemples d’outils |
|---|---|---|---|
| Natif pur | Kotlin / Swift | Widgets natifs | Android Studio, Xcode |
| Cross-platform natif | JS/TS ou Dart | Widgets natifs ou rendu propre | React Native, Flutter |
| Hybride WebView | JS/TS | Page web dans une coquille | Capacitor, Ionic |
| PWA | JS/TS | Navigateur | Next.js + manifest |
Le natif pur donne le contrôle maximal, mais exige deux équipes, deux langages, deux codebases. Les WebView et PWA réutilisent votre web, mais l’expérience trahit vite : scroll moins fluide, pas d’accès complet aux APIs système, pas de vraie présence sur les stores (PWA), sensation « site dans une boîte ».
React Native occupe le point d’équilibre : un seul code JS/TS, mais le rendu produit de
vrais composants natifs. Quand vous affichez un <Text>, Android crée un TextView — le
même widget qu’une app Kotlin. Pas de DOM, pas de WebView, pas de HTML.
💡 Pour un dev Next.js — Retenez la formule officielle : « Learn once, write anywhere ». React n’est pas lié au DOM : c’est un moteur de réconciliation d’arbres de composants. React DOM projette cet arbre en HTML ; React Native le projette en widgets natifs. Vos hooks, vos props, votre JSX, votre modèle mental de re-render : identiques. Ce qui change, c’est la cible de rendu — et l’environnement (pas de navigateur, pas de
window).
Qui utilise React Native en 2026
Ce n’est pas une techno de niche — c’est l’une des fondations mobiles les plus déployées au monde :
- Meta : Facebook, Instagram, Messenger, WhatsApp (par endroits), Meta Horizon — RN est né chez Meta en 2015 et y reste massivement investi.
- Microsoft : Office, Outlook, Teams, Xbox — Microsoft co-maintient RN pour Windows/macOS.
- Shopify : 100 % de ses apps mobiles, avec des contributions majeures (FlashList, Skia).
- Amazon (Kindle, boutique par endroits), Coinbase, Discord, Bluesky, PlayStation App, Walmart, Tesla…
Deux signaux forts pour votre décision :
- Meta et Microsoft misent leur mobile dessus — le risque d’abandon est à peu près nul.
- L’écosystème d’embauche : les offres « React Native » recrutent… des devs React. Votre CV Next.js + ce cours = profil mobile crédible.
React Native vs Flutter — le vrai match
Flutter (Google, langage Dart) est l’autre grand du cross-platform. Comparaison honnête :
| Critère | React Native | Flutter |
|---|---|---|
| Langage | TS/JS — vous le parlez déjà | Dart — à apprendre |
| Rendu | Widgets natifs (look Android réel) | Moteur de rendu propre (Impeller) — pixels dessinés |
| Partage avec le web | Énorme (React, libs JS, logique) | Faible (Dart web reste marginal) |
| Perf brute UI | Excellente depuis la New Architecture | Excellente |
| Écosystème packages | npm (immense) + expo-* | pub.dev (riche, plus jeune) |
| Portage desktop | Windows/macOS via Microsoft (correct) | Bon |
La ligne de fracture réelle : Flutter dessine ses propres pixels (ses boutons imitent Android), RN délègue aux widgets du système (ses boutons sont Android). Et surtout : Flutter exigerait d’abandonner tout votre capital JS/React. Pour un dev Next.js, choisir Flutter reviendrait à repartir de zéro pour un gain incertain. Dossier clos.
⚠️ Piège — Ne confondez pas React Native avec les frameworks hybrides (Ionic, Capacitor) qui affichent votre site web dans une WebView. C’est une confusion fréquente en entretien. RN ne contient aucune WebView par défaut : l’UI est 100 % native.
Et le natif pur, alors ?
Kotlin (Android) et Swift (iOS) restent supérieurs sur trois terrains : les apps extrêmement graphiques (jeux 3D), l’accès immédiat aux APIs système du jour (RN suit avec quelques semaines/mois via les modules), et les équipes déjà 100 % natives. Pour tout le reste — c’est-à-dire l’immense majorité des apps, y compris vos quiz et apps de productivité — le cross-platform natif a gagné la guerre du rapport valeur/effort. Et le jour où une API vous manque vraiment, RN permet d’écrire un module natif ciblé (Partie 15) : ce n’est pas une prison.
Ce que votre bagage Next.js couvre — et ne couvre pas
Directement transférable (vous partez à ~80 %) :
- Composants, props, état, hooks (
useState,useEffect,useContext, memoïsation) — identiques. - TypeScript, npm/pnpm, la toolchain JS, ESLint/Prettier.
- Le routing par fichiers : Expo Router est explicitement calqué sur App Router.
- Tailwind : via NativeWind, vos classes utilitaires reviennent (Partie 4).
- Data fetching : TanStack Query fonctionne à l’identique (Partie 7).
À apprendre (le programme de ce cours, littéralement) :
- Les composants de base changent :
View/Textremplacentdiv/span, et leurs règles sont plus strictes (Partie 3). - Pas de CSS :
StyleSheetet un flexbox légèrement différent (Partie 4). - L’environnement : clavier virtuel, safe areas, gestes, cycle de vie d’app (Parties 3, 9, 10).
- Tout le monde du build : binaires, signing, APK/AAB, stores — inexistant sur le web, où « déployer » = pousser sur Vercel (Parties 11-13).
📚 Aller plus loin — reactnative.dev (doc officielle), expo.dev , et le talk d’origine « React Native: Bringing modern web techniques to mobile » (Meta, 2015) pour la genèse.
Et Drill dans tout ça
Le fil rouge de ce cours est Drill, votre app de quiz personnelle : choisir un thème (Bootstrap, Next.js, PHP, Symfony…), enchaîner des QCM chronométrés, marquer des points, battre vos records. C’est un projet idéal pour apprendre RN : listes, navigation, état de jeu, timer animé, stockage local, notifications, et à la fin — un APK installé sur votre téléphone, mis à jour à distance. Chaque partie du cours fait avancer Drill d’un cran.
✏️ Exercices
1. Sans relire : citez la différence fondamentale entre React Native et Capacitor/Ionic.
✅ Solution
Capacitor/Ionic affichent une page web dans une WebView (le rendu est du HTML dans un
navigateur embarqué). React Native ne contient pas de WebView : chaque composant React est
projeté en widget natif Android réel (TextView, ViewGroup…). L’UI de RN est native,
celle d’Ionic est du web emballé.
2. Un collègue vous dit : « Flutter est plus performant, RN passe par un bridge JSON lent. » Que répondez-vous en 2026 ?
✅ Solution
C’était partiellement vrai avant 2022. Depuis la New Architecture (active par défaut depuis RN 0.76), le bridge asynchrone à sérialisation JSON a été remplacé par JSI : le JS appelle le natif par références C++ directes, de façon synchrone quand il le faut. Les benchmarks UI courants placent RN et Flutter dans la même classe de performance. Le vrai critère de choix n’est plus la perf mais : langage (TS vs Dart), rendu (widgets natifs vs pixels dessinés), et capital de compétences existant. Détails au chapitre suivant.
3. Listez trois choses de votre quotidien Next.js qui marcheront telles quelles en RN, et trois qui n’existent plus.
✅ Solution
Marchent telles quelles : les hooks React (useState, useEffect…), TypeScript et npm/pnpm,
le paradigme composants/props, TanStack Query, la logique métier pure. N’existent plus : le DOM
(div, document, window), le CSS (fichiers .css, cascade, media queries), le déploiement
« push sur Vercel » (remplacé par builds + stores), localStorage (remplacé par AsyncStorage/SQLite),
et les APIs navigateur en général.
🧠 Quiz
1. Que produit React Native à l’écran quand vous rendez un composant <Text> ?
Réponse
Un widget natif Android : un TextView (et un UILabel sur iOS). Ni HTML, ni WebView, ni
canvas — le même objet que créerait une app Kotlin.
2. Quelle est la devise officielle de React Native, et que signifie-t-elle ?
Réponse
« Learn once, write anywhere » — apprenez React une fois, écrivez pour toutes les cibles (web, Android, iOS…). Nuance importante : ce n’est PAS « write once, run anywhere » — le code est largement partagé mais chaque plateforme peut avoir ses spécificités.
3. Citez trois entreprises majeures dont des apps grand public tournent en React Native.
Réponse
Par exemple : Meta (Facebook, Instagram, Messenger), Microsoft (Office, Outlook, Teams), Shopify (toutes ses apps), Discord, Coinbase, Bluesky, Amazon, Walmart, Tesla.
4. Quelle est la différence de philosophie de rendu entre RN et Flutter ?
Réponse
Flutter dessine lui-même chaque pixel avec son moteur (Impeller) — ses widgets imitent la plateforme. RN délègue le rendu aux widgets natifs du système — ses composants sont de vrais widgets Android/iOS.
5. Pour quel type de projet le natif pur (Kotlin/Swift) reste-t-il le meilleur choix ?
Réponse
Les apps extrêmement exigeantes graphiquement (jeux 3D, traitement vidéo temps réel), celles qui ont besoin des toutes dernières APIs système le jour de leur sortie, ou les équipes déjà entièrement natives. Pour les apps « classiques » (contenu, productivité, e-commerce, quiz…), le cross-platform natif suffit largement.
👉 Chapitre suivant : 1.2 — Comment ça marche — on
ouvre le capot : Hermes, JSI, Fabric, et le chemin exact entre votre useState et le pixel.