Expo Modules API

Un module Expo se crée avec npx create-expo-module, ou en local dans le projet avec npx create-expo-module --local qui le place dans modules/. Il est décrit par un fichier expo-module.config.json à sa racine, qui liste les plateformes et les classes de module ; c’est ce fichier que l’autolinking d’Expo lit, indépendamment de l’autolinking de la CLI React Native. Le code iOS est en Swift (sous-classe de Module avec un bloc definition), le code Android en Kotlin, et le JavaScript charge le module avec requireNativeModule.

Le choix entre Expo Modules, Turbo Modules et Nitro se résume à ce que vous écrivez : du C++ partagé, choisissez Turbo Modules ; des appels très fréquents sensibles à la latence (traitement de frames, lecture synchrone intensive), Nitro ; un accès natif ordinaire avec peu de boilerplate, l’Expo Modules API. La doc Expo indique des performances comparables aux Turbo Modules, les deux passant par JSI, et les microbenchmarks Android publiés avec le SDK 58 placent même Expo Modules 2.0 devant un Turbo Module dans les douze cas mesurés. Le prix d’entrée est une dépendance au package expo, et quelques centaines de kilo-octets dans le binaire.

Expo Modules 2.0, en bêta sur iOS et Android dans le SDK 58 après une phase expérimentale des macros iOS au SDK 57, remplace le DSL par des annotations sur une classe Swift ou Kotlin ordinaire. Expo annonce des appels synchrones 2,5 à 5,6 fois plus rapides que le DSL sur iOS. Le contrat JavaScript ne change pas, ce qui permet de migrer module par module.