📘 Vibe coding en entreprise : comment l’encadrer sans freiner vos équipes ? → Lire le livre blanc

Blog › Mobile

Pour ou contre Expo ? Pourquoi theTribe a changé d’avis

En 2021, nous avions arrêté Expo. Aujourd’hui, toutes nos apps React Native partent d’Expo. Ce qui a changé, et quand Expo reste un mauvais choix.

Par Thomas BarusseauPublié le 3 mars 2021Mis à jour le 7 octobre 20265 min de lecture

Mis à jour en octobre 2026 : en 2021, nous avions arrêté Expo. Aujourd’hui, toutes nos applications React Native partent d’Expo. Cet article explique ce qui a changé.

Pour ou contre Expo ? Pourquoi theTribe a changé d’avis
Sommaire
  1. Expo, c’est quoi ?
  2. Ce qui nous avait fait arrêter Expo en 2021
  3. Ce qui a changé
  4. Comment nous utilisons Expo aujourd’hui
  5. Et Fastlane, Firebase App Distribution, TestFlight ?
  6. Quand Expo n’est pas le bon choix
  7. Expo ou pas Expo ? Notre recommandation en 2026

Lorsqu’on démarre un projet React Native, la première question est souvent la même : faut-il partir sur Expo ou sur React Native « nu » ?

En 2021, nous avions publié ici un retour d’expérience sans ambiguïté : nous avions arrêté d’utiliser Expo, et nous ne le recommandions pas pour un usage professionnel. Cinq ans plus tard, notre position s’est inversée : toutes nos nouvelles applications React Native partent d’Expo.

Ce n’est pas que nous avions tort à l’époque. C’est qu’Expo a changé en profondeur. Voici ce qui nous gênait, ce qui a évolué, et comment nous l’utilisons aujourd’hui.

Expo, c’est quoi ?

Expo est un framework et une plateforme construits au-dessus de React Native. Il fournit une large collection de modules natifs (caméra, notifications, stockage sécurisé, localisation…), un système de navigation (Expo Router), des outils de build et de publication, et la possibilité de mettre à jour une application sans repasser par la validation des stores.

React Native lui-même recommande désormais de démarrer un nouveau projet avec un framework, et cite Expo en premier. Ce n’était pas le cas en 2021.

Ce qui nous avait fait arrêter Expo en 2021

À l’époque, nos reproches étaient précis :

  • Impossible d’ajouter certains modules natifs : pas d’achats intégrés, pas de Bluetooth, Google Maps imposé pour les cartes. Pour beaucoup de nos projets, c’était bloquant.
  • Difficile d’en sortir : une fois un projet démarré avec Expo, « l’éjecter » laissait un code toujours très lié à ses bibliothèques. Sur un projet, nous avions perdu beaucoup de temps à tout reprendre.
  • Des applications lourdes : toutes les bibliothèques d’Expo étaient embarquées, même inutilisées.
  • Des builds lents en version gratuite, avec des files d’attente de plusieurs heures.
  • Des bibliothèques Facebook embarquées, qui posaient problème pour les applications destinées aux moins de 13 ans.

Ces critiques étaient justes en 2021. La plupart ne le sont plus.

Ce qui a changé

On peut ajouter n’importe quel module natif

Le changement décisif s’appelle les development builds. Au lieu de faire tourner l’application dans l’app générique Expo Go, on construit sa propre version de développement, qui embarque exactement les modules natifs dont le projet a besoin, y compris ceux qui ne viennent pas d’Expo. Achats intégrés, Bluetooth, SDK de paiement ou de cartographie : tout s’installe comme dans un projet React Native classique.

Quand un module demande une configuration native, un config plugin l’applique automatiquement, sans avoir à modifier à la main les projets iOS et Android.

On n’est plus enfermé

