Le mobile natif de Shopify est de retour, et l’IA a changé l’arbitrage

Le développement mobile natif de Shopify remplace React Native, renversant une stratégie de six ans après que les agents de programmation ont modifié le coût de maintenance de deux applications. Shopify développera ses logiciels iOS en Swift et ses logiciels Android en Kotlin. L’entreprise affirme que les agents peuvent désormais traduire, tester et examiner suffisamment de travail pour rendre des bases de code distinctes viables.

Cette décision remet en cause l’une des promesses les plus fortes du développement multiplateforme. React Native permet aux équipes de partager une grande partie de l’implémentation d’une application entre iOS et Android. Shopify a adopté ce modèle afin d’éviter de développer les fonctionnalités deux fois, de permettre aux développeurs web de contribuer et de maintenir l’alignement entre les deux plateformes.

Shopify ne déclare pas React Native lent ou infructueux. L’entreprise indique que le framework a apporté les bénéfices promis par sa décision mobile de 2020. Le revirement repose sur un argument différent : l’IA a réduit le travail économisé par le partage de l’implémentation, tandis que les logiciels natifs offrent toujours un accès plus direct à chaque plateforme.

Cette distinction importe au-delà de Shopify. Si les agents de programmation rendent les implémentations parallèles abordables, les équipes d’ingénierie doivent revoir la façon dont elles évaluent la réutilisation du code. La couche partagée la plus précieuse pourrait passer du code source aux spécifications, aux tests, aux systèmes de design et aux procédures de revue.

Le mobile natif de Shopify remplace une stratégie React Native réussie

Shopify abandonne une architecture qui a réussi parce que l’hypothèse économique sur laquelle elle reposait a changé.

L’entreprise a annoncé son retour au développement natif le 10 septembre 2026. Ses principaux produits mobiles incluent Shop, Shopify, Point of Sale et Inbox. Des millions de marchands et d’acheteurs s’appuient sur ces applications, selon Shopify.

L’entreprise a tout misé sur React Native en 2020. React Native est le framework de Meta destiné à créer des interfaces iOS et Android avec JavaScript et des composants natifs de plateforme. Shopify souhaitait une pile technologique commune qui réduirait le développement redondant sur les deux systèmes d’exploitation.

Ses premiers résultats ont conforté cette décision. L’entreprise a fait état de 95 % de code partagé pour Arrive, devenu Shop, et de 99 % pour Compass. Une équipe s’est également estimée deux fois plus productive après avoir réécrit Arrive avec React Native.

Shopify a ensuite fait évoluer sa plus grande application destinée aux marchands vers le framework. Ce produit comptait plus de 300 écrans sur chaque plateforme. Une migration progressive semblait initialement plus sûre que d’interrompre le développement de fonctionnalités pour une réécriture complète.

La stratégie a exigé un investissement organisationnel conséquent. Shopify a formé des développeurs natifs dans le cadre d’un programme interne React Native, créé des fondations partagées et contribué des bibliothèques à l’écosystème élargi. L’entreprise a aussi développé des processus pour mélanger du code natif avec React Native lorsque des travaux spécifiques à une plateforme restaient nécessaires.

En janvier 2025, Shopify décrivait encore l’avenir de React Native comme prometteur. Son bilan après cinq ans saluait la gestion de Meta et promettait de nouveaux investissements dans les fondations partagées. Il faisait également la promotion d’un groupe de travail relancé pour les entreprises utilisant le framework.

La nouvelle annonce constitue donc un véritable revirement, et non le rejet tardif d’une expérience ratée. Shopify affirme que React Native a fait gagner du temps, élargi le nombre de personnes pouvant contribuer et réduit les efforts consacrés à maintenir la parité fonctionnelle.

Ces avantages ont toutefois entraîné des coûts récurrents. Les équipes ont optimisé les performances, maintenu des composants fondamentaux, suivi les évolutions du framework et géré des dépendances externes. Shopify jugeait ces coûts acceptables tant qu’une implémentation partagée éliminait un volume important de travail en double.

Les agents de programmation ont changé ce calcul. Shopify affirme utiliser des grands modèles de langage pour le développement logiciel depuis 2021. Les premiers usages comprenaient l’implémentation de fonctionnalités, l’investigation de bugs, la résolution de problèmes et la revue de code.

