React Native 0.87 : contrats publics, mémoire native et OTA

React Native 0.87 pose une question très concrète aux applications existantes : quelles dépendances reposent encore sur des détails internes du framework ? Autour de cette migration, deux lectures complètent le tableau : la mémoire native que le GC JavaScript voit mal, et les habitudes qui rendent une OTA réversible.

Une API publique mieux délimitée

La release React Native 0.87 (nouvelle fenêtre) active la Strict TypeScript API par défaut. Les types viennent du code source ; les imports profonds dans react-native/Libraries/* deviennent des erreurs de typage. Les refs disposent de types dédiés, comme ViewInstance et TextInputInstance. La toolchain évolue aussi : Node.js 22.13.0 minimum, prise en charge d’AGP 9 et Kotlin 2.0 ou supérieur.

Pour une équipe, la première étape utile est un inventaire des imports internes et des erreurs du typecheck. Classer chaque erreur entre code de l’app, bibliothèque maintenue et bibliothèque à remplacer évite d’empiler des casts qui masqueraient le vrai problème. Une compilation TypeScript verte ne remplace ensuite ni la compilation native ni le test des écrans qui manipulent directement les refs.

Swift Package Manager est encore expérimental. Le changer en même temps que les types et la toolchain rendrait les régressions plus difficiles à attribuer : mieux vaut garder une variable à la fois.

Unmount ne signifie pas mémoire immédiatement libérée

Software Mansion décrit des shadow nodes Fabric conservés après des révisions du Shadow Tree (nouvelle fenêtre). Ses mesures portent sur des vues animées montées puis démontées ; une collecte peut libérer une quantité de mémoire native que l’activité JavaScript seule n’explique pas.

L’enseignement pratique est de suivre plusieurs indicateurs ensemble. Si la mémoire augmente pendant une navigation répétée, conserver la durée du test, le nombre de transitions et l’état des animations. Une seule capture après fermeture d’un écran ne dit pas si la mémoire est encore référencée, en attente de collecte ou réellement perdue.

OTA : définir la compatibilité avant l’urgence

Le guide Expo sur les mises à jour OTA (nouvelle fenêtre) distingue JavaScript et assets du code natif, et recommande preview, contrôle de compatibilité, déploiement progressif et retour arrière.

Avant un correctif urgent, préparer un petit parcours reproductible : installer le binaire visé, charger la mise à jour preview, ouvrir les écrans touchés et vérifier un redémarrage. Le plan de retour doit identifier le bundle précédent et la population concernée. Ce travail est particulièrement utile après un changement de SDK : une OTA peut corriger le JavaScript sans rendre compatible un module natif absent du binaire.

Le fil conducteur de ces trois sujets est la traçabilité : savoir quelle API est publique, quelle mémoire on mesure et quel runtime peut recevoir une mise à jour.