Expo Modules 2.0 et Discord : écrire moins de glue, vérifier les contrats

Cette journée réunit une évolution d’API native et un retour d’expérience de migration. Leur point commun est de rendre explicites les contrats entre JavaScript, code natif et interface : une abstraction plus simple n’efface pas les cas de cycle de vie.

Expo Modules 2.0 : partir du code natif

L’aperçu Expo Modules 2.0 (nouvelle fenêtre) remplace la description dans un DSL par des classes Swift ou Kotlin annotées. Lors de cet aperçu, les macros iOS sont expérimentales dans SDK 57 ; Android est encore en cours et une beta documentée est prévue dans SDK 58. Les vues ne sont pas couvertes par la première expérimentation.

Pour une bibliothèque existante, un bon premier port est une fonction isolée avec types d’entrée et de sortie connus. Vérifier aussi erreurs, objets partagés et destruction du module. Réduire la quantité de glue est utile, mais il reste nécessaire de savoir quel thread exécute le travail et combien de temps vivent les ressources.

Discord : le travail continue après le changement de moteur

Le retour Software Mansion sur Discord iOS (nouvelle fenêtre) décrit presque une année de travail avec les équipes de l’app. Il insiste sur la longue traîne après activation de la New Architecture : hypothèses de coordonnées, gestes et interactions entre bibliothèques et Fabric.

Cela invite à choisir des parcours qui exposent les frontières. Un menu placé dans une modale peut utiliser une origine de coordonnées différente ; un geste commencé avant un changement d’arbre doit encore pouvoir se terminer. Une capture de l’écran immobile ne détecte pas ces problèmes.

Relier un symptôme à la bonne release

L’intégration PostHog d’Expo (nouvelle fenêtre) associe les événements à des propriétés EAS telles que l’identifiant d’update, le canal et le runtime. Elle aide à passer d’une hausse d’erreurs à la version concernée.

Pour en tirer parti, définir les événements avant le rollout : début d’un parcours, étape importante et résultat. Éviter de changer en même temps le sens de ces événements et l’implémentation du parcours. Sinon une variation de métrique pourrait provenir de l’instrumentation elle-même.

Un ordre d’adoption raisonnable

Commencer par l’observation et les reproductions, porter ensuite un module limité, puis élargir après validation. Les gains de microbenchmarks de fonctions natives ne prédisent pas seuls la fluidité d’une application complète. Le critère reste le parcours : comportement identique, erreurs compréhensibles et performance mesurée au bon endroit.