Retour au natif : lire une décision d’équipe sans en faire une règle

Coinbase : un signal sur l’organisation du développement

React Native Rewind #60 (nouvelle fenêtre) relaie un projet de retour de Coinbase vers Swift et Kotlin, en attribuant à Adam Wolf l’idée que les agents réduisent le coût de développer deux fois une fonctionnalité. Ce signal est rapporté par la newsletter ; il ne fournit pas ici un bilan technique primaire de la migration ni une mesure comparative entre les stacks.

Ce qui mérite discussion est l’hypothèse économique : si écrire du code sur deux plateformes devient moins coûteux, le partage de code doit être apprécié avec d’autres critères. La synchronisation des sorties, la cohérence métier et la maintenance ne disparaissent pas lorsque la génération de code s’accélère.

Shopify décrit une expérience plus précise

Dans son billet Back to native (nouvelle fenêtre), Shopify explique le travail sur ses applications et distingue le cas de Shop du chantier plus large de l’application Shopify. L’entreprise continue aussi à soutenir React Native Skia pendant la transition. Ce retour ne signifie donc pas l’arrêt immédiat de tout investissement dans l’écosystème.

Pour une équipe React Native, le bon point de comparaison est son propre produit. Une app majoritairement composée de formulaires et de listes n’a pas le même profil qu’une expérience qui multiplie les composants spécifiques au système. Une équipe avec des spécialistes iOS et Android peut aussi absorber des coûts qu’une petite équipe commune ne peut pas répartir.

Avant de traduire ces annonces en choix d’architecture, il faut nommer le problème rencontré : intégration d’une capacité native, performances sur un parcours, rythme de livraison ou maintenance des dépendances. Un changement de framework peut répondre à certains de ces problèmes, sans résoudre ceux qui viennent des données ou de l’organisation des releases.