Aller au contenu
useffect.sh
Planifier 30 min avec un senior
Scale · versions et New Architecture

Montée de version React Native et New Architecture

Depuis React Native 0.76, la New Architecture est activée par défaut. Depuis 0.82, on ne peut plus la désactiver. Chaque version de retard rend le saut plus cher. On le fait avec vous, par PRs, sans geler la roadmap.

Réponse courte

La montée de version React Native de useffect.sh remet une app existante sur une version récente de React Native ou d’Expo et la fait passer sur la New Architecture, Fabric et TurboModules compris. Elle s’adresse aux équipes dont l’app a pris plusieurs versions de retard, dépend de librairies qui n’ont pas suivi, ou doit quitter l’ancienne architecture : React Native 0.81 et Expo SDK 54 sont les dernières versions à l’autoriser. La mission commence par un diagnostic de cinq jours : inventaire des dépendances, modules natifs et patches, compatibilité New Architecture, état de la CI. Ensuite, un ou plusieurs seniors font la montée dans votre repo, version par version quand c’est nécessaire, par PRs relues selon votre process, avec une démo chaque semaine. Les libs sans mainteneur sont remplacées ou patchées, les modules natifs maison migrés, les tests et la CI remis au vert. Vous récupérez une app à jour, des runbooks et une procédure de montée de version que votre équipe peut rejouer.

de diagnostic avant la première PR
5 jours
React Native depuis la première version
2015
par semaine, dans votre repo
1 démo

01

Quand faire appel à nous

  • Plus de deux versions de retard.

    Chaque release de React Native déplace des choses dans le Podfile, les fichiers Gradle et les templates natifs. Le diff cumulé devient un projet en soi.

  • Des librairies qui ne supportent pas la New Architecture.

    Un composant clé n’a pas de version compatible Fabric, son dépôt est archivé, et le remplacer touche vingt écrans.

  • Des patches que personne ne sait réappliquer.

    Les correctifs patch-package dans node_modules s’accumulent, leur auteur est parti, et chaque bump les casse.

  • La CI tient avec des outils dépréciés.

    Xcode, le JDK, Gradle et Ruby sont tenus à bout de bras pour rester compatibles avec une vieille version. Le pipeline casse à chaque mise à jour des runners.

  • Le trunk CocoaPods passe en lecture seule.

    À partir du 2 décembre 2026, il n’accepte plus de nouveaux podspecs. Les builds continueront, mais les nouvelles versions de pods n’y arriveront plus.

  • Les stores exigent un SDK que votre version ne gère pas.

    Depuis le 28 avril 2026, Apple exige Xcode 26 et le SDK iOS 26 ; depuis le 31 août 2026, Google Play exige l’API 36 pour toute nouvelle app ou mise à jour. Une vieille version de React Native finit par ne plus passer.

02

Comment ça se passe

  1. 1 / Jours 1–5

    Diagnostic de la montée

    Inventaire des dépendances et de leur compatibilité New Architecture, modules natifs maison, patches, état de la CI et des tests. Diagnostic écrit de trois pages max, avec le chemin de montée et les points durs.

  2. 2 / Semaines 1–2

    Préparer le terrain

    Tests sur les parcours critiques s’ils manquent, CI reproductible, build de référence mesuré : cold start, taille, crash-free. C’est la base de comparaison pour la suite.

  3. 3 / Semaines 2–N

    Monter, version par version

    Diff officiel appliqué, libs remplacées ou patchées, modules natifs migrés vers TurboModules et Fabric, Hermes vérifié. Une PR par étape, relue selon votre process, démo chaque semaine.

  4. 4 / Dernières semaines

    Vérifier et transmettre

    Release progressive sur les deux stores, comparaison avec le build de référence, runbook de montée de version pour la prochaine fois.

03

Ce que vous recevez

  • Diagnostic écrit avec le chemin de montée
  • App sur une version récente, New Architecture activée
  • Dépendances remplacées ou patchées, patches documentés
  • Modules natifs migrés vers TurboModules et Fabric
  • CI et tests au vert sur la nouvelle version
  • Runbook de montée de version rejouable

04

Missions comparables

05

Questions fréquentes

Combien coûte une montée de version React Native ?

Ça dépend du nombre de versions à rattraper, des modules natifs maison, des libs à remplacer et de l’état des tests. Le diagnostic de cinq jours sert à le chiffrer sur pièces, avant la première PR.

Faut-il passer par toutes les versions intermédiaires ?

Pas toujours, mais souvent. Quand plusieurs versions séparent le projet de la cible, on monte par paliers pour isoler les régressions. Si l’ancienne architecture est encore active, on passe par React Native 0.81 ou Expo SDK 54, on active la New Architecture, on vérifie, puis on continue : c’est le chemin recommandé par l’équipe React Native.

Peut-on continuer à livrer pendant la montée ?

Oui. La montée vit sur une branche rebasée régulièrement, et les PRs arrivent par étapes dans votre process de revue. Vos releases continuent. On évite seulement d’ouvrir un gros chantier natif en parallèle.

Notre app est sur Expo, est-ce différent ?

Le chemin est plus court : chaque SDK Expo cible une version de React Native, et prebuild régénère les projets natifs. Le travail porte alors sur les dépendances, les config plugins et vos modules natifs. Si l’app est encore en bare React Native, la migration vers Expo peut faire partie du chantier.

Que devient notre code natif maison ?

Les modules Swift, Objective-C, Kotlin ou Java sont migrés vers TurboModules et Fabric, ou vers Expo Modules si l’app est sur Expo. Ceux qui ne servent plus sont retirés, avec un ADR qui explique pourquoi.

Qui s’occupe de la prochaine montée ?

Votre équipe. On laisse un runbook de montée de version, les patches documentés et une CI qui vérifie le build sur les deux plateformes. La suivante devrait pouvoir se faire sans nous.

Voir aussi

Les termes de cette page

Mis à jour le 26 octobre 2026

Votre version de React Native a une date de péremption.

30 minutes avec un senior pour estimer le chemin de montée. Gratuit, réponse sous 48 h.

Planifier 30 minRetour à l’accueil