React Native 0.88 : migration iOS, bundling et gestes natifs

React Native 0.88 et Expo SDK 58 ouvrent plusieurs chantiers distincts : le cycle de vie iOS, les événements, le temps de transformation JavaScript et l’adaptation aux fenêtres redimensionnables. Cette édition les remet en perspective avec les nouveautés de Gesture Handler et une manière de séparer navigation et vérification dans les tests de parcours.

React Native 0.88 : séparer migration et expérimentation

Le billet React Native 0.88 (nouvelle fenêtre) décrit une version sans rupture de l’API utilisateur depuis 0.87. Cela n’efface pas le travail d’intégration native : le SDK iOS 27 impose UIScene. L’entrée React Native doit passer dans SceneDelegate, les callbacks d’URL et d’activité utilisateur être transmis à RCTLinkingManager, et Info.plist déclarer UIApplicationSceneManifest. Le support reste limité à une scène.

Le dispatch des événements adopte EventTarget par défaut ; les listeners impératifs sur les refs restent en Canary. Les handlers déclaratifs restent le chemin habituel. Les intégrations qui utilisent les mécanismes internes d’événements méritent une vérification ciblée.

Autres apports : les polices variables sur Text et TextInput, et ArrayBuffer dans les TurboModules Java. Pour les appels synchrones, la mémoire empruntée ne reste valide que pendant l’appel ; il faut copier les données à conserver. Swift Package Manager reste expérimental, CocoaPods demeure supporté.

Pour préparer une mise à jour, séparer les essais évite de mélanger les causes d’un échec : d’abord compiler et lancer l’app, ensuite tester le retour depuis une URL et les activités utilisateur, enfin essayer les API expérimentales dans une branche dédiée. Un parcours d’authentification qui revient dans l’application est un bon candidat : l’écran final doit être correct après un lancement à froid comme lorsque l’app est déjà ouverte.

L’annonce X d’origine (nouvelle fenêtre) est conservée comme référence historique. Le billet détaillé porte la date du 19 octobre ; il complète cette édition datée du 17.

Noxcturnal : accélérer le bundling à froid, avec des limites

Le changelog SDK 58 (nouvelle fenêtre) présente Noxcturnal, un transformer Rust expérimental. Sur l’application de test d’Expo, le bundle à froid passe de 5,26 à 2,46 secondes ; 443 fichiers retombent encore sur Babel. C’est une mesure de transformation dans un contexte précis, pas un gain promis sur le démarrage d’une app ni sur chaque modification à chaud.

L’option est experiments.noxcturnalTransformWorker. Elle exige l’absence de transformer personnalisé et de plugins ou presets Babel personnalisés ; les fichiers nécessitant les transforms Reanimated ou Worklets sont exclus. Avant de l’activer durablement, comparer le même projet, sur la même machine, avec des caches dans le même état. Puis vérifier animations, compilation de production et source maps : une compilation plus rapide doit produire une application qui reste débogable.

La démonstration d’Evan Bacon (nouvelle fenêtre) illustre le même découpage entre transformation Rust et fallback Babel décrit par Expo.

Écrans pliables : tester la fenêtre, pas seulement le téléphone

Avec SDK 58, la Stack et les NativeTabs d’Expo Router s’appuient sur les barres système placées par iOS sur les écrans pliables ; les safe areas demandent en revanche plus d’attention, avec des SafeAreaView à ajouter, notamment dans les listes défilantes, pour les marges horizontales de l’iPhone Duo. Sa documentation distingue la taille de la fenêtre, qui pilote le layout, de la charnière, utile aux interactions. Pour une équipe mobile, cela suggère un exercice concret : redimensionner un écran pendant qu’un formulaire ou une liste est déjà rempli, puis vérifier la conservation de l’état, le focus et la visibilité des actions.

Un écran qui paraît correct en deux captures peut échouer pendant la transition : clavier ouvert, feuille modale visible, panneau secondaire masqué ou bouton déplacé sous une barre système. Les écrans custom demandent donc une revue distincte de ceux construits avec les composants de navigation du système. Voir les repères iPhone Duo d’Expo (nouvelle fenêtre).

Gesture Handler 3.4 : surveiller le feedback des pressions

La release 3.4.0 (nouvelle fenêtre) ajoute le support Swift Package Manager sur iOS tout en gardant CocoaPods. Elle modifie aussi le comportement des pressions rapides : immediatePressOut permet de choisir quand terminer l’état pressé, et Android déclenche onPressIn au début du press natif.

L’intérêt est visible sur un bouton dont la couleur ou l’échelle change pendant l’appui. Vérifier seulement que onPress a été appelé ne suffit pas à juger le ressenti. Rejouer un tap bref, un appui prolongé, un glissement qui annule la pression et une interaction pendant le défilement permet de repérer un feedback absent ou une action déclenchée au mauvais moment.

Le changelog mentionne aussi des corrections de gestes annulés, de hit testing et de pointerEvents. La compatibilité de la version choisie avec React Native doit être contrôlée avant migration ; la ligne 2.x s’arrête à RN 0.87 selon Software Mansion.

Tests de parcours : un modèle pour agir, un autre pour juger

La documentation e2e (nouvelle fenêtre) permet de configurer judge séparément du modèle qui pilote agent.act. Ce juge prend en charge les assertions, attentes et extractions ; le rapport identifie le modèle utilisé. Cette distinction est pertinente pour les tests mobiles : naviguer jusqu’à un écran et vérifier précisément son contenu sont deux tâches différentes.

Un scénario de connexion devrait exprimer le résultat attendu : identité affichée, absence de message d’erreur, retour à la bonne destination. « La connexion fonctionne » laisse trop de place à l’interprétation. Conserver aussi les preuves du parcours permet d’examiner un échec sans dépendre du seul verdict du modèle.

Le choix d’un juge distinct ne garantit ni un coût inférieur ni une meilleure détection. Comparer plusieurs exécutions avec des cas volontairement cassés aide à voir s’il repère une régression réelle. Les changements de modèle doivent être évalués sur ces mêmes cas, comme les changements de dépendances natives.