Accueil / Articles / Pourquoi le retrait de Shopify de React Native ne menace pas Expo

Pourquoi le retrait de Shopify de React Native ne menace pas Expo

Explique pourquoi le passage de Shopify de React Native à Swift et Kotlin natifs ne signifie pas la fin du développement multiplateforme avec Expo pour la plupart des équipes.

1208 mots

Le 10 septembre 2026, Shopify a annoncé qu’il retirait ses applications mobiles principales de React Native pour les reconstruire nativement à l’aide de Swift et Kotlin. En quelques heures, les forums des développeurs se sont remplis de spéculations. Les discussions sur les réseaux sociaux débattaient du fait que cela marquait la fin de React Native. Plusieurs articles de blog allaient même jusqu’à affirmer que le développement mobile multiplateforme était terminé.

Si vous travaillez avec Expo, rien de tout cela ne devrait vous inquiéter.

Ce que Shopify a réellement fait — et pourquoi

La raison avancée par Shopify était assez simple : les assistants de codage basés sur l’IA ont rendu beaucoup moins coûteux le maintien de deux bases de code natives distinctes pour iOS et Android. Le point fort initial de React Native était d’économiser du temps de développement en partageant le code entre les plateformes. Dès que les outils d’IA peuvent générer du code natif en Swift et Kotlin à grande vitesse, ce calcul change pour une entreprise de la taille de Shopify.

Le détail clé est « une organisation de la taille de Shopify ».

Shopify gère l’une des applications mobiles les plus complexes au monde, avec des centaines d’ingénieurs, des millions de commerçants, et des exigences de performance qui mettent à l’épreuve n’importe quel framework. Lorsque Shopify affirme que l’IA a rendu le développement natif plus abordable, c’est en tant que société capable de gérer simultanément deux grands ensembles de code complexes.

La plupart des développeurs Expo ne se trouvent pas dans cette situation, tout comme les équipes typiques qui développent des applications aujourd’hui.

Expo et Shopify résolvent des problèmes différents

Pour Shopify, React Native était principalement un moyen de réduire les coûts au sein d’une vaste organisation d’ingénierie. Pour les développeurs d’Expo, React Native est l’outil qui permet à un développeur solo ou à une petite équipe de livrer une application complète et soignée sur iOS et Android, sans avoir besoin d’être un spécialiste de l’une ou l’autre plateforme native.

Ces deux cas d’usage n’ont presque rien en commun.

Expo dispose d’une équipe principale dédiée qui a passé des années à perfectionner l’une des meilleures expériences de développement pour les applications mobiles. Le SDK 57, récemment sorti, a apporté d’autres améliorations en termes de performances, d’outils de compilation et d’ergonomie au quotidien pour les développeurs. Les bibliothèques complémentaires telles que NativeWind, Reanimated et Expo Router sont plus stables et prêtes pour le déploiement que jamais auparavant.

Rien de tout cela ne change parce qu’un grand distributeur a décidé de passer à autre chose.

Les chiffres racontent une histoire différente

Pendant que les commentateurs se hâtaient de déclarer React Native terminé, les données d’adoption montraient le contraire.

NativeWind, la solution de stylisation inspirée de Tailwind CSS pour React Native, a dépassé 1,3 million de téléchargements hebdomadaires en 2026 et continue d’augmenter. Expo reste très présent au sein des communautés de développeurs et dans les discussions. De nouvelles bibliothèques de stylisation comme Uniwind ont vu le jour et ont atteint des centaines de milliers de téléchargements hebdomadaires en seulement quelques mois.

Ces chiffres ne décrivent pas un écosystème en régression. Ils décrivent plutôt un écosystème qui continue de mûrir.

Ceux qui ont abandonné React Native dès l’annonce de Shopify étaient probablement les mêmes personnes qui auraient trouvé une autre excuse pour partir le mois prochain de toute façon. Les développeurs qui créent réellement des produits avec Expo ne reconsidèrent rien.

L’IA accélère le développement avec Expo, sans le rendre obsolète

Il y a une véritable ironie dans l’argument selon lequel l’intelligence artificielle aurait tué React Native : en réalité, les outils d’intelligence artificielle ont considérablement amélioré la création de applications avec Expo, et non l’ont détériorée.

Des assistants tels que Claude, Cursor et GitHub Copilot comprennent très bien l’écosystème Expo. Grâce à un fichier CLAUDE.md bien organisé qui décrit vos conventions de composants et vos modèles architecturaux, l’un de ces assistants peut ajouter de nouvelles interfaces, développer de nouvelles fonctionnalités et refactoriser le code existant tout en maintenant la cohérence avec le reste de votre base de code.

