Expo Maps stable, Screens 5 en bêta et tests mobiles rejouables

Expo Maps devient stable : le choix dépend des interactions attendues

Expo annonce la stabilité d’Expo Maps (nouvelle fenêtre). La bibliothèque expose Google Maps sur Android et Apple Maps sur iOS. La documentation (nouvelle fenêtre) recommande ~58.0.11 pour le SDK 58 et précise les contraintes à examiner avant de choisir le composant d’une carte mobile.

Apple Maps demande iOS 17 ou plus. Les callbacks de tap sur les marqueurs et les tracés, comme onMarkerClick et onPolylineClick, ainsi que la sélection programmatique avec selectMarker ou selectAnnotation, exigent iOS 18 ou plus. Pour une carte qui ouvre une fiche après sélection d’un marqueur, la version minimale devient donc une décision produit : il faut prévoir le comportement du parcours sur iOS 17.

Le fournisseur reste propre à chaque plateforme. Une équipe qui exige Google Maps sur iOS devra choisir une autre intégration. Sur Android, Expo demande d’activer Maps SDK for Android dans un projet Google Cloud, d’ajouter la clé à la configuration Expo, puis de créer un nouveau development build. Un essai utile consiste à vérifier le parcours complet, de l’affichage de la carte à l’ouverture du détail, sur les versions d’OS réellement supportées.

Screens 5 : préparer les icônes d’onglets pendant la bêta

La première bêta de react-native-screens 5 (nouvelle fenêtre), publiée le 3 novembre, ajoute le support de React Native 0.88. Elle apporte aussi des modales confinées à leur conteneur sur iOS, par exemple une colonne de SplitView, et des transitions configurables pour Stack v5 sur Android.

Le changement à repérer dès maintenant concerne les onglets iOS. Les types d’icône templateSource et xcasset disparaissent, et les icônes imageSource sont teintées par défaut. Une ancienne icône templateSource devient un imageSource avec renderingMode: 'template'. Pour conserver les couleurs d’une image, il faut au contraire préciser renderingMode: 'original'. La PR de migration des icônes (nouvelle fenêtre) détaille également les remplacements pour les assets Xcode et les symboles personnalisés.

La version reste en bêta. Pour une équipe qui utilise les onglets natifs, inventorier les sources d’icônes donne déjà un périmètre de migration concret. Lors de l’essai, comparer les onglets sélectionnés et inactifs, en thèmes clair et sombre, permettra de vérifier que la nouvelle teinte conserve leur lisibilité et les couleurs voulues.

Tests mobiles : enregistrer avec l’agent, rejouer en CI

Le tutoriel Argent e2e (nouvelle fenêtre) décrit un parcours que l’agent exécute sur l’application avant de le sauvegarder dans un fichier YAML sous .argent/e2e/. Ce fichier se relit et se versionne avec le code. argent e2e run le rejoue ensuite sans appel à un modèle ; une étape en échec produit un code de sortie non nul et une capture de l’appareil.

L’intérêt pour une équipe mobile est de conserver la reproduction d’un bug comme test de non-régression. Le tutoriel recommande des identifiants stables, avec testID en React Native, pour retrouver les éléments malgré un changement de texte ou de traduction. Une attente sur l’écran atteint et une assertion sur le résultat donnent au parcours une vérification explicite, au-delà de la seule succession des taps.

L’état de départ mérite autant d’attention : launch redémarre l’application mais conserve ses données, ses comptes et l’état du backend. Un scénario qui crée un élément doit préparer ou réinitialiser ses données pour pouvoir être rejoué. Le tutoriel prévoit cette préparation par script et une exécution distincte pour chaque appareil ou plateforme à couvrir.

Sur l’infrastructure, EAS CLI 27.4.0 (nouvelle fenêtre) ajoute notamment eas/start_warm_agent_device_session et eas/start_warm_argent_remote_session. Ces étapes réutilisent un simulateur iOS déjà démarré lorsqu’il est disponible, avec un démarrage à froid en repli. Cela permet de réutiliser le simulateur entre les sessions ; la préparation des données du test reste à définir dans le scénario.