Fin 2025, l’entreprise confiait aux agents des tâches plus complexes. Les équipes ont commencé à tester si une implémentation iOS pouvait guider une implémentation Android, et si le processus inverse fonctionnait tout aussi bien. Ces prototypes ont orienté Shopify vers des applications Swift et Kotlin distinctes.

La nouvelle stratégie native de l’entreprise reconnaît toujours l’inconvénient central. Le développement natif exige des équipes qu’elles développent et maintiennent les logiciels deux fois. Selon Shopify, l’IA a réduit cette charge, mais ne l’a pas éliminée.

Cette décision est lourde de conséquences, car Shopify avait autrefois fourni des preuves particulièrement solides de l’utilisation de React Native à grande échelle. L’entreprise ne s’est pas limitée à utiliser le framework autour d’une petite fonctionnalité. Elle a migré de grandes applications, formé des équipes, construit une infrastructure, soutenu des mainteneurs et publié des bibliothèques réutilisables.

À présent, cette même entreprise soutient que la réutilisation de l’implémentation ne mérite plus la même importance. C’est la tension centrale de cet article. L’historique de migration de Shopify vers React Native montre que le framework fonctionnait, tandis que les agents de Shopify ont affaibli l’argument économique en faveur de son maintien.

Les agents de programmation mettent les équipes multiplateformes sous pression

La pression immédiate s’exerce sur les organisations qui considèrent le code partagé comme la principale mesure de l’efficacité mobile.

Les frameworks multiplateformes combinent deux formes d’effet de levier. Ils permettent aux développeurs d’exprimer un comportement une seule fois, et aux entreprises d’organiser le travail mobile autour d’un nombre réduit de langages et d’outils. Ces deux avantages réduisent les coûts de coordination autant que le temps de programmation.

L’argument de Shopify affaiblit directement le premier avantage. Un agent peut examiner une fonctionnalité iOS existante, produire une implémentation Android correspondante et contribuer à vérifier la parité comportementale. Le code source diffère, mais une grande partie de l’effort humain n’a plus besoin d’être répétée manuellement.

Cela déplace l’attention vers le second avantage. Des plateformes distinctes exigent toujours différents systèmes de build, dépendances, procédures de publication, environnements de test et formes de jugement spécialisé. Les agents peuvent aider dans ces tâches, mais les équipes restent responsables de chaque résultat livré.

Les mainteneurs de frameworks font désormais face à une proposition de valeur plus complexe. « Écrire une fois » devient moins convaincant lorsque la traduction logicielle est peu coûteuse. Les outils multiplateformes doivent démontrer leur valeur par la fiabilité, la vitesse d’itération, la mobilité des équipes, la qualité de l’écosystème et la réduction de la surcharge de coordination.

Les responsables de l’ingénierie mobile subissent la pression dans l’autre sens. Des dirigeants pourraient interpréter le développement Swift Kotlin de Shopify comme la preuve que toute entreprise peut abandonner sa base de code partagée. Cette conclusion ignorerait les systèmes que Shopify a construits autour de ses agents.

Shopify n’a pas demandé à un modèle de régénérer une application en une seule passe. L’entreprise a créé des flux de travail structurés, des points de contrôle de revue, des outils de test et des contraintes architecturales. Des ingénieurs expérimentés sont restés responsables des exigences, des décisions de plateforme et de la qualité en production.

La migration a également démarré avec un point de départ exceptionnellement favorable : un produit React Native opérationnel. Cette application a servi de spécification exécutable pour les écrans, les interactions, la navigation, l’analytique et le comportement des données. Les agents traduisaient un comportement défini plutôt que d’inventer un produit entier.

Cette distinction exerce une pression supplémentaire sur les entreprises dont les applications sont mal documentées. Les portages générés par l’IA dépendent d’un comportement de référence clair et de résultats observables. Les systèmes hérités ambigus offrent davantage d’occasions aux agents de reproduire des bugs, d’omettre des cas limites ou d’inventer des modèles incompatibles.

Les développeurs sont eux aussi concernés. React Native avait autrefois élargi le vivier de contributeurs de Shopify en permettant à des personnes ayant une expérience web de travailler sur des fonctionnalités mobiles. Le code natif accordait traditionnellement une plus grande importance aux connaissances spécialisées en Swift, Kotlin, iOS et Android.

