Hermes

Pour vérifier le moteur réellement utilisé, !!global.HermesInternal dans la console suffit, et HermesInternal.getRuntimeProperties() donne la version exacte. Le piège documenté par l’équipe React Native : si le bundle est chargé d’une façon non standard (un bundle téléchargé par un système d’update maison, par exemple), HermesInternal peut être présent alors que l’app charge du JavaScript brut et non du bytecode .hbc. Dans ce cas, le gain de démarrage disparaît sans aucun message d’erreur. Avec EAS Update, le bundle publié est bien compilé en bytecode pour la version d’Hermes du build.

Hermes ne se compare qu’en release. Un build debug garde les sources et les outils de debug, et toute mesure de démarrage faite dessus est fausse. npx expo run:ios --configuration Release ou yarn android --mode release donnent le vrai chiffre. Côté langage, Hermes suit son propre rythme d’implémentation d’ECMAScript ; un polyfill Intl ou une API récente peut manquer, d’où l’intérêt de tester les formats de dates et de nombres sur device plutôt que dans Node.

Pour Hermes V1, le passage est automatique à partir de la 0.84 (Expo SDK 56 et suivants). Revenir à l’ancien Hermes se fait en forçant hermes-compiler à 0.15.0 dans package.json (overrides ou resolutions), avec hermesV1Enabled=false côté Android et RCT_HERMES_V1_ENABLED=0 au pod install, ce qui oblige à recompiler React Native depuis les sources. Il faut une raison précise pour le faire.