Aller au contenu
useffect.sh
Planifier 30 min avec un senior
Build et publication

Runtime version

L’identifiant qui garantit qu’une update OTA n’est appliquée qu’aux builds dont le code natif est compatible avec elle.

Définition

La runtime version est une propriété d’un build et d’une update qui garantit leur compatibilité : une update EAS n’est livrée qu’aux builds dont la runtime version correspond exactement à la sienne. Elle décrit l’interface entre le JavaScript et la couche native ; dès qu’un changement natif modifie cette interface (nouveau module, mise à jour du SDK, permission ajoutée), la runtime version doit changer, et donc un nouveau build être publié avant toute update. Elle se configure dans app.json sous runtimeVersion, soit comme chaîne manuelle ("1.0.0"), soit par une politique : appVersion reprend le champ version, nativeVersion combine version et numéro de build natif (1.0.0(1)), et fingerprint calcule un hash du projet natif avec @expo/fingerprint à chaque build et chaque update. C’est le mécanisme qui remplace la discipline manuelle que CodePush exigeait. Une update publiée qui n’arrive jamais sur les téléphones vient presque toujours d’un écart de runtime version.

Dans une vraie app

Le choix de la politique est une décision d’équipe. appVersion est simple mais repose sur la discipline d’incrémenter version à chaque release avec du natif ; un bump oublié et une update casse des builds en production. fingerprint retire ce risque en hashant ce qui touche au natif (dossiers natifs, config, dépendances natives) ; depuis le SDK 58, le preset par défaut balanced ignore les bumps de version et hashe les modules natifs par nom et version, ce qui limite les rebuilds inutiles. Il produit tout de même plus de runtime versions qu’une politique manuelle, donc plus de builds à maintenir en parallèle. Une chaîne manuelle convient aux projets qui suivent déjà un process de release strict.

Pour vérifier ce qu’une build embarque, eas build:list affiche la runtime version de chaque build, et eas update:list celle de chaque update ; les deux doivent coïncider pour la plateforme concernée. eas fingerprint:compare explique pourquoi deux fingerprints diffèrent, ce qui évite les « mais je n’ai rien changé côté natif » quand une dépendance a mis à jour un podspec. L’API Updates.runtimeVersion donne la valeur au runtime, utile dans un écran de debug interne.

Le piège le plus coûteux : les projets qui gardent runtimeVersion figé sur "1.0.0" pendant des mois « pour que les updates passent partout ». Tôt ou tard une update référence un module natif que les anciens builds n’ont pas, et le crash touche précisément les utilisateurs qui ne mettent pas leur app à jour.

Sources

Les 35 termes du glossaire

Un de ces sujets bloque votre app ?

30 minutes avec un senior pour regarder le problème dans votre code. Gratuit.