Expo vs React Native bare workflow

Réponse courte

En 2026, Expo est le bon choix par défaut pour la majorité des apps React Native. EAS Build, Development Builds et les modules natifs couvrent les besoins courants d'un MVP ou d'une V1. Le bare workflow reste utile pour des contraintes natives très spécifiques ou une équipe mobile déjà expérimentée.

Le vieux débat sur Expo est dépassé

Pendant longtemps, Expo avait une réputation simple : pratique pour commencer, limité pour produire. Cette réputation colle encore, mais elle date.

Aujourd'hui, Expo permet de travailler sur des apps React Native sérieuses, avec builds store, code natif, configuration avancée et développement sur appareils réels. Le débat n'est plus "Expo ou vrai projet mobile". Expo est devenu une manière solide de gérer un projet React Native.

Chez Inyka, Expo est utilisé par défaut parce qu'il réduit le temps perdu sur la configuration. Pour un MVP, ce gain est direct.

Le cas Doctolib

En 2024-2025, Doctolib a migré son app mobile vers l'écosystème Expo. Le contexte donne une idée de la maturité actuelle de l'outil : 90 millions d'utilisateurs, 270 millions de rendez-vous pris en 2025, une codebase React Native de dix ans, 81 % des rendez-vous pris depuis le mobile.

Doctolib a choisi le bare workflow plutôt que le managed workflow, surtout pour deux raisons. Premièrement, garder le contrôle complet du code natif iOS et Android existant (intégrations Firebase, Datadog, modules propriétaires). Deuxièmement, opérer dans la santé régulée demande une infrastructure auto-hébergée et auditée, donc pas d'EAS Build chez eux.

Le point intéressant pour nos projets : Doctolib confirme qu'Expo n'est plus un outil "pratique pour commencer, limité pour produire". C'est devenu une infrastructure suffisamment solide pour faire tourner l'une des apps grand public les plus utilisées en France. Pour un MVP startup ou PME, le doute n'a plus lieu d'être.

Ce qu'Expo apporte

Expo simplifie la création, les builds, les tests et la configuration. Avec EAS Build, il devient possible de générer des builds pour iOS et Android sans gérer toute la complexité locale.

Development Builds permettent de sortir du cadre limité d'Expo Go. On peut utiliser une version de développement propre au projet, avec des modules natifs et une configuration plus proche de la production.

Cette approche colle très bien aux apps MVP : authentification, profils, formulaires, notifications, paiement standard, stockage, analytics raisonnables, publication store.

Expo ne supprime pas la complexité mobile. Il la rend plus prévisible.

Ce que le bare workflow apporte

Le bare workflow donne un contrôle direct sur les dossiers natifs iOS et Android. C'est utile quand l'app dépend fortement de code natif spécifique, de SDK peu compatibles, ou d'une configuration très fine.

Il peut aussi être pertinent dans une équipe mobile senior qui veut gérer elle-même les pipelines, les builds et les dépendances natives.

Le prix de ce contrôle est clair : plus de configuration, plus de maintenance, plus de risques de divergence entre iOS et Android.

Pour un MVP, ce coût est souvent mal placé. Il finance une liberté technique avant même d'avoir validé l'usage.

Comparatif simple

Critère	Expo	Bare workflow
Démarrage projet	Rapide	Plus long
Builds iOS Android	Simplifiés avec EAS	À configurer plus finement
Modules natifs	Très large couverture	Contrôle complet
Maintenance	Plus prévisible	Plus lourde
MVP startup	Très adapté	Souvent trop coûteux
Cas très spécifique	Possible, à vérifier	Plus adapté

Le choix ne doit pas se faire par principe. Il doit se faire selon le risque projet.

Les limites réelles d'Expo

Expo peut être moins adapté si l'app dépend d'un SDK natif rare, d'un appareil externe, d'un usage Bluetooth avancé, d'une intégration système fine ou d'une contrainte native très spécifique.

Il faut aussi éviter de croire qu'Expo dispense d'architecture. Une app Expo mal structurée restera difficile à maintenir. Le framework ne répare pas un mauvais modèle de données.

Sur les projets Inyka, la limite apparaît surtout quand le client veut une app temps réel très complexe, une reprise de codebase existante ou un besoin natif inhabituel. Ces projets ne sont pas le format standard du studio.

Pourquoi Inyka utilise Expo par défaut

Inyka livre des applications mobiles iOS et Android en React Native, généralement en 4 à 6 semaines. Expo aide à tenir ce rythme sans sacrifier la qualité minimale attendue.

La stack par défaut est React Native, Expo, Supabase et TypeScript. Elle couvre très bien les apps de réservation, apps internes PME, MVP SaaS, marketplaces simples et applications avec paiement standard.

L'offre Essential démarre à 7 500 € HT. Launch démarre à 14 000 € HT. Scale démarre à 24 000 € HT. Ces offres reposent sur une stack choisie pour éviter les surprises techniques.

Le choix Expo n'est pas une économie de bout de chandelle. C'est un choix de production.

La page agence React Native détaille cette approche.

Sources

Questions fréquentes

Expo est-il limité pour une app professionnelle ?

Non, pas pour la majorité des apps mobiles standard. Les limites apparaissent surtout sur des besoins natifs très spécifiques.

Peut-on publier une app Expo sur les stores ?

Oui. EAS Build permet de préparer des builds pour App Store et Google Play.

Quand choisir React Native bare ?

Il faut choisir bare quand l'app demande un contrôle natif très fin ou des SDK incompatibles avec une approche Expo.

Inyka peut-il faire du bare workflow ?

Le format standard Inyka repose sur Expo. Un besoin bare doit être justifié dès le cadrage, sinon il alourdit le projet sans gain clair.