Ces utilisateurs qui tirent le plus de valeur de ce flux de travail, parfois appelés « vibe coders » car ils décrivent le résultat souhaité et laissent l’assistant s’occuper de la mise en œuvre, ont néanmoins besoin d’une structure de base solide. Les outils d’IA sont excellents pour écrire du code, mais ils sont bien moins fiables pour prendre des décisions architecturales, concevoir des flux de navigation, créer un système de thématisation ou mettre en place à partir de zéro un ensemble cohérent de composants partagés.

C’est précisément cette lacune que comble un modèle de départ bien conçu pour Expo. Il ne s’agit pas du code que pourrait générer un assistant d’IA sur demande — il s’agit de la structure de base qui permet à l’écriture de code assistée par l’IA d’être véritablement productive.

Les modèles constituent la couche de base du développement assisté par l’IA

Lorsqu’un développeur ouvre Cursor ou Claude pour créer une nouvelle application, la première question réelle est de savoir à partir de quelle base de code il commence.

Commencer avec un résultat brut de create-expo-app signifie passer vos premières heures à mettre en place la navigation, à ajouter le mode sombre, à créer des composants UI de base et à établir des conventions. L’IA peut aider pour certaines parties de ce travail, mais il reste nécessaire de prendre des décisions humaines, de configurer les éléments et d’iter à plusieurs reprises avant d’avoir une base utilisable.

Commencer plutôt avec un modèle prêt pour la production signifie que les travaux préparatoires sont déjà terminés. Vous ouvrez votre éditeur IA, décrivez la fonctionnalité que vous souhaitez ajouter ensuite, et l’assistant dispose d’une base de code cohérente et bien organisée à étendre.

C’est précisément pour cette raison que les modèles conçus en tenant compte de workflows assistés par l’IA — avec une documentation détaillée dans CLAUDE.md, des notes claires au niveau des composants et des patterns cohérents — sont aujourd’hui plus importants qu’il y a deux ans, et non moins.

Les développeurs qui devraient vraiment s’inquiéter

Si la décision de Shopify devrait inquiéter quelqu’un, ce sont les développeurs qui créent des applications React Native basiques en dehors de l’écosystème Expo, en s’appuyant directement sur le React Native CLI, et qui ciblent des clients à grande échelle disposant d’assez de ressources en ingénierie pour justifier un développement entièrement natif.

Cela décrit une portion plutôt restreinte de tous ceux qui utilisent React Native.

Si vous êtes plutôt un développeur indépendant, un freelance, un petit studio, ou quelqu’un qui crée sa première application en la décrivant principalement à un assistant IA, Expo reste le chemin le plus rapide pour passer d’une idée à une application fonctionnelle sur les deux principales plateformes mobiles. Rien dans la décision de Shopify ne change cette réalité.

Que cela signifie pour vous

Continuez à développer avec Expo. Continuez à publier vos applications avec Expo. L’écosystème est en bonne santé, les outils s’améliorent constamment à chaque nouvelle version, et la communauté qui l’entoure ne disparaît pas.

Si vous lancez un nouveau projet React Native, commencez par un modèle prêt pour la production plutôt qu’un projet vide, et laissez les assistants IA gérer les détails d’implémentation sur cette base. Cette combinaison vous permet de publier plus rapidement que si vous deviez tout créer à partir de zéro.

Certains développeurs passeront les semaines à venir à lire des opinions tranchées et à remettre en question leurs choix technologiques à cause d’une annonce d’entreprise. D’autres continueront simplement à publier leurs applications.

Visez à faire partie du deuxième groupe.

Lectures complémentaires

  • Créer un composant Select configurable pour React Native Paper — Une présentation détaillée de la conception et du dépôt en open source de react-native-paper-select, abordant la recherche, les éléments de sélection multiples, les listes segmentées et les compromis en termes de performance.
  • Planifier la mise à jour vers Expo SDK 58 : iOS 27, React Native 0.88 et nouvelles outils — Une visite pratique de la version bêta d’Expo SDK 58 : quels changements pour iOS 27 et React Native 0.88, quelles fonctionnalités sont expérimentales, et comment tester la mise à jour en toute sécurité.
  • PWA, Swift et Kotlin, ou Expo : choisir une architecture d’application mobile — Comparez les PWA, les applications entièrement natives en Swift et Kotlin, ainsi qu’Expo en ce qui concerne la base de code, la présence dans les stores, les performances, l’accès au matériel, la vitesse de publication et le coût, puis faites votre choix.