L’« éjection » a disparu. Les dossiers natifs iOS et Android sont générés à la demande à partir de la configuration du projet (Continuous Native Generation). On peut les régénérer, les inspecter, ou les garder et les modifier si un cas très particulier l’exige. On n’est plus coincé : Expo est devenu une couche d’outillage au-dessus de React Native, pas une boîte fermée.

Les applications ne sont plus alourdies

Seuls les modules réellement utilisés sont embarqués. Le poids d’une application Expo est désormais comparable à celui d’une application React Native équivalente, et le problème des bibliothèques Facebook est réglé depuis longtemps.

Le build n’est plus un goulot d’étranglement

Les builds peuvent se faire en local, sur le service d’Expo ou sur n’importe quelle plateforme de CI mobile. Chez theTribe, nous utilisons Codemagic : les builds iOS et Android partent automatiquement de la chaîne d’intégration, sans file d’attente.

Comment nous utilisons Expo aujourd’hui

Expo fait partie de Station, le socle technique sur lequel démarrent nos projets TypeScript. L’application mobile y est une application Expo universelle : iOS, Android et une version web, sur une seule base de code. Concrètement :

  • Un seul langage et un seul contrat d’API pour tout le projet. L’application mobile, l’application web et le back-office consomment le même contrat typé que l’API. Si un champ change côté serveur, l’application mobile ne compile plus, au lieu de planter en production.
  • Expo Router pour la navigation, avec des routes déclarées comme des fichiers, comme sur le web.
  • NativeWind pour le style, avec la même palette de marque que le web : changer l’identité visuelle se fait à un seul endroit.
  • Un stockage sécurisé des jetons de connexion dans le trousseau du téléphone (Keychain sur iOS, Keystore sur Android), et une session qui résiste aux coupures réseau : une perte de connexion dans un ascenseur ne déconnecte pas l’utilisateur.
  • Des tests de bout en bout sur mobile avec Maestro, et des builds automatisés avec Codemagic.

Ce qui nous faisait gagner du temps en 2021 (le build, le test sur téléphone, la publication) est toujours là. Ce qui nous bloquait a disparu.

Et Fastlane, Firebase App Distribution, TestFlight ?

En 2021, après avoir quitté Expo, nous avions remplacé ses services par Fastlane pour automatiser les déploiements, Firebase App Distribution et TestFlight pour les tests utilisateurs. Ces outils restent excellents, et TestFlight reste incontournable pour tester une application iOS en conditions réelles. Mais sur un projet Expo, une bonne partie de ce que nous assemblions à la main est désormais intégrée à l’outillage et à la chaîne de CI.

Quand Expo n’est pas le bon choix

Expo convient aujourd’hui à la grande majorité des applications React Native. Quelques cas méritent toutefois réflexion :

  • Une application qui repose surtout sur du code natif spécifique (moteur graphique, traitement audio ou vidéo très bas niveau) : Expo reste possible, mais l’essentiel de la valeur sera dans des modules natifs écrits à la main.
  • Une équipe qui a déjà une forte culture Flutter : nous utilisons aussi Flutter sur certains projets, et le choix entre les deux dépend autant de l’équipe et du produit que de la technologie. Nous en parlons dans notre comparatif Flutter ou React Native.
  • Un projet React Native existant, sans Expo : migrer est souvent possible progressivement, mais ce n’est pas toujours prioritaire. On l’évalue au cas par cas.

Expo ou pas Expo ? Notre recommandation en 2026

Pour une nouvelle application React Native, nous recommandons Expo. Il apporte un outillage complet, ne ferme plus aucune porte, et permet de démarrer vite sans le payer plus tard.

La leçon de 2021 reste valable : le choix doit se faire dès le début du projet, en regardant les besoins actuels et futurs de l’application. La différence, c’est qu’aujourd’hui, partir sur Expo ne vous empêchera plus d’y répondre.

Vous avez un projet d’application mobile ? Découvrez notre agence de développement mobile.

Vous aimez ce que vous lisez ?

Parlons de votre projet : on vous répond sous 24 h.