Ce que dit la source

Le plafond de verre de React Native chez un acteur à très grande échelle : friction permanente avec les API natives et les nouveautés OS, coûts de migration imposés par la roadmap de Meta (New Architecture), performance et qualité perçue sur les parcours critiques, et dépendance à une couche d'abstraction que l'on ne contrôle pas.

• >Retournement symbolique : Shopify était la vitrine entreprise de React Native depuis 2020, avec une équipe dédiée et un sponsoring visible de l'écosystème. Le signal envoyé dépasse le cas Shopify.
• >La thèse de l'article : le gain principal du cross-platform était l'économie de duplication de code. Avec des LLM capables de porter une feature Swift vers Kotlin, cet arbitrage économique s'inverse.
• >Le coût caché de l'abstraction : chaque nouveauté iOS/Android arrive avec un délai, chaque bridge natif est du code custom à maintenir, et les migrations majeures du framework sont subies, pas choisies.
• >La performance et le "feeling natif" restent le talon d'Achille sur les écrans complexes, malgré des années d'optimisation interne.
• >Le vrai coût d'une app mobile n'est pas la ligne de code : c'est le design, le produit, la QA sur deux plateformes et les releases. Ce poste-là ne disparaît pas avec le natif.
• >À l'échelle de Shopify, financer deux équipes natives est soutenable. Pour une DSI avec trois développeurs mobiles, l'équation reste inchangée.

• >Beaucoup lisent la justification par l'IA comme un habillage narratif : la vraie raison serait que React Native n'a jamais tenu ses promesses à cette échelle, et "grâce à l'IA" sonne mieux en communication corporate que "on s'est trompés".
• >Duplication assistée par LLM = dette technique dupliquée. Plusieurs commentateurs pointent que deux implémentations générées divergent inévitablement, produisant des bugs asymétriques iOS/Android impossibles à tracer.
• >Le coup porté à l'écosystème React Native : Shopify était un contributeur majeur. Départ d'un sponsor de ce poids, effet domino redouté sur les bibliothèques communautaires.
• >Le coût humain du zigzag : les équipes qui ont passé cinq ans à devenir expertes RN doivent réapprendre SwiftUI et Compose. Le "technology bet" à 5 ans a un prix, rarement chiffré dans les billets d'ingénierie.
• >Argument de survivorship bias : on ne compte que les migrations spectaculaires vers le natif, jamais les milliers d'apps RN qui tournent très bien et dont personne ne blogue.
• >Certains rappellent qu'Airbnb avait tiré les mêmes conclusions en 2018, avec des raisons quasi identiques — l'industrie n'aurait donc rien appris en sept ans.

Alternatives citées : Flutter (souvent cité, mais les inquiétudes sur l'engagement long terme de Google reviennent systématiquement), Kotlin Multiplatform et Compose Multiplatform (l'option la plus défendue : logique métier partagée, UI native), Expo (jugé nettement supérieur au RN "brut" et rarement mentionné dans l'article), un cœur partagé en Rust ou C++ avec UI native (approche Dropbox/Signal), Capacitor/Ionic et .NET MAUI pour les cas moins exigeants.