Expo Agent CLI, iPhone Duo et défilement natif

Cette édition de rattrapage couvre la période du 21 au 28 octobre 2026. Expo outille la préparation et le lancement des apps par les agents. Côté interface, l’iPhone Duo et Screens demandent de vérifier comment les barres natives réagissent à la fenêtre et au défilement.

Expo Agent CLI prépare l’environnement avant de chercher un bug

Le billet Expo du 27 octobre (nouvelle fenêtre) présente @expo/agent-cli, une CLI expérimentale qui s’appuie sur Expo CLI, EAS CLI et expo-doctor. Elle renvoie du JSON, des codes de sortie et la prochaine commande à exécuter. Son intérêt mobile est précis : éviter qu’un agent cherche un bug JavaScript alors que le module natif ajouté exige un development build.

npx --yes @expo/agent-cli@latest status indique si le projet peut tourner dans Expo Go et si une reconstruction native est nécessaire, sans lancer l’app. dev --ios prépare le bon environnement et réutilise le build existant quand il convient. dev --plan expose les étapes avant exécution.

Pour une équipe, cela donne deux points de contrôle. Avant le run, vérifier l’environnement attendu. Après la modification, smoke --ios lance ou réutilise l’app, contrôle son chargement et cherche les erreurs d’exécution. Le résultat métier mérite ensuite son propre scénario de test.

Chaque worktree dispose de son simulateur ou émulateur. Le cloud exige --eas ou une configuration explicite, car builds et sessions consomment des crédits. Les commandes et leurs sorties peuvent encore changer.

iPhone Duo déplace l’audit des safe areas sur les côtés

Le guide Expo du 23 octobre (nouvelle fenêtre) demande SDK 58 et Xcode 27.1 pour tester l’iPhone Duo. Dans les poses où iOS place les barres dans un rail vertical, le contenu doit respecter un inset gauche ou droit de 84 points. Une interface qui ne traite que le haut et le bas peut donc masquer des actions sur le bord.

La Stack et les NativeTabs d’Expo Router laissent iOS déplacer les contrôles natifs. Le travail restant concerne le contenu des écrans. Dans une ScrollView, Expo recommande d’entourer le contenu avec SafeAreaView. Les boutons flottants et les toasts doivent intégrer les insets horizontaux. La largeur se lit au rendu avec useWindowDimensions, car elle change pendant le pliage ou en Split View.

Pour valider un formulaire ou une liste, garder l’écran ouvert pendant le pliage, la rotation et le passage en Split View. Vérifier que l’état et la position de défilement restent conservés, puis que chaque action reste accessible. Les barres en JavaScript demandent une revue distincte. Le SplitView natif reste expérimental en SDK 58.

ScrollViewMarker explicite la liste suivie par les barres natives

Software Mansion décrit le 22 octobre (nouvelle fenêtre) un échec discret des heuristiques natives. Ajouter un backgroundColor à une View peut modifier son aplatissement par React Native et faire perdre à UIKit la liste qu’il observait. La liste défile toujours, mais la tab bar Liquid Glass peut cesser de se minimiser.

ScrollViewMarker enregistre explicitement la liste auprès de l’écran Stack ou Tabs le plus proche. Sur Android, il fournit aussi la cible de liftOnScroll au header Material 3. Le composant attend un seul enfant défilant et un marqueur par écran. Une FlatList peut être entourée directement. Pour FlashList, l’intégration passe par renderScrollComponent.

Cette API appartient à Screens 5.0.0-alpha. En 4.x, le billet conserve collapsable={false} comme solution. Pour une équipe déjà en production sur cette branche, cela permet de traiter le problème de hiérarchie sans engager une migration de navigation. Le cas de régression à garder est visuel : ajouter un bandeau au-dessus de la liste, défiler, puis observer la réaction des barres. Une assertion sur la présence des lignes ne détecterait pas ce défaut.