New Architecture

Dans un projet, l’état de l’architecture se lit à deux endroits : newArchEnabled dans android/gradle.properties et la variable RCT_NEW_ARCH_ENABLED lue par le Podfile. Sur un projet Expo géré par prebuild, c’est la clé newArchEnabled de app.json qui pilotait ces deux fichiers. Depuis la 0.82 ces réglages ne servent plus à désactiver quoi que ce soit, mais on les trouve encore dans des projets qui ont traîné plusieurs upgrades, et ils trompent souvent sur ce qui tourne vraiment.

Le vrai sujet de migration, ce sont les dépendances. Une librairie écrite pour le bridge passe par la couche d’interop, que l’équipe React Native conserve « dans un avenir prévisible » sans date de retrait. Ça tourne, mais ça masque des bugs : events perdus, measure qui renvoie des zéros, props non typées qui arrivent dans le mauvais format. L’outil utile reste reactnative.directory (nouvelle fenêtre) et son filtre New Architecture, puis le changelog de chaque dépendance native. React Native 0.81 et Expo SDK 54 sont les dernières versions qui acceptent encore l’ancienne architecture ; c’est le palier recommandé pour migrer avant de monter plus haut.

Ce que je vérifie en audit : la version de React Native, la présence de react-native-reanimated 4 (qui exige la New Architecture) ou 3, et les warnings Legacy Architecture dans les logs Metro au premier lancement. À partir de la 0.84, le code de l’ancienne architecture n’est plus compilé dans les builds iOS, ce qui réduit la taille du binaire et le temps de build. Une app encore bloquée par une librairie sans support doit soit la remplacer, soit contacter le mainteneur, soit rester en 0.81 en connaissance de cause.