Shopify quitte React Native pour Swift et Kotlin, agents à l'appui

Six ans et deux revirements

En 2020, Shopify basculait ses applications mobiles sur React Native pour trois raisons affichées : ne plus écrire deux fois la même fonctionnalité, ouvrir le mobile à des développeurs qui n’en venaient pas, et cesser de courir après la parité entre iOS et Android. En janvier 2025, la même équipe écrivait encore que l’avenir du framework était radieux et que l’investissement continuerait. Le 10 septembre 2026, le blog d’ingénierie de la maison annonce le chemin inverse : retour à Swift et Kotlin.

Le billet ne renie rien. Il qualifie le pari de 2020 d’extrêmement réussi et décrit React Native comme un excellent framework. Ce qui a bougé, écrit-il, c’est une hypothèse de départ — pas le framework.

L’argument avancé tient en un mot : agents

Shopify dit utiliser des LLM pour produire du logiciel depuis 2021, soit un an avant ChatGPT — précision qu’on devine écrite avec une certaine satisfaction. D’abord pour implémenter des fonctionnalités, chercher des bugs et relire du code. Puis, fin 2025, pour une question nettement plus embêtante : construire deux fois signifie-t-il encore travailler deux fois ?

L’équipe raconte avoir reconstruit plusieurs parties centrales de ses plus grosses applications en Swift et Kotlin, à l’aide d’agents, et avoir été surprise du résultat. Trois observations concrètes en sortent : un agent implémente une fonctionnalité sur Android en prenant la version iOS comme référence, et réciproquement ; des développeurs contribuent efficacement hors de leur pile d’origine ; et le coût du maintien de la parité chute nettement, via des spécifications, des tests et des points de revue partagés entre plateformes.

Le billet ne prétend pas pour autant que ce coût a disparu. Deux plateformes restent deux plateformes. C’est simplement, dit-il, que ce n’est plus le facteur qui décide.

Le plafond n’est pas celui que vous imaginez

Si vous attendiez le procès en lenteur, passez votre chemin : Shopify affirme noir sur blanc que des applications React Native peuvent être rapides, et que les siennes le sont. Le grief technique est ailleurs. Le framework demandait un investissement continu — optimisation des performances, amélioration de briques fondamentales de React Native lui-même, suivi des mises à jour et des dépendances externes. Des compromis que l’équipe jugeait acceptables tant que le partage de code les payait.

C’est là l’enseignement réel, et il est moins glorieux pour le natif qu’il n’y paraît. Le cross-platform n’a pas buté sur un plafond technique : il a perdu sa contrepartie. Le natif conserve ses avantages — proximité des capacités de la plateforme, outillage de première partie, moins de couches de framework et de dépendances entre le code et le système — pendant que son principal défaut se fait absorber par des agents. La décision de Shopify ne dit rien du plafond de React Native. Elle dit que le prix du billet a changé.

L’écosystème récupère l’addition

Restent les bibliothèques que Shopify a publiées et qui sont devenues des références. React Native Skia sera sponsorisé jusqu’à fin 2026 ; William Candillon continuera à y travailler au-delà, forkera le dépôt sous un nouveau nom, et l’original sera archivé une fois la transition terminée. FlashList, environ deux millions de téléchargements par semaine et façon par défaut d’afficher des listes performantes, verra ses cassures de compatibilité critiques encore corrigées, le temps que Shopify trouve un repreneur au long cours parmi plusieurs entreprises approchées. Restyle, public plus restreint, est archivé. Traduction pour les dépendants : votre brique critique devient un appel au sponsoring, ce qui est déjà mieux qu’un commit d’archivage sans préavis.

Notez au passage la mécanique, plus intéressante que le choix lui-même : une équipe a rouvert une décision qui marchait, parce qu’une hypothèse avait bougé. Dans nos métiers, c’est encore plus rare qu’un changement de framework.