Shopify affirme que les agents aident désormais les ingénieurs à contribuer en dehors de leur pile principale. Des modèles d’interface déclarative familiers ont également facilité l’apprentissage de SwiftUI et Jetpack Compose pour les développeurs React Native. SwiftUI et Jetpack Compose sont les frameworks modernes d’Apple et de Google pour définir des interfaces à partir de l’état de l’application.

Cela ne rend pas l’expertise de plateforme facultative. Les ingénieurs natifs comprennent toujours le comportement du cycle de vie, l’accessibilité, la mémoire, le traitement en arrière-plan, les conventions de plateforme et les contraintes de publication. Le code généré peut sembler correct tout en créant une dérive architecturale ou de subtils problèmes de performance.

La réponse imposée n’est pas nécessairement une migration de framework. Les équipes doivent désormais recalculer où le code partagé produit de véritables économies. Elles ont aussi besoin de preuves montrant si les agents peuvent préserver la qualité entre deux implémentations dans leur propre environnement.

Pour les équipes React Native, la réponse la plus solide sera opérationnelle plutôt qu’idéologique. Elles peuvent mesurer l’effort de mise à jour, la maintenance des dépendances, les taux de crash, la vitesse de démarrage, le temps de build et les exceptions spécifiques aux plateformes. Ces chiffres révèlent si l’implémentation partagée compense encore sa couche d’abstraction.

Pour les équipes natives, les résultats de Shopify relèvent le niveau d’exigence pour démontrer la productivité de l’IA. La complétion de code seule ne suffit pas. Un flux de travail agentique crédible doit préserver l’analytique, l’accessibilité, la navigation, les tests, la sûreté des publications et un comportement produit cohérent.

La pression à long terme vise donc les deux camps. Les défenseurs du multiplateforme doivent quantifier des bénéfices allant au-delà de la réutilisation du code. Les défenseurs du natif doivent prouver que la duplication assistée par agents reste maintenable après que l’enthousiasme d’une migration s’est dissipé.

Le revirement concerne la réutilisation, pas les performances de React Native

La décision de Shopify dissocie la réutilisation du code de la cohérence produit, en les traitant comme deux problèmes d’ingénierie distincts.

React Native reliait historiquement ces objectifs. Un composant ou une fonctionnalité partagée se comportait généralement de manière similaire sur les plateformes, car les deux applications exécutaient une grande partie de la même implémentation. Cette relation réduisait la surface où les versions de plateforme pouvaient diverger.

Le nouveau modèle de Shopify conserve la cohérence tout en abandonnant le code d’interface partagé. Les équipes utiliseront des spécifications communes, des tests, des règles de design, des contrats d’analytique et des points de contrôle de revue. Les agents implémenteront ensuite le même comportement visé à l’aide du framework natif de chaque plateforme.

Il s’agit d’un revirement plus profond qu’un simple changement de langages de programmation. L’entreprise déplace la source de vérité vers un niveau supérieur. Au lieu de considérer le code partagé comme le principal contrat produit, elle considère l’intention examinée et le comportement observable comme le contrat.

Cette approche préserve plusieurs avantages du natif. Les développeurs peuvent utiliser les API propriétaires dès qu’Apple et Google les publient. Ils peuvent suivre les conventions de plateforme sans négocier une abstraction partagée. Ils suppriment également des couches de framework et de dépendances entre l’application et le système d’exploitation.

Ce changement est intervenu alors que Shop faisait face à un autre investissement majeur dans React Native. L’application devait adopter la New Architecture du framework, qui modifie le rendu, l’intégration des modules natifs et les frontières entre le code partagé et le code spécifique aux plateformes.

Avant de réaliser cet investissement, Shopify a testé le développement direct avec SwiftUI et Jetpack Compose. Un ingénieur a passé une semaine à utiliser des agents de programmation pour migrer autant que possible de Shop vers un prototype iOS natif.

Ce prototype n’était pas prêt pour la production. Il a toutefois reproduit suffisamment d’écrans, d’interactions et de parcours dans l’application pour rendre une migration complète envisageable. Les agents ont donné leurs meilleurs résultats lorsqu’ils pouvaient travailler à partir de fonctionnalités définies et d’un comportement visible.

