Développez votre première application en React Native : le guide pratique
React Native permet de créer une application iOS et Android avec une seule base de code, sans sacrifier l’expérience utilisateur. Ce guide vous accompagne de l’installation aux stores, avec des choix techniques argumentés, des exemples concrets et des pièges à éviter.
🔑 À retenir
- Choisissez Expo pour démarrer vite, React Native CLI pour un contrôle total
- Structurez votre projet tôt (navigation, état, dossiers) pour éviter la dette technique
- Pensez performance dès les premières listes, images et appels réseau
- Testez sur vrai appareil et automatisez au minimum la qualité (lint, format, tests)
- Préparez le déploiement dès le début (identité d’app, icônes, permissions, builds)
Construire une application mobile, c’est gérer à la fois l’interface, la logique métier, les données, les performances… et deux plateformes. Avec React Native, l’idée est simple : développer en JavaScript/TypeScript et produire une app qui s’exécute nativement sur iOS et Android, avec une grande partie du code partagée.
Dans la pratique, réussir une première app React Native dépend moins de "connaître React" que de savoir monter un environnement propre, choisir une architecture réaliste, gérer la navigation et l’état, consommer une API sans fragiliser l’app, puis livrer un binaire stable sur les stores. Voici un chemin de bout en bout, orienté production.
React Native en clair : ce que vous gagnez (et ce que vous échangez)
React Native traduit vos composants en vues natives (UIKit/SwiftUI côté iOS, Views Android côté Android). Vous bénéficiez d’un rendu proche du natif et d’un écosystème mature (navigation, formulaires, requêtes réseau, tests). L’enjeu : conserver une expérience fluide, malgré le pont JavaScript et les différences de plateforme (permissions, navigation système, comportements UI).
Avantages
- Base de code largement partagée entre iOS et Android (gain de temps sur les écrans, la logique, les validations)
- Hot Reload / Fast Refresh pour itérer rapidement sur l’interface
- Accès aux API natives via modules (capteurs, caméra, notifications) quand nécessaire
- Écosystème React : composants réutilisables, gestion d’état, outillage qualité
Limites
- Divergences iOS/Android : il faut tester sur les deux et adapter certains composants
- Performances à surveiller sur listes, animations, images et écrans très dynamiques
- Dépendance à des bibliothèques tierces (qualité variable, maintenance à vérifier)
- Déploiement iOS plus exigeant (certificats, profils, validation App Store)
Choisir votre voie : Expo ou React Native CLI (et comment trancher)
Deux manières courantes de démarrer existent. Expo fournit une couche d’outillage (builds, mises à jour, accès à des API) qui simplifie la vie. React Native CLI, lui, vous donne la main sur les projets natifs dès le départ (Xcode/Android Studio), au prix d’une configuration plus technique.
| Critère | Expo | React Native CLI |
|---|---|---|
| Démarrage | Très rapide (configuration minimale) | Plus long (outils natifs à installer/configurer) |
| Accès natif | Large via modules Expo ; possible d’aller plus loin via “prebuild” | Total (vous modifiez directement iOS/Android) |
| Builds | EAS Build (cloud ou local selon config) | Local (Xcode/Gradle), CI à mettre en place |
| Pour une 1re app | Souvent le meilleur choix | Pertinent si vous savez déjà que vous devrez modifier le natif |
Pour une première application, Expo est généralement le choix le plus rationnel : vous livrez plus vite, vous passez moins de temps dans la plomberie, et vous gardez une porte de sortie (prébuild) si vous devez intégrer du natif plus tard. En revanche, si votre cahier des charges impose dès le départ des modifications natives spécifiques (SDK très particulier, configurations iOS/Android avancées), la CLI peut éviter un détour.
Préparer l’environnement : installation fiable et reproductible
Le socle commun : Node.js (LTS), un gestionnaire de paquets (npm ou idéalement pnpm/yarn), Git, et un éditeur (VS Code est courant). Ajoutez TypeScript dès le début : le coût d’entrée est faible, et le gain en fiabilité est réel dès que votre app dépasse quelques écrans.
- Installez Node.js en version LTS et vérifiez avec : node -v et npm -v
- Activez un formatage/lint cohérent : Prettier + ESLint (et un hook de pré-commit si possible)
- Sur macOS pour iOS : Xcode (et les outils en ligne de commande) ; sur Windows/Linux : test iOS impossible localement, prévoyez un Mac ou un service de build
- Pour Android : Android Studio, SDK Platform Tools, un émulateur (ou un appareil physique)
Créer votre projet et partir sur une base saine (TypeScript, navigation, dossiers)
Démarrez un projet Expo en TypeScript, puis installez d’emblée les briques structurantes : navigation, gestion des requêtes et un minimum de conventions de dossiers. Le but n’est pas d’industrialiser trop tôt, mais d’éviter le "fourre-tout" qui ralentit tout après 2 semaines.
- Navigation : React Navigation (stack + tabs selon vos écrans)
- Données serveur : TanStack Query (ex-React Query) pour cache, revalidation, états de chargement
- Formulaires : React Hook Form (si vous avez de vrais formulaires)
- Stockage local : AsyncStorage ou SecureStore (Expo) selon la sensibilité
- Config : variables d’environnement (sans exposer de secrets dans l’app)
Une structure simple et robuste : src/ avec screens/ (écrans), components/ (UI réutilisable), services/ (API, stockage), hooks/, navigation/, theme/ (couleurs, typographie), types/. Gardez le code "métier" hors des écrans : un écran doit surtout orchestrer, pas tout calculer.
Construire l’interface : composants, styles et accessibilité sans douleur
React Native fournit les briques de base : View, Text, Image, Pressable, ScrollView, FlatList. Le réflexe productif : privilégier FlatList pour les listes longues, limiter les re-renders, et standardiser la mise en forme via un thème (espacements, tailles, couleurs).
Côté style, vous pouvez rester sur StyleSheet (natif, performant) ou adopter une solution utilitaire (type Tailwind RN) si votre équipe y est habituée. Dans tous les cas : centralisez les tokens (couleurs, arrondis, interlignes) et évitez les valeurs magiques dispersées.
- Accessibilité : utilisez accessibilityLabel sur les boutons importants, vérifiez le contraste, respectez les tailles de texte (Dynamic Type / Font scaling)
- Gestes : préférez Pressable à TouchableOpacity pour un contrôle fin
- Images : servez des formats optimisés, définissez width/height pour éviter les sauts de mise en page
- Listes : FlatList avec keyExtractor stable, windowSize raisonnable, évitez de rendre 200 éléments d’un coup
Gérer l’état et les données : local vs serveur, et une méthode qui tient
La confusion classique : tout mettre dans un "store global". Dans une app mobile, une grande part de l’état vient du serveur (liste d’articles, profil, notifications) et doit être gérée comme telle : cache, rafraîchissement, erreurs réseau, mode hors-ligne partiel.
Approche recommandée pour une première app : (1) état serveur via TanStack Query, (2) état UI local dans les composants, (3) un petit store global seulement pour ce qui traverse toute l’app (session utilisateur, préférences). Ainsi, vous réduisez les effets de bord et vous simplifiez le débogage.
Consommer une API proprement : réseau, erreurs, pagination, et résilience
Une application "réelle" vit sur un réseau imparfait : 4G instable, Wi‑Fi capricieux, serveurs qui renvoient des erreurs. Votre code doit intégrer cette réalité : timeouts, gestion d’erreur lisible, indicateurs de chargement, et comportements de repli (réessayer, afficher le cache, expliquer l’échec).
- Centralisez les appels HTTP (fetch/axios) dans un service unique : baseURL, en-têtes, journalisation contrôlée
- Normalisez les erreurs : mappez les statuts (400/401/403/500) vers des messages utiles
- Gérez la pagination côté liste : paramètres (page, cursor), et UI (chargement en bas, état vide)
- Ajoutez une stratégie de retry mesurée (pas infinie), et un mode "pull to refresh"
Pour la qualité, validez les données reçues quand c’est critique (par exemple avec un schéma). Sans aller jusqu’à la paranoïa, cela évite des crashs quand l’API change. Et n’oubliez pas : sur mobile, chaque appel coûte en latence et en batterie, regroupez quand c’est possible.
Performance : les 6 points qui font la différence sur mobile
Une app React Native peut être très fluide… à condition d’éviter quelques pièges connus. Les lenteurs perçues viennent souvent de listes mal rendues, d’images lourdes, d’animations gérées côté JavaScript, ou de re-renders inutiles.
- Mesurez avant d’optimiser : utilisez le profilage (Flipper/DevTools) et cherchez les écrans vraiment lents
- Stabilisez les props : useCallback/useMemo quand cela a du sens (pas partout)
- Listes : privilégiez FlatList, évitez les composants trop lourds par item, et utilisez getItemLayout si possible
- Images : mise en cache, formats adaptés, dimensions explicites, évitez les énormes PNG
- Animations : utilisez des libs optimisées et limitez les calculs en JS sur les frames
- Données : évitez de recalculer/filtrer de grandes listes à chaque frappe (débounez, indexez)
Tests et qualité : le minimum viable qui évite les régressions
Sur une première app, viser 100% de couverture n’est pas réaliste. En revanche, un socle de qualité est accessible : lint + format, quelques tests unitaires, et des tests de composants sur les écrans critiques. Ajoutez une routine de test manuel structurée sur deux appareils (un iOS, un Android) avant chaque release.
- ESLint + Prettier : base non négociable pour éviter les divergences
- Tests : Jest + React Native Testing Library pour les composants
- Scénarios manuels : installation propre, parcours onboarding, login/logout, mode avion, reprise après mise en veille
- Crashs en production : prévoyez un outil de remontée (selon votre contexte) et des logs non sensibles
Déploiement iOS/Android : préparer les stores sans y passer une semaine
Le déploiement n’est pas une formalité : il implique identité d’application, certificats, signatures, versions, captures d’écran, politiques de confidentialité et permissions. Le bon timing : préparer ces éléments tôt, même si l’app n’est pas finie, pour éviter le mur de fin de projet.
- Identité : nom, bundle identifier (iOS), applicationId (Android), icônes et splash
- Permissions : demandez uniquement le nécessaire, expliquez l’usage (iOS y est strict)
- Versions : adoptez une convention (ex. 1.0.0) et incrémentez proprement buildNumber/versionCode
- Builds : générez un build de test tôt (TestFlight / piste interne Google Play) pour valider le pipeline
- Fiche store : description claire, captures d’écran, politique de confidentialité si collecte de données
Feuille de route : votre première app en 10 étapes réalistes
- Définir le périmètre : 3 à 6 écrans et un objectif utilisateur mesurable
- Choisir Expo (par défaut) et TypeScript
- Mettre en place navigation + thème + structure de dossiers
- Créer les écrans en statique (UI) avant l’API
- Brancher l’API avec un service réseau centralisé et une gestion d’erreurs cohérente
- Ajouter la gestion d’état serveur (cache, pagination, rafraîchissement)
- Traiter l’accessibilité et les différences iOS/Android (claviers, safe areas, retours)
- Stabiliser performance (listes, images) et corriger les re-renders évidents
- Ajouter le socle qualité (lint, quelques tests, checklist de tests manuels)
- Préparer et exécuter le déploiement (builds de test, puis store)
