Développer une application séparément pour iOS et Android demande de faire vivre deux implémentations. Pendant des années, partager le code a permis de consacrer davantage de budget aux fonctionnalités et à leur évolution. Avec les agents de programmation, une partie de ce travail peut désormais coûter moins cher. Le choix technique mérite donc un nouvel examen.
Chez Appik, nous voyons ce changement comme une possibilité supplémentaire pour les projets mobiles. Notre expérience du natif, de React Native et du web nous sert à comparer les options en fonction du produit, de ses utilisateurs et de sa maintenance.
Shopify et Coinbase réévaluent leur développement mobile
Le 10 septembre 2026, Shopify annonce son retour vers Swift et Kotlin. Les agents ont changé le coût des deux implémentations. L'entreprise précise que ses applications React Native sont rapides et que le choix du framework lui avait apporté les bénéfices attendus.
Coinbase décrit une réécriture de son application mobile en Swift et Kotlin, assistée par IA, dans une offre de recrutement officielle. C'est un projet en cours, pas une annonce de migration déjà achevée.
Ces décisions posent une question utile pour une direction produit : si produire et faire évoluer deux versions devient moins coûteux, quels avantages propres à chaque plateforme justifient cet investissement pour notre application ? La réponse dépend aussi des équipes et des ressources disponibles.
Pourquoi Appik a adopté le code partagé
Avant de travailler avec React Native, nous développions déjà des applications natives iOS et Android. La mutualisation répondait à un problème concret : une fonctionnalité livrée sur une plateforme devait souvent être reconstruite sur l'autre, puis évoluer de la même manière.
Partager du code permettait de réduire ce travail répétitif, tout en conservant des applications performantes. Selon les parcours, certaines règles métier et certains composants pouvaient également servir au web. Les adaptations aux plateformes restaient nécessaires.
Pour une PME qui doit proposer un outil sur téléphone et ordinateur, cette logique garde de la valeur. Le budget peut servir à améliorer le parcours terrain, relier l'ERP ou préparer la reprise du produit par une autre équipe. Le pourcentage de code partagé est un moyen ; le résultat attendu est un produit utilisable et durable.
React Native peut offrir d'excellentes performances
Une interface React Native n'est pas une page web placée dans une application. L'architecture de React Native relie React aux composants et aux capacités natives. Le choix des outils de rendu et l'organisation des calculs comptent ensuite beaucoup.
Skia et Graphite pour le rendu graphique
React Native Skia s'appuie sur le moteur graphique C++ Skia et son intégration JSI. Il permet de dessiner des interfaces, graphiques et effets dans un canvas, sans demander à JavaScript de calculer chaque pixel.
La v3.0.2 du dépôt de William Candillon, publiée le 3 octobre 2026, choisit Graphite comme API par défaut. Cette évolution concerne la nouvelle branche v3 ; elle ne signifie pas que les applications utilisant les anciennes versions ont toutes changé de moteur.
Google décrit Graphite comme une architecture adaptée aux API GPU modernes, permettant notamment de préparer le travail graphique avec des enregistreurs indépendants. Son intérêt est concret pour les rendus personnalisés ; son adoption doit être vérifiée sur les appareils visés.
Reanimated pour les interactions et les animations
Reanimated utilise des worklets sur le thread d'interface. La logique d'une animation peut ainsi fonctionner sans attendre que le runtime JavaScript principal ait terminé une autre tâche.
Cela donne des outils adaptés à une carte que l'on déplace, un graphique interactif ou une transition liée au geste. Le guide de performance de Reanimated rappelle toutefois que les versions, les propriétés animées et le nombre de composants influencent le résultat. Une bibliothèque ne corrige pas automatiquement une architecture coûteuse.
Worklets pour placer les calculs au bon endroit
React Native Worklets distingue les runtimes RN, UI et Worker. Certaines fonctions JavaScript peuvent s'exécuter dans un runtime dédié, notamment pour des traitements de données. Elles ne deviennent pas pour autant du code Swift ou Kotlin.
L'enjeu est d'éviter qu'un calcul monopolise les ressources nécessaires à l'interaction. Les échanges entre runtimes ont eux aussi un coût : déplacer tout le travail sans mesurer serait une mauvaise stratégie.
Legend List pour les longues listes
Legend List v2 utilise la virtualisation et propose le recyclage des composants. Le défilement peut réutiliser des éléments plutôt que les recréer. Les benchmarks présentés comparent des solutions de listes React Native ; ils ne démontrent pas une victoire sur toutes les listes natives.
Ces outils comptent pour un fil de messages, un catalogue ou une liste d'interventions. Une image trop lourde ou des lignes qui recalculent sans cesse leur contenu peuvent malgré tout dégrader le défilement.
React Native peut-il faire mieux qu'une implémentation native ?
Oui, c'est possible sur un parcours donné. Un rendu React Native qui utilise un moteur C++ et le GPU peut demander moins de travail qu'une autre implémentation du même écran reposant sur de nombreux composants et mises à jour. C'est une possibilité technique à mesurer, pas un résultat que nous promettons pour chaque projet.
Swift et Kotlin permettent eux aussi d'utiliser le GPU et des moteurs spécialisés. Les outils cités montrent surtout pourquoi un langage ou un framework ne suffit pas à prédire la fluidité.
Pour comparer deux options, nous retenons les mêmes interactions, contenus et appareils, avec des versions de production. Nous examinons le temps de réponse, les images perdues pendant le défilement, le démarrage, la mémoire et la consommation d'énergie. Un écran fluide sur un téléphone haut de gamme ne prouve pas que l'application entière répond aux contraintes du terrain.
L'IA élargit les choix, y compris pour React Native
Les agents peuvent aider à adapter une fonctionnalité, préparer des tests et proposer une implémentation sur une autre plateforme. Dans notre pratique, ils sont aussi très utiles sur React et React Native. Nous ne pouvons pas attribuer avec certitude cette efficacité au volume de leurs données d'entraînement, que nous ne connaissons pas.
La question économique porte sur le coût du produit dans la durée. Deux applications natives demandent toujours des tests, des publications et un suivi des évolutions des systèmes. Une base partagée demande également du travail sur les dépendances, les parties natives et les différences entre plateformes.
Une organisation équipée pour maintenir deux versions peut profiter davantage de l'accès direct aux outils Apple et Google. Une équipe qui doit livrer sur mobile et web peut privilégier la mutualisation. Une application React Native existante qui répond aux usages mérite d'être évaluée avant de financer une réécriture.
Bonani et notre pratique du natif
Nous avons développé Bonani, un petit carnet d'anniversaires, en natif pour iOS et Android. Son périmètre limité nous permet d'explorer cette approche sur un produit concret, avec des données locales, l'accès aux contacts et des rappels.
Bonani utilise SwiftUI et SwiftData sur iOS, Kotlin, Jetpack Compose et Room sur Android. Les interfaces sont distinctes, mais les règles et les exemples de test restent communs. Un anniversaire sans année ne produit pas d'âge ; un 29 février reste enregistré comme tel, même lorsque son rappel tombe le 1er mars.
Bonani ne fournit pas un benchmark contre React Native et ne représente pas la complexité d'une application de grande entreprise. Ce projet nous permet de travailler directement avec les conventions et les contraintes de chaque plateforme.
Chez Appik, nous voulons utiliser l'expérience accumulée sur ces dix dernières années pour choisir la stack adaptée à chaque projet, avec l'appui des agents. L'équipe garde la responsabilité de l'architecture, de la validation sur les appareils et de la mise en production.
Quelle approche pour votre application ?
Vous préparez une application mobile ou souhaitez faire évoluer un produit existant ? Contactez Appik pour en discuter. Nous pouvons examiner vos usages, vos intégrations et les contraintes qui orientent le choix entre natif, React Native et web.
Sources et références
- Shopify · Retour au natif
- Coinbase · Réécriture mobile en cours
- React Native · Architecture
- Shopify · Skia, C++ et JSI
- React Native Skia · Graphite par défaut dans la v3.0.2
- Google · Architecture graphique Graphite
- Reanimated · Animations et worklets
- Reanimated · Guide de performance
- React Native Worklets · Runtimes RN, UI et Worker
- Legend List · Virtualisation, recyclage et benchmarks v2
Swiss Made Software
