Le 31 juillet dernier, Chain React 2026 s'est refermée à Portland après trois jours de conférences. La sixième édition a réuni Meta, Microsoft, Amazon et Expo, avec Neil Dhar de Meta en ouverture sur Static Hermes en production. Ce que la scène a acté compte plus que ce qu'elle a dit. En huit mois, React Native a refermé une porte que Meta laissait ouverte depuis 2015 : celle du "on n'est pas encore au niveau du natif". Pour un dirigeant qui prépare un lancement mobile à l'automne, le calcul n'est plus celui du printemps.
Ce que huit mois viennent de bouger
Reprenons le film. Le 11 février 2026, React Native 0.84 rendait Hermes V1 moteur JavaScript par défaut. Les équipes qui ont migré publient un cold start 40% plus rapide, un rendu 35% plus rapide, une mémoire baissée de 25%, des appels JS vers natif accélérés d'un facteur 40. Quelques jours plus tard, Expo SDK 55 sortait sans plus aucun flag pour la nouvelle architecture. L'ancienne, sur bridge sérialisé, était juste supprimée du code.
En avril, React Native 0.85 débarquait avec un moteur d'animation unifié pensé pour Reanimated. En mai, Expo SDK 56 embarquait React 19.2 et coupait 40% du temps de build natif. En juin, la 0.86 corrigeait le comportement edge to edge d'Android 15, sans casser aucune API publique pour la seconde release consécutive. La State of React Native 2025 comptait 80% d'adoption de la nouvelle architecture parmi les répondants. Les 20% restants n'ont plus le choix : sur SDK 55 et suivants, la migration n'est pas une option.
Sur les stats de marché, l'écart avec Flutter s'est inversé fin 2025. La Stack Overflow Developer Survey 2025 place React Native à 14,51% d'usage, contre 13,55% pour Flutter. Et sur les offres d'emploi LinkedIn, React Native pointe à un ratio d'environ six pour un.
Ce que la parité native change concrètement
La question qu'on nous pose le plus, chez Klaapp, quand un dirigeant nous appelle pour un premier projet mobile : "vous êtes sûrs que React Native vaut le natif ?". Jusqu'à l'an dernier, la réponse honnête tenait en trois nuances. Pour 90% des cas oui, mais l'animation complexe, la mémoire sur les vieux Android et la latence bridge restaient des trous. Ces trous se sont refermés cette année.
Un cold start sous 800 millisecondes sur un iPhone 13, un rendu à 120 FPS sur une liste de mille items animés, des gestures qui tiennent la comparaison avec SwiftUI. Ce ne sont plus des cas isolés, ce sont les benchmarks de la 0.85. Les Nitro Modules et les Turbo Modules donnent une porte de sortie propre quand un composant natif reste incontournable, sans réintroduire un bridge pour tout le reste.
Le coût de développement, lui, n'a pas bougé. Deux plateformes couvertes par une seule équipe, une seule roadmap. Sur un budget PME entre 40 et 80 000 euros pour une V1, la différence avec un couple iOS plus Android natifs reste de l'ordre de un pour deux, souvent plus quand le produit partage sa nav avec un web.
Le calcul redevient contextuel, plus dogmatique
L'ancien débat "natif ou cross platform" s'appuyait sur un vrai gap de performance. Ce gap ferme la porte, l'arbitrage se déplace ailleurs.
Trois cas où le natif garde du sens. Un produit qui exploite en profondeur un SDK Apple récent, ARKit, HealthKit, App Intents ou LiveActivities, gagne encore à être écrit en Swift natif, tout simplement parce que Meta publie les bindings React Native trois à six mois après Apple. Un jeu 3D à moteur maison ne se fait pas en React Native, la question ne se pose même pas. Une équipe déjà 100% iOS chez Swift et qui n'a qu'un million d'utilisateurs iOS n'a pas de raison rationnelle de rebasculer.
Les autres cas basculent vers React Native. Une équipe qui doit livrer iOS plus Android en même temps sur un budget PME. Un produit qui partage sa logique métier avec un back office web déjà en React et TypeScript. Une roadmap qui demande des cycles de release courts et pilotables par feature flags. Un projet qui doit vivre trois à cinq ans avec une équipe qui tourne, sans dépendre d'un profil senior Swift ou Kotlin à double casquette.
Flutter garde une niche. Sur le desktop et l'embarqué, Flutter reste devant. Sur du mobile pur avec un pipeline design custom et une petite équipe design system, il continue à séduire. Mais sur le mobile généraliste, avec les stats de recrutement de 2025 et 2026, l'argument "vivier de développeurs" penche désormais franchement du côté React Native.
Le vrai coût de la parité : la dette technique
Un point qu'on ne peut pas balayer. Cette parité arrive avec une contrepartie. Toute application React Native construite avant 2024 et jamais remise à niveau vit sur du code qui ne compile plus sur SDK 55. Le saut SDK 53 vers 55 traverse deux majeurs de React Native (0.79 à 0.83), la migration Reanimated v3 vers v4, la disparition du legacy interop layer, et souvent une réécriture des modules natifs custom.
Ce chantier se chiffre en semaines de dev pour une app moyenne. La question à poser aujourd'hui à votre équipe technique n'est pas "quand on migre", c'est "quelle release SDK on cible sur les six prochains mois, et quelle enveloppe on prévoit". Une équipe sans cette réponse a un impensé qui va lui rentrer dedans à l'occasion d'un incident, ou pire, d'un rejet App Store sur un SDK trop ancien.
Ce qu'on ferait à votre place
Trois pistes concrètes, selon votre situation.
Si vous hésitez pour un premier lancement mobile cet automne. Ne partez pas sur un couple iOS plus Android natif par défaut. Sur les trois quarts des cahiers des charges qui nous arrivent, React Native version 2026 tient la performance, économise la moitié du budget, et raccourcit les cycles de release d'un facteur deux. Le choix natif reste défendable, mais il doit venir d'une contrainte identifiée, pas d'une intuition héritée d'il y a cinq ans.
Si vous avez déjà une app React Native qui n'a pas été touchée depuis dix huit mois. Faites auditer l'état du SDK et de la nouvelle architecture avant décembre. La release Apple d'automne va durcir les exigences côté App Store, et une app bloquée sur un SDK trop ancien risque de refuser une simple mise à jour de contenu. Le coût de l'audit est faible, celui d'un blocage en production peut coûter des semaines.
Chez Klaapp on fait tourner du React Native sur la nouvelle architecture depuis Fillzz jusqu'à Pandook, et on voit concrètement le fossé se creuser entre les apps qui ont fait le pas et celles qui traînent. Ce n'est pas une opinion, c'est un signal qui remonte des métriques de production et des temps de review interne. Ce mois d'août est un bon moment pour se poser la question, avant que la fenêtre d'automne ne se referme.