Shopify revient au natif : lire la décision à l’échelle de son app

Shopify annonce un retour à Swift et Kotlin pour ses applications mobiles. Pour une équipe React Native, le sujet mérite une lecture précise : le choix d’une entreprise et la maintenance de bibliothèques partagées ont des conséquences différentes.

Ce que Shopify raconte

Le billet de Mustafa Ali (nouvelle fenêtre) présente la reconstruction de Shop avec assistance d’agents, du prototype à la publication dans les stores en douze semaines. La migration de l’application Shopify, beaucoup plus étendue, est encore en cours au moment du billet.

Ce délai appartient à une équipe, un périmètre et une méthode. Il ne mesure pas le coût d’une réécriture de n’importe quelle app. Une base disposant d’intégrations métier, de données locales et de comportements historiques exige un inventaire qui dépasse le nombre d’écrans.

Le point immédiat : les dépendances open source

Shopify précise aussi l’avenir de ses bibliothèques. Pour Skia, l’entreprise annonce un soutien jusqu’à fin 2026 et une transition avec William Candillon. Ce calendrier est une information à suivre pour les consommateurs du package, indépendamment de leur décision de rester sur React Native.

Dans un projet, recenser les dépendances concernées, la version utilisée et les patches locaux est plus urgent qu’une conclusion sur le choix du framework. Un changement de dépôt ou de nom de package demande une migration planifiée ; il ne signifie pas que le code déjà livré cesse de fonctionner.

Comparer des options à périmètre constant

Pour évaluer une éventuelle réécriture, choisir un parcours difficile et définir les mêmes critères pour les deux approches : comportement, accessibilité, performance, tests et capacité de l’équipe à le maintenir.

Il faut aussi compter la transition. Pendant qu’une nouvelle version est construite, l’application existante continue d’avoir des utilisateurs et des correctifs. Une comparaison qui ignore cette période avantage artificiellement la solution nouvelle.

Ce retour d’expérience sert donc à revoir ses hypothèses : où le partage de code aide-t-il réellement, où le natif domine-t-il et quelles preuves permettraient de changer de stratégie ? Il ne suffit pas, à lui seul, à décider pour un autre produit.