Shopify en natif, expo-ai et Simlock pour les équipes mobiles

Le choix d’une stack mobile engage aussi la manière de livrer, les capacités disponibles sur les appareils et les moyens de vérifier les changements. Le retour de Shopify au natif, l’arrivée d’expo-ai et l’ouverture de Simlock donnent trois occasions de réexaminer ces contraintes dans une équipe React Native.

Shopify revient au natif : comparer les conditions de livraison

Mustafa Ali annonce le 30 octobre la nouvelle application Shopify pour les marchands (nouvelle fenêtre), reconstruite en natif sur iOS et Android. Elle apporte un nouveau design, Liquid Glass sur iOS et un démarrage plus rapide sur les deux plateformes. Selon l’annonce, le temps de lancement Android est divisé par plus de deux ; une réponse précise que la migration a pris douze semaines (nouvelle fenêtre).

Le billet de Shopify sur son retour à Swift et Kotlin (nouvelle fenêtre) situe ce choix : les agents ont réduit, pour ses équipes, le coût de développement et de maintien de la parité entre plateformes. Shopify organise la reconstruction autour de petites étapes, avec tests, revue visuelle et validation humaine. Cette organisation fait donc partie du retour d’expérience à examiner.

Un détail change la comparaison pour une équipe Expo : Shopify précise n’avoir jamais utilisé les mises à jour OTA avec React Native (nouvelle fenêtre). L’entreprise livre une ou plusieurs mises à jour par semaine et pilote les fonctionnalités avec des flags côté serveur.

Avant de transposer cette décision, une équipe peut donc examiner sa propre cadence de livraison, son usage d’EAS Update et sa capacité à entretenir deux implémentations. Les gains annoncés donnent un retour d’expérience à étudier, dont la portée reste celle de la reconstruction et des moyens de Shopify.

expo-ai : essayer les modèles du système sur un parcours limité

Le module expérimental expo-ai (nouvelle fenêtre) donne accès aux modèles de langage fournis par le système : Apple Foundation Models sur iOS et Gemini Nano via l’API Prompt de ML Kit sur Android. Le README du package (nouvelle fenêtre) décrit la génération de texte, le résumé, la catégorisation, les résultats structurés et les outils applicatifs. Les résultats structurés sont validés ; les contraintes de schéma natives sont utilisées lorsqu’elles sont disponibles.

Pour une application métier, un premier essai pourrait proposer une catégorie à partir d’une description saisie sur le terrain. L’inférence locale ouvre la possibilité de traiter ce texte sans appel à un service tiers. Le prototype doit aussi prévoir le cas où le modèle système est indisponible, afin que l’utilisateur puisse terminer sa saisie.

L’intégration exige un development build : le module est absent d’Expo Go. Sur Android, la disponibilité dépend de l’appareil et d’AICore ; une tâche est rejetée avec ERR_APP_BACKGROUND lorsque l’application passe en arrière-plan. Cela donne un test concret : démarrer une catégorisation, quitter l’app, puis revenir et vérifier que le formulaire reste utilisable.

Le statut expérimental invite à isoler cet essai dans une fonction facultative. Comparer les catégories proposées aux corrections de l’utilisateur aidera à décider si le modèle apporte assez de valeur pour élargir son rôle.

Simlock : attribuer un appareil à chaque agent de test

Callstack rend Simlock open source (nouvelle fenêtre). L’outil réserve à chaque agent un simulateur iOS, un émulateur Android ou un téléphone enregistré, démarré et vérifié. La réservation reste exclusive jusqu’à sa libération. Quand aucun appareil n’est libre, Simlock peut en créer ; lorsque la machine atteint sa capacité, les demandes sont mises en file. Il nettoie aussi les appareils inutilisés.

La documentation de Simlock (nouvelle fenêtre) permet de commencer sur un Mac, puis de réunir plusieurs machines Mac ou Linux derrière une gateway. Cette progression répond à un problème très concret des vérifications mobiles en parallèle : deux agents qui naviguent sur le même simulateur peuvent modifier l’écran ou l’état de l’application pendant le parcours de l’autre.

Pour une équipe qui fait vérifier ses PR sur appareil, un premier scénario consiste à lancer deux parcours simultanés et à suivre leurs réservations jusqu’à leur libération. Chaque rapport devrait permettre de retrouver l’appareil utilisé et le résultat attendu. L’exclusivité de l’appareil fournit une base pour exécuter ces parcours ; les assertions et les preuves conservées restent nécessaires pour juger le changement testé.