Un groupe central de six ingénieurs a ensuite construit les fondations natives et les principaux parcours Shop. Des équipes produit ont rejoint le projet à mi-parcours pour valider leurs domaines et traiter les cas limites. Shopify est passé de la preuve de concept à des applications natives en production en 12 semaines.

Ces chiffres expliquent pourquoi ce revirement est devenu crédible. Une réécriture greenfield classique, c’est-à-dire une nouvelle implémentation construite sans conserver l’architecture précédente, peut prendre des années. Elle peut aussi geler le développement produit et entraîner des problèmes de parité prolongés.

Shopify avait connu ce défi dans le sens inverse. Sa précédente migration progressive vers React Native avait créé une période avec trois architectures : iOS, Android et React Native. Un bilan de 2022 indiquait que le rythme initial aurait nécessité quatre à cinq ans.

L’entreprise a choisi une approche greenfield pour son retour au natif. Elle affirme que les agents de codage pouvaient utiliser l’application React Native existante comme référence, tandis que les nouvelles bases de code éliminaient les anciennes contraintes architecturales. Les prototypes suggéraient que les applications pouvaient être reconstruites beaucoup plus rapidement qu’auparavant.

Les résultats de Shop ont également apporté des éléments de preuve sur les performances. Shopify a indiqué que l’application iOS native affichait le contenu visible de l’accueil en 2 466 millisecondes, contre 3 200 millisecondes auparavant. Cela représente une réduction de 23 % du temps de démarrage.

Sur Android, le temps de démarrage est passé de 4 433 millisecondes à 2 233 millisecondes, soit une réduction de 50 %. La version de production Android est également passée de 293 Mo à 184 Mo, tandis que la version iOS est passée de 67 Mo à 68 Mo.

Le temps de compilation de la version Android a diminué d’environ 75 %. Shopify a également montré l’application Android native atteignant 120 images par seconde lors du défilement du flux et de la navigation sur un appareil Pixel.

La stabilité des sessions est passée d’au moins 99,5 % historiquement à au moins 99,95 % après la sortie native. Shopify a qualifié cette évolution de réduction par dix des sessions qui plantent.

Il s’agit de comparaisons rapportées par l’entreprise, et non de benchmarks indépendants. La migration a également inclus une simplification du produit, certains écrans ayant été supprimés et d’autres rationalisés. Il est donc difficile d’attribuer chaque amélioration uniquement à la technologie native.

Shopify évite elle-même cette affirmation. L’entreprise indique explicitement que ses applications React Native étaient rapides et que React Native reste un excellent framework. Son argument central porte sur la valeur relative d’une implémentation partagée lorsque les agents réduisent le travail en double.

Cette distinction évite un verdict trompeur opposant React Native au natif. Shopify ne présente pas un benchmark universel pour toutes les applications. Elle rapporte que son équipe, ses outils, son architecture et l’échelle de son produit favorisent désormais un équilibre différent.

Helix montre pourquoi la migration allait au-delà de la génération de code

Shopify a rendu la duplication native gérable en transformant la migration en boucle de vérification contrôlée.

L’entreprise a constaté qu’une conversion en une seule étape produisait trop de code difficile à maintenir. Même des spécifications détaillées en amont ne rendaient pas fiable une réécriture entièrement automatisée. Le résultat pouvait sembler complet tout en cachant des schémas incohérents et des comportements manquants.

Shopify a créé Helix pour diviser le travail de migration en petits points de contrôle. Un développeur indique au système un écran, et Helix lit l’implémentation React Native. Il propose ensuite une séquence de travail ordonnée que les humains peuvent examiner rapidement.

Chaque point de contrôle doit démontrer son comportement par des tests. Il fait également l’objet d’une comparaison visuelle, de deux revues de code contradictoires et d’une approbation humaine avant le début du point de contrôle suivant. Les retours sont conservés afin que le flux de travail devienne plus autonome au fil du temps.

Ce mécanisme importe davantage que la vitesse brute de génération. La migration logicielle échoue lorsque les erreurs s’accumulent plus vite que les réviseurs ne peuvent les comprendre. De petites unités validées limitent la quantité de comportement non vérifié qui entre dans la nouvelle application.

Shopify a également exécuté plusieurs sessions d’agents dans des worktrees distincts. Des sous-agents spécialisés ont inspecté le code existant, documenté les comportements, préparé des plans par plateforme, implémenté des fonctionnalités et vérifié la parité. Les ingénieurs approuvaient les exigences et les plans d’implémentation avant que le développement ne progresse.

L’acceptation du plan était liée à un hash du contenu examiné. Si le plan changeait, son approbation précédente devenait invalide. Cette conception réduisait le risque qu’un agent implémente discrètement un plan différent après avoir reçu l’autorisation.

Le flux de travail examinait davantage que les éléments visibles de l’interface. Shopify affirme que sa revue du code source couvrait l’état, la navigation, l’analytique, l’accessibilité et le comportement des données. Ces domaines recèlent souvent les échecs de migration les plus difficiles, car les captures d’écran seules ne peuvent pas les révéler.

La préservation de l’analytique était particulièrement importante. Les recommandations et d’autres systèmes en aval dépendaient d’événements attendus et de champs contextuels. Une application visuellement correcte pouvait néanmoins endommager les systèmes de décision si les noms, les volumes ou les relations de payload des événements changeaient.

Shopify a développé un autre outil, Tardis, pour exposer sous une forme structurée les événements, journaux et états en direct de l’application. Les agents pouvaient envoyer des commandes à l’application, enquêter sur des problèmes, inspecter la navigation et valider les correctifs avec moins d’interactions manuelles.

Pour les revues de parité, Tardis capturait des captures d’écran et des fenêtres d’événements des applications React Native et natives à des points de contrôle nommés. Les agents comparaient les champs d’événements tout en tenant compte des différences légitimes, notamment les horodatages et les identifiants de page uniques.

L’architecture répondait également à la latence des simulateurs. Les agents mobiles dépendent souvent des arbres d’accessibilité ou des captures d’écran pour comprendre l’état de l’interface. Ils peuvent modifier le code en quelques secondes, puis passer plusieurs minutes à compiler et tester via un simulateur.

Shopify a constaté que cette boucle lente nécessitait une supervision humaine fréquente. Le rechargement à chaud des modules de React Native améliorait l’itération, mais n’éliminait pas le goulot d’étranglement du simulateur. La capacité des modèles avait une valeur limitée lorsque les retours restaient lents et fragiles.

L’entreprise a répondu en séparant la logique métier de l’interface. La logique métier headless peut s’exécuter sans afficher l’application. Shopify a exposé cette logique via une interface en ligne de commande, permettant aux agents de l’exercer en quelques millisecondes sur un ordinateur de bureau.

C’est le mécanisme qui sous-tend le développement mobile natif de Shopify. Les agents n’ont pas simplement remplacé six ingénieurs par du code généré. Shopify a repensé l’architecture des applications, les systèmes de retour, les portes de revue et l’accès aux tests autour de la participation des machines.

Ce travail modifie l’économie apparente. Maintenir deux implémentations devient moins coûteux en partie parce que l’organisation investit dans un système de vérification partagé. L’actif commun n’est plus le code de l’interface, mais la mécanique qui décrit et vérifie le comportement attendu.

Le modèle ressemble également à la manière dont les équipes peuvent créer un historique consultable des décisions techniques. Les spécifications, plans, constats de revue et résultats de tests deviennent un contexte réutilisable. Une base de connaissances d’ingénierie peut aider les humains à retracer ces décisions dans la documentation, même si elle ne remplace pas les tests au niveau du dépôt.

Cette approche favorise les grandes organisations disposant d’une infrastructure mature. Shopify pouvait créer des outils sur mesure, maintenir des contrôles automatisés étendus et affecter des ingénieurs expérimentés à l’architecture et à la revue. Une équipe plus petite peut davantage bénéficier d’un framework qui fournit la coordination par le code partagé.

La véritable concurrence oppose donc l’implémentation partagée à l’intention partagée. React Native encode directement la cohérence dans du code source réutilisable. Le nouveau processus de Shopify encode la cohérence à travers les spécifications, l’instrumentation, les tests et une traduction contrôlée.

Les résultats de Shopify ne tranchent pas entre React Native et le natif

Une réécriture réussie en 12 semaines ne prouve pas que deux bases de code natives resteront moins coûteuses sur l’ensemble de leur cycle de vie.

La vitesse de migration n’est que la première mesure. Le test le plus difficile intervient lorsque les deux applications évoluent indépendamment. Les nouvelles fonctionnalités, les changements de système d’exploitation, les correctifs d’urgence et le renouvellement des effectifs révéleront si les agents peuvent maintenir l’alignement des implémentations.

La parité fonctionnelle reste une exigence déclarée. Shopify affirme qu’Android et iOS doivent rester alignés en permanence. Auparavant, le code React Native partagé imposait une grande partie de cette condition de manière structurelle. Le nouveau processus doit l’imposer par des contrôles de développement et de publication.

Cela introduit plusieurs modes de défaillance. Un agent peut créer un comportement équivalent avec des schémas architecturaux incompatibles. Il peut copier une hypothèse iOS dans Android, ou préserver un ancien bug parce que l’application de référence le contient.

Le code généré peut également satisfaire les tests tout en augmentant la duplication ou la dette technique. Shopify reconnaît des risques incluant la dérive architecturale, la logique répétée et les problèmes de performances. Des consignes au niveau du dépôt, le linting, l’analyse statique, les contrôles de performances et la revue humaine restent nécessaires.

L’expertise native devient donc plus importante, et non moins. Les ingénieurs doivent déterminer si le Swift généré respecte les conventions d’Apple et si le Kotlin généré correspond à l’architecture Android. Ils doivent également reconnaître les comportements qu’un modèle a reproduits fidèlement mais qui ne devraient pas être préservés.

La migration de Shop a bénéficié d’une implémentation de référence stable. Le développement de nouveaux produits pose un problème différent. Lorsqu’aucune plateforme ne dispose d’une version acceptée, les agents ne peuvent pas traduire un comportement à partir d’une source connue. Les équipes doivent d’abord définir l’intention assez clairement pour les deux implémentations.

La découverte produit peut rendre cela difficile. Les designers et les ingénieurs affinent fréquemment le comportement en utilisant une première version. Un composant React Native partagé applique immédiatement cet ajustement sur toutes les plateformes, tandis que les équipes natives doivent le propager et le vérifier deux fois.

Les comparaisons de performances nécessitent également de la prudence. Shopify a reconstruit Shop sur une base propre et simplifié certaines parties du produit. Les frameworks natifs, la réduction des dépendances, la suppression d’écrans et le nettoyage architectural ont tous pu contribuer aux gains rapportés.

Les mesures proviennent de Shopify plutôt que d’une organisation de test indépendante. Elles restent utiles parce qu’elles décrivent un déploiement en production, mais elles ne doivent pas devenir des ratios universels. Les différentes applications auront des parcours de démarrage, des intégrations natives et des structures d’équipe différents.

React Native continue d’offrir des avantages que les agents de codage n’effacent pas. Une implémentation partagée réduit le nombre d’endroits où la logique métier peut diverger. Son écosystème fournit également des bibliothèques, des pratiques de débogage, des outils de déploiement et un vaste vivier de développeurs React.

Shopify a elle-même souligné ces atouts. Sa précédente migration a produit des fondations partagées et aidé les développeurs à passer d’une application à l’autre. L’entreprise a également indiqué que React Native permettait aux équipes de fournir de la valeur sans devoir constamment réconcilier les différences entre plateformes.

La transition vers l’open source ajoute une autre incertitude. Shopify prévoit de sponsoriser React Native Skia jusqu’à la fin de 2026, après quoi le mainteneur William Candillon le poursuivra sous un nouveau nom. Le dépôt d’origine sera finalement archivé.

FlashList suit une voie différente. Shopify indique que la bibliothèque de listes haute performance reçoit environ deux millions de téléchargements par semaine. L’entreprise prévoit de corriger les problèmes critiques de compatibilité tout en discutant d’une gestion à long terme avec d’autres organisations.

Restyle dispose d’une base d’utilisateurs plus réduite et sera archivé. Shopify indique qu’il restera fonctionnel jusqu’à la fin de 2026, avec un éventuel soutien à la transmission à un autre mainteneur. Ces transitions créent un travail concret de planification pour les développeurs qui dépendent des bibliothèques de Shopify.

Ils montrent aussi pourquoi le départ d’un utilisateur majeur affecte un écosystème sans pour autant discréditer sa technologie. React Native perd des investissements en ingénierie, des tests sur le terrain et un soutien institutionnel de la part d’un adoptant de premier plan. La gouvernance communautaire peut remplacer cette contribution, mais la transition doit réussir.

La migration plus large de l’entreprise reste inachevée. Shop est la première application à migrer. L’application principale Shopify comprend plus de 300 écrans, des widgets, une application Apple Watch, des complications et des Siri Shortcuts.

Shopify indique que cette application sera publiée en natif plus tard en 2026, puis que ses applications restantes suivront. Ces projets constituent un test plus exigeant que Shop, car ils intègrent davantage de fonctionnalités propres aux plateformes et de parcours essentiels pour les marchands.

D’ici là, la conclusion responsable reste limitée. Shopify a démontré qu’une migration native assistée par des agents peut fonctionner rapidement pour une application majeure. L’entreprise n’a pas encore établi le coût de maintenance à long terme sur l’ensemble de son portefeuille mobile.

Trois signaux indiqueront si le pari de Shopify tient

Les prochaines preuves devront démontrer la reproductibilité, une parité durable et un transfert stable vers l’open source.

Le premier signal sera la sortie native de l’application principale Shopify. Ses plus de 300 écrans et ses intégrations poussées avec Apple en font une migration plus difficile que Shop. Une publication dans les délais, avec des fonctionnalités préservées, renforcerait l’affirmation de Shopify selon laquelle sa méthode est extensible.

La qualité de cette publication compte davantage que la seule date. Les performances au démarrage, la stabilité des sessions, les temps de build, l’accessibilité, la continuité analytique et les parcours marchands devraient égaler ou améliorer la version React Native. Une sortie retardée ou inégale affaiblirait l’argument en faveur d’une migration greenfield rapide.

Le deuxième signal sera le maintien de la parité après le début du développement indépendant de fonctionnalités. Shopify devra montrer qu’iOS et Android continuent de publier des fonctionnalités équivalentes sans allonger les délais de revue. Les données issues de plusieurs cycles de publication compteront davantage que le rythme de migration.

Ce test touche au cœur du développement Shopify Swift Kotlin. Les agents peuvent traduire une fonctionnalité terminée, mais les équipes produit modifient aussi les exigences pendant l’implémentation. Des analyses et des comportements cohérents montreront si des spécifications partagées peuvent remplacer durablement un code source partagé.

Le troisième signal sera l’avenir des bibliothèques React Native de Shopify. Un fork fluide de React Native Skia, une gouvernance durable de FlashList et des orientations claires pour Restyle soutiendraient l’affirmation de Shopify selon laquelle l’entreprise gère cette sortie de manière responsable.

Une maintenance perturbée raconterait une autre histoire. Elle démontrerait que les changements d’architecture imposent des coûts au-delà des dépôts d’une seule entreprise. Ces coûts incomberaient aux développeurs qui ont planifié leurs projets autour des engagements antérieurs de Shopify.

Les responsables de l’ingénierie devraient suivre ces signaux avant de reproduire cette décision. Ils devraient également établir leur propre référence pour les crashs, le temps de démarrage, la taille de l’application, la durée des builds, la maintenance du framework et le travail de parité.

Ils peuvent ensuite lancer un prototype limité à partir d’une fonctionnalité réelle. Le test devrait inclure l’analytique, l’accessibilité, la navigation, les états d’erreur et les conventions des plateformes. Il devrait mesurer le temps de revue et la détection des défauts, et non simplement les lignes de code générées.

Le développement mobile natif de Shopify est important parce qu’il redéfinit la réutilisation à l’ère des agents. Il n’apporte pas de réponse universelle au débat entre React Native et le natif. Il pose plutôt une question exigeante : si l’implémentation devient peu coûteuse, où une organisation d’ingénierie doit-elle placer sa source de vérité ?

Les équipes devraient répondre à cette question à l’aide de données de production. Elles doivent suivre si les agents réduisent l’effort total de revue et de maintenance sur plusieurs publications. Si c’est le cas, des applications natives distinctes deviennent plus attrayantes. Si la coordination augmente plus vite que ne s’améliore la génération de code, une implémentation partagée conserve sa place.