Planification de la mise à niveau Expo SDK 58 : iOS 27, React Native 0.88 et nouveaux outils
Une présentation pratique de l’Expo SDK 58 beta : quels changements pour iOS 27 et React Native 0.88, quelles fonctionnalités sont expérimentales, et comment tester la mise à niveau en toute sécurité.
Sources: Expo SDK 58 Beta: What React Native Developers Actually Need to Know
Expo SDK 58 ne se distingue pas par une fonctionnalité majeure en particulier. Au contraire, de nombreuses modifications sont introduites d’un seul coup : prise en charge d’iOS 27, React Native 0.88, compilations Android plus rapides, appels aux modules natifs moins coûteux, widgets pour l’écran d’accueil Android, intégration de Siri via App Intents, une interface en ligne de commande destinée à la programmation d’agents, un Expo Router plus mature, ainsi qu’un transformateur expérimental basé sur Rust pour Metro. Ce guide classe ces modifications en fonction de leur impact pratique, afin que vous puissiez savoir quelles modifications affecteront votre codebase, lesquelles sont offertes gratuitement, celles qui restent expérimentales, et comment effectuer la mise à niveau sans endommager une application en production.
Tenez SDK 58 pour une version bêta, car c’en est bien une
Au moment de la rédaction, SDK 58 est en phase bêta, et Expo prévoit que cette étape durera environ trois à quatre semaines. Vérifiez le journal des modifications d’Expo pour connaître l’état actuel avant de planifier quoi que ce soit en fonction d’une date de sortie.
Une période bêta constitue la fenêtre idéale pour les tests : votre code d’application, les bibliothèques tierces, les modules natifs personnalisés, le pipeline de compilation ainsi que tout code natif écrit manuellement. Ce n’est pas le moment opportun pour mettre à jour l’SDK d’une application en production juste avant un week-end. Cependant, pour les projets secondaires et les outils internes, la version bêta représente un moyen à faible risque de découvrir ce qui va arriver et d’identifier les problèmes tôt, tant qu’il reste encore du temps pour les corriger au niveau source.
iOS 27 et le cycle de vie basé sur les scènes
Une grande partie de la motivation derrière l’SDK 58 réside dans iOS 27. Les applications compilées avec l’SDK iOS 27 utilisent le cycle de vie basé sur les scènes d’Apple, et Expo a réorganisé son infrastructure native autour de ce modèle.
Quelques informations de contexte sont utiles ici. Dans le modèle ancien, UIApplicationDelegate gérait toute l’application : une seule fenêtre, un seul ensemble de callbacks de démarrage et en premier plan. Le modèle de scène divise ces responsabilités, de sorte que chaque instance d’UI (une scène) dispose de son propre cycle de vie, géré par un délégué de scène. Les tâches qui relevaient auparavant du délégué de l’application, comme réagir au fait que l’application devienne active ou gérer les URLs reçues, peuvent être transférées aux callbacks au niveau de la scène.
Dans un projet Expo typique, cette transition doit rester invisible. Cela devient important lorsque l’on a personnalisé la partie native. Un exemple courant est des configurations supplémentaires dans le callback de démarrage du délégué de l’application, comme la méthode Swift ci-dessous (affichée ici sans mise en évidence syntaxique) :
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions:
[UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
// Custom initialization
return true
}
Si votre AppDelegate.swift contient une logique personnalisée importante, une partie de celle-ci pourrait désormais relever du traitement des scènes plutôt que d’une seule fenêtre d’application globale. Expo recommande de consulter ses directives sur la migration du cycle de vie des scènes si vous modifiez le délégué de l’application native.
Quels projets nécessitent une attention particulière
De nombreuses applications Expo n’ouvrent jamais AppDelegate.swift, et pour elles la migration devrait se faire sans problème. Cependant, les applications plus volumineuses ont tendance à accumuler du code natif au fil des années, et c’est là que réside le risque. Examinez attentivement votre projet iOS s’il dispose d’une configuration native pour l’un des éléments suivants :
- initialisation des SDK d’analyse
- Gestion des liens profonds et universels
- SDK d’authentification
- Notifications push
- SDK de paiement natifs
Chacun d’eux se connecte généralement à des appels de retour lors du lancement ou via une URL, qui sont précisément les appels de retour affectés par le modèle de scène. Testez ces flux explicitement plutôt que d’imaginer qu’une compilation réussie signifie une application fonctionnelle.
React Native 0.88 et l’API stricte de TypeScript
La version bêta du SDK 58 est incluse dans la candidate de sortie React Native 0.88. Mettre à jour Expo signifie donc intégrer tous les changements apportés tant dans React Native 0.87 que 0.88, et non seulement dans une seule version.
Le changement que vous rencontrerez probablement en premier est la API stricte de TypeScript, qui restreint ce qui est considéré comme une API publique de React Native. Les importations vers des fichiers internes en sont les principales victimes :
import Something from 'react-native/Libraries/...';
Les applications et les bibliothèques utilisent ce type d’importations profondes depuis des années, généralement parce que le point d’accès public ne fournissait pas ce dont elles avaient besoin. Cela fonctionnait toujours par hasard : les chemins de fichiers internes peuvent changer ou être modifiés à chaque nouvelle version sans préavis. React Native établit désormais une distinction claire entre les modules publics et privés, et un codebase rempli d’importations profondes devrait considérer la version 58 du SDK comme un signal pour les nettoyer. Lorsqu’une bibliothèque de votre arbre de dépendances utilise ce type d’importations, vérifiez s’une version plus récente ne l’a pas déjà corrigé.
API supprimées telles que InteractionManager
Certaines anciennes API ont également disparu, et InteractionManager en fait partie. Le code qui reporte des tâches lourdes jusqu’à ce que les animations et interactions soient terminées ressemble souvent à ceci :
InteractionManager.runAfterInteractions(() => {
loadHeavyContent();
});
Le remplacement recommandé est l’API standard de callback d’inactivité :
requestIdleCallback(() => {
loadHeavyContent();
});
Les sémantiques sont similaires mais pas identiques. InteractionManager attend que les interactions enregistrées soient terminées, tandis que requestIdleCallback exécute le callback lorsque le thread JavaScript est inactif. Pour la plupart des cas où il s’agit de « charger cela après l’apparition de l’écran », la différence est insignifiante, mais si vous comptez sur lui pour attendre une animation spécifique, vérifiez son comportement sur un appareil réel.
Dans une petite application, cette migration est généralement rapide. Dans une application plus ancienne avec de nombreuses dépendances, effectuez la mise à niveau sur une branche dédiée et laissez le compilateur TypeScript lister tous les problèmes avant d’intervenir ailleurs. Les erreurs du compilateur deviennent alors votre liste de contrôle pour la migration.
Constructions Android plus rapides
expo-modules-core inclut désormais des bibliothèques natives précompilées pour Android. Auparavant, une compilation propre d’Android consacrait une part importante de son temps à la compilation du code C++ sur lequel reposent les modules Expo. SDK 58 élimine la plupart de cette étape.
D’après les mesures d’Expo, en utilisant une application SDK 58 vide sur un ordinateur Apple M3 Pro, le temps de compilation en mode débogage pour Android est passé d’environ 80 secondes à environ 39 secondes. Vos résultats varieront en fonction de la taille du projet et du matériel, mais l’économie provient du fait que cette étape est complètement supprimée, ce qui devrait se refléter dans tout projet utilisant des modules Expo.
Les avantages se multiplient dans l’environnement CI. Une équipe qui ouvre vingt demandes de pull par jour, chacune déclenchant des compilations Android, paie ce coût de compilation à chaque exécution, et les machines CI partent souvent d’un cache vierge. Économiser une demi-minute une seule fois n’est pas significatif. Mais l’économie réalisée à chaque compilation locale, à chaque job CI, sur chaque branche fonctionnelle et lors de chaque build de version représente un gain réel en temps et en coûts de calcul. La vitesse de compilation est également une forme de performance, seulement mesurée en minutes de développement plutôt qu’en taux de rafraîchissement.
Appels moins coûteux entre JavaScript et code natif
Les améliorations de performance dans le SDK 58 ne se limitent pas aux compilations. Expo a également réduit le coût des appels vers les modules natifs, avec la plupart des gains sur iOS. Le transfert de longues chaînes de caractères est considérablement plus rapide, et les promesses retournées par les fonctions natives asynchrones génèrent moins de surcharge.
Vous n’avez pas besoin de modifier quoi que ce soit pour en bénéficier : les modules Expo existants intègrent ces améliorations dès que vous effectuez une mise à niveau.
Cela est particulièrement important pour les applications qui franchissent fréquemment la frontière entre JavaScript et le code natif. Prenons par exemple une telle appel :
const result = await SomeNativeModule.processLargePayload(data);
La fonction native peut effectuer son travail rapidement, mais chaque invocation nécessite néanmoins de convertir les arguments en types natifs puis de les transformer à nouveau en valeurs JavaScript. Si une application effectue de telles appels des milliers de fois, par exemple lors du traitement d’un flux de données provenant de capteurs ou de la synchronisation de gros ensembles de données, réduire légèrement ce temps à chaque passage produit une différence mesurable.
Expo Modules 2.0 : des classes natives au lieu d’un DSL
Pour les équipes qui développent leurs propres modules natifs, Expo Modules 2.0 représente l’un des changements les plus significatifs. Au moment de la rédaction de ce texte, il est en version bêta tant sur iOS que sur Android.
L’API actuelle des Expo Modules décrit un module à l’aide d’un DSL : un bloc de définition où vous declarez des fonctions, des propriétés et des événements. Expo Modules 2.0 adopte une approche plus conventionnelle. Vous écrivez une classe ordinaire en Swift ou Kotlin et vous annotez les membres qui doivent être exposés à JavaScript.
L’avantage pratique est que votre code natif reste conforme au style propre à ce langage. Le Swift conserve son apparence typique et le Kotlin la sienne, sans nécessiter d’apprendre d’abord une couche spécifique au framework. Cela réduit les obstacles pour les développeurs qui connaissent la plateforme mais pas Expo, et cela est également utile aux outils de codage par IA, car leurs données d’entraînement contiennent bien plus de code Swift et Kotlin classique que de code DSL Expo.
Il y a aussi l’aspect des performances. Les liaisons peuvent être générées au moment de la compilation plutôt que d’être résolues dynamiquement en temps de exécution, et les benchmarks d’Expo montrent d’importantes améliorations dans plusieurs microbenchmarks. Les microbenchmarks isolent une seule opération, ce qui les rend rarement directement transposables en accélérations au niveau de l’application ; ils ne constituent donc pas à eux seuls une raison de redessiner votre architecture native. Si vous souhaitez en savoir davantage sur les raisons pour lesquelles les liaisons statiques sont plus rapides, la comparaison présentée dans Nitro Modules : comment les liaisons statiques surpassent React Native TurboModules aborde le même principe. Ce qui distingue Expo Modules 2.0, c’est qu’il rend les modules à la fois plus simples à écrire et plus rapides en même temps, ce qui constitue une combinaison rare.
Widgets d’écran d’accueil sur Android
expo-widgets prend désormais en charge Android, ce qui ouvre de nouvelles possibilités pour les produits destinés à divers types d’applications : suiveurs d’habitudes, outils financiers, applications de livraison, applications de fitness, gestionnaires de tâches et calendriers.
Monthly Budget
ainsi que un détail du montant restant par catégorie en dessous :
₹34,500 remainingFood ₹8,200
Travel ₹3,400
Shopping ₹5,100
Un gestionnaire de tâches pourrait afficher les trois tâches les plus importantes de la journée directement sur l’écran d’accueil.
Au sein d’Android, chaque widget exécute son propre paquet JavaScript sur un environnement de exécution Hermes dédié, prend en charge les interactions utilisateur et peut utiliser les couleurs Material pour s’intégrer au thème du système. Il est important de comprendre cet environnement de exécution distinct : le widget ne partage ni la mémoire ni l’état avec l’application en cours d’exécution, il faut donc lui transmettre les données explicitement plutôt que de les lire depuis le stockage interne de l’application. Pour les équipes multi-plateformes, disposer de widgets sur les deux plateformes au sein de l’écosystème Expo élimine encore une raison de maintenir des implémentations natives séparées.
App Intents : Siri, Shortcuts et Spotlight
expo-app-intents relie les applications Expo au système App Intents d’Apple, qui est le mécanisme à l’origine de plusieurs interfaces système :
- Siri
- Shortcuts
- Spotlight
- Apple Intelligence
Imaginez un gestionnaire de tâches. Normalement, pour terminer une tâche, il faut ouvrir l’application, trouver l’élément correspondant et y cliquer. Avec une intention exposée, l’utilisateur peut simplement demander à Siri :
"Terminer l’envoi des documents ID."
Siri traite la tâche correspondante et exécute l’action déclarée par votre application. Votre code JavaScript reçoit cette invocation et met à jour les données de l’application. Dans l’exemple d’Expo, cela se produit sans que l’application ne passe en premier plan.
L’implication plus large est un changement dans la structure des applications mobiles. L’icône de l’application n’est plus le seul point d’accès. Certaines actions partent de Siri, d’autres d’un widget, d’autres encore de la recherche Spotlight ou des automatisations Shortcuts de l’utilisateur. L’application devient un ensemble de fonctionnalités que le système d’exploitation peut exposer là où elles sont utiles, ce qui mérite d’être pris en compte lors de la conception des fonctionnalités.
Un point important à noter : expo-app-intents est encore en version alpha au moment de la rédaction. Expérimentez-le, mais n’implémentez pas encore de flux de travail critique pour l’entreprise dessus.
Expo UI se rapproche de SwiftUI et Jetpack Compose
Expo UI continue d’approfondir son intégration avec SwiftUI et Jetpack Compose. Le SDK 58 ajoute des primitives de navigation SwiftUI pour iOS :
NavigationStack
NavigationLink
NavigationDestination
Toolbar
Ces éléments correspondent aux propres blocs de construction de navigation de SwiftUI, ce qui vous permet d’utiliser une navigation par pile et des barres d’outils natives plutôt qu’une reconstitution en JavaScript. Cette version ajoute également davantage de composants Jetpack Compose et améliore les composants universels existants qui fonctionnent sur toutes les plateformes.
Une amélioration plus modeste est pourtant très utile : chaque composant de la documentation Expo UI dispose désormais d’un exemple visuel. Sans captures d’écran, choisir un composant UI entraîne souvent un cycle frustrant :
- Trouver un composant dont le son vous convient.
- Lire ses propriétés.
- Le connecter à une interface utilisateur.
- Lancer l’application.
- Découvrir qu’elle ne ressemble pas du tout à ce que vous aviez imaginé.
- Recommencer avec un composant différent.
Voir le composant affiché à côté de son API met fin à ce cycle.
Device Hub et contrôle via un simulateur basé sur le navigateur
Xcode 27 remplace Simulator.app par Device Hub, et Expo CLI prend en charge ce nouveau flux de travail. Expo expérimente également un package distinct, expo-device-hub, qui fournit un tableau de bord local dans le navigateur pour vos simulateurs et émulateurs.
Dans ce tableau de bord, vous pouvez visualiser :
- un miroir en temps réel de l’écran du dispositif
- la consommation de CPU et de mémoire
- le trafic réseau
- les options d’apparence telles que le mode clair et sombre
- les options d’accessibilité
Vous pouvez également taper, faire glisser et écrire sur le dispositif depuis le navigateur. Pour essayer, installez le paquet et lancez le serveur de développement :
npx expo install expo-device-hub
npx expo start
Si votre journée consiste à alterner constamment entre un éditeur, une terminal, l’émulateur Android, le simulateur iOS et des outils de profilage distincts, regrouper une partie de ces fonctionnalités dans une seule fenêtre du navigateur peut considérablement fluidifier le cycle de développement.
Expo travaille également sur le EAS Simulator, qui vise à offrir une expérience similaire grâce à des simulateurs hébergés dans le cloud, de sorte que vous n’aurez pas besoin d’avoir Xcode ou Android Studio installés localement.
Une CLI conçue pour les agents de codage
Cette nouvelle fonctionnalité montre clairement où se dirige l’évolution des outils de développement. Expo a publié un paquet expérimental :
@expo/agent-cli
Les agents de codage ont du mal à décider quel outil utiliser parmi plusieurs : Expo CLI, EAS CLI, expo-doctor, etc., chacun ayant ses propres paramètres et format de sortie. L’agent CLI regroupe tous ces outils derrière une interface cohérente. Sa configuration pour votre projet se fait comme suit :
npx @expo/agent-cli@latest agents:setup
Quelques-uns de ses commandes illustrent ce principe. La première est :
status
Il vérifie des éléments tels que la compatibilité avec Expo Go sans lancer l’application. La suivante est :
dev
Il lance l’environnement de développement et cherche le chemin le plus rapide pour obtenir une application en cours d’exécution. La dernière est :
smoke
Il lance l’application, prend une capture d’écran et la ferme à nouveau.
Cette dernière commande est la plus intéressante pour les workflows automatisés. Supposons que vous demandiez à un agent d’ajouter une page de paramètres et de vérifier si l’application se lance toujours. Au lieu de supposer que la modification fonctionne, l’agent peut exécuter une vérification de base et examiner le résultat. C’est un petit pas vers des agents qui, en plus d’être des générateurs de code, peuvent vérifier eux-mêmes leur travail, ce qui constitue la majeure partie de leur valeur pratique. Le paquet est encore expérimental, il faut donc s’attendre à ce que ses commandes changent.
Expo Router stabilise plusieurs fonctionnalités
Expo Router bénéficie d’une mise à jour importante dans SDK 58. Plusieurs fonctionnalités qui étaient auparavant expérimentales sont désormais stables :
- les chargeurs de données, permettant de récupérer les informations relatives à une route avant que l’écran ne s’affiche
- le rendu du côté serveur pour les sorties web
- le middleware qui s’exécute avant qu’une requête n’atteigne une route
- les onglets natifs pris en charge par les barres d’onglets de la plateforme
- les barres d’outils
Au niveau technique, la navigation a également été réécrite afin que l’état de navigation soit plus déterministe, ce qui signifie que la même séquence d’actions produit de manière fiable le même état. La plupart des applications ne devraient pas remarquer de différence. Si vous avez créé vos propres navigateurs ou importé directement depuis le chemin suivant, lisez attentivement le guide de migration :
expo-router/react-navigation
Sur le web, les routes asynchrones sont désormais la norme. Chaque route peut être divisée en son propre chunk JavaScript et chargé lorsque l’utilisateur y accède, au lieu d’envoyer du code pour chaque écran lors du premier chargement de la page. Pour les applications web construites avec Expo Router, c’est un paramètre par défaut judicieux, car le temps de chargement initial est généralement ce que les utilisateurs remarquent le plus. Gardez à l’esprit qu cela signifie également qu’une route peut être chargée brièvement lors de la première visite, il convient donc d’examiner rapidement les états de chargement sur le web.
Un transformateur Rust expérimental pour Metro
Techniquement, il s’agit peut-être du changement le plus intéressant de cette version, bien qu’il soit explicitement expérimental. Expo teste un transformateur JavaScript écrit en Rust appelé Noxcturnal, basé sur l’outilchain oxc.
Une grande partie du temps nécessaire au bundling en mode froid de Metro est consacrée aux transformations Babel : analyse de chaque fichier, application de plugins et génération du résultat. En remplaçant cette étape par du code natif Rust, on cible directement la partie la plus coûteuse. Selon les tests d’Expo, les transformations de modules individuels étaient environ trois fois plus rapides, et les bundles complets en mode froid près de deux fois plus rapides. Une application de test importante comptant environ 5 500 fichiers est passée de 5,26 secondes à 2,46 secondes.
Vous pouvez l’activer en utilisant un paramètre d’expérimentation dans votre configuration :
experiments: {
noxcturnalTransformWorker: true
}
Connaître les limites avant de l’activer. Les projets qui dépendent de plugins Babel personnalisés, de préférences prédéfinies ou de transformations spécialisées peuvent encore recourir à Babel, donc l’amélioration des performances dépend du degré de standardisation de votre configuration. Comme cette fonctionnalité est expérimentale, son comportement et sa configuration peuvent changer d’une version à l’autre.
Cette orientation est cohérente avec l’écosystème plus large, où les outils JavaScript à fort impact sur les performances passent depuis plusieurs années de JavaScript à Rust. Expo explore désormais la même voie pour Metro.
Moins de recompilations natives inutiles
Le comportement par défaut en matière de génération d’empreintes dans SDK 58 est désormais la préférence prédéfinie balanced. L’empreinte correspond à un hash de tout ce qui influence la compilation native ; lorsqu’elle change, les outils d’Expo en déduisent qu’un nouveau binaire natif est nécessaire.
Cela semble peu intéressant jusqu’à ce qu’il vous épargne une recompilation native pour une modification qui n’affecte jamais le code natif. Selon la configuration, modifier quelque chose comme la version de l’application dans app.json modifiait autrefois l’empreinte digitale. Le réglage équilibré cherche à ignorer les changements qui n’affectent pas de manière significative l’environnement d’exécution natif. Le résultat au quotidien est simple : moins de recompilations déclenchées sans raison valable, ce qui signifie également moins de constructions binaires inutiles lorsque l’on se fie aux empreintes digitales pour choisir entre une mise à jour sans connexion et une nouvelle version depuis le magasin. Personne ne démontre ce type de fonctionnalité, mais tout le monde en bénéficie.
Améliorations mineures dignes d’être connues
En dehors des points majeurs, plusieurs mises à jour de modules peuvent être pertinentes en fonction de votre application :
expo-camerapermet le numérisation de documents sur plusieurs pages, utile pour les scanners de reçus, les flux de téléchargement de documents, la vérification d’identité (KYC) et la gestion des dépenses.expo-fontprend en charge les polices variables sur Android, iOS et le web.expo-audiointègre des contrôles d’écran verrouillé sensibles aux listes de lecture ainsi que la possibilité d’enregistrer en WAV/PCM.expo-file-systemajoute davantage d’API de hachage et un support natif pour la prévisualisation.expo-notificationsintroduit de nouveaux comportements, comme la livraison d’alertes horaires sur Android.- L’intégration avec PostHog permet d’associer des informations sur la version EAS ainsi que les mises à jour aux événements d’analyse.
Aucun de ces éléments ne définit à lui seul la version finale. Ensemble, ils montrent à quel point la couverture de la plateforme s’est élargie.
Changements importants à examiner avant la mise à niveau
Les mises à niveau sont excitantes jusqu’au moment où la création de l’application s’arrête, alors ne sautez pas cette étape. Avant de passer à un projet réel sur SDK 58, vérifiez ce qui suit.
Importations profondes dans React Native
Recherchez dans le codebase ce préfixe de chemin :
react-native/Libraries/
Chaque correspondance représente une importation de fichiers internes de React Native que l’API stricte de TypeScript pourrait rejeter. Vérifiez également node_modules, ou du moins examinez les dépendances qui échouent, car les bibliothèques en sont une source fréquente.
APIs de React Native supprimées
Vérifiez que ni votre application ni ses dépendances n’utilisent encore des APIs supprimées entre React Native 0.87 et 0.88, comme InteractionManager.
Codage personnalisé pour AppDelegate
Si le projet iOS contient des personnalisations du cycle de vie natif, examinez-les par rapport au cycle de vie basé sur la scène requis par iOS 27.
Navigation personnalisée dans Expo Router
Les navigateurs personnalisés ainsi que les imports provenant de expo-router/react-navigation sont affectés par les modifications apportées aux mécanismes internes ; suivez le guide de migration.
Écritures dans le système de fichiers
File.write() est désormais asynchrone. Le code qui suppose que le fichier existe déjà échouera à moins d’attendre la fin de l’appel. Si vous avez vraiment besoin d’un comportement synchrone, passez à :
File.writeSync()
Version de Node.js
Les versions de Node.js prises en charge par Expo ont évolué. Vérifiez votre environnement local ainsi que vos images CI avant de supposer qu’un échec de compilation est dû à une erreur d’Expo.
Une manière sûre de tester la mise à niveau
N’entamez pas la mise à niveau depuis la branche principale de production. Créez une branche dédiée à la migration et effectuez-y la mise à niveau :
npx expo install expo@next --fix
La tag expo@next installe la version bêta, et l’option --fix met à jour vos autres paquets Expo pour qu’ils soient compatibles avec elle.
Testez d’abord les flux les moins spectaculaires, car ce sont ceux que les utilisateurs remarquent en cas de panne :
- L’application démarre-t-elle du tout ?
- Le connexion et l’authentification fonctionnent-ils ?
- Les utilisateurs peuvent-ils naviguer entre les écrans principaux ?
- Les liens profonds ouvrent-ils bien la bonne page ?
- Les notifications push arrivent-elles correctement ?
- Les utilisateurs peuvent-ils téléverser des images et des fichiers ?
- Les paiements se terminent-ils avec succès ?
- La version Android fonctionne-t-elle correctement ?
- La version iOS fonctionne-t-elle correctement ?
Ce n’est qu’une fois ces éléments validés que cela vaut la peine d’explorer les nouvelles fonctionnalités. Les nouvelles API sont amusantes à tester ; c’est le test de régression qui permet de garder vos utilisateurs satisfaits.
La direction d’Expo
En examinant l’ensemble du SDK 58, c’est la direction générale qui importe plus que n’importe quelle fonctionnalité individuelle. Expo a débuté comme un moyen de rendre React Native plus facile à utiliser, et il devient progressivement une plateforme d’application complète :
- Expo Router pour la structure et la navigation des applications
- Expo Modules pour les API natives
- EAS Build pour la compilation des applications
- EAS Update pour la diffusion des mises à jour
- EAS Observe pour le suivi en production
- Expo UI pour les composants d’interface natives
- Widgets et App Intents pour l’intégration avec les systèmes d’exploitation
- Outils agent pour un développement assisté par l’IA
En plus de cela, Expo continue d’investir dans les infrastructures dont les développeurs profitent au quotidien : des compilations plus rapides, des appels aux fonctionnalités natives moins coûteux, moins de recompilations, de meilleurs tunnels de connexion, des outils de simulation améliorés et éventuellement un empaquetage plus rapide. Rien de tout cela ne produit des captures d’écran impressionnantes, mais cela améliore le travail quotidien. Pour en savoir plus sur la position d’Expo, consultez pourquoi le retrait de Shopify de React Native ne menace pas Expo.
Faut-il mettre à jour maintenant ?
Pour une application en production, testez avant de valider les changements. Le SDK 58 est encore en version bêta, React Native 0.88 est proposé en tant que candidat à la version finale, plusieurs des nouvelles API sont expérimentales ou en version alpha, et davantage de correctifs sont attendus avant la sortie stable.
Pour un projet secondaire, une outil interne ou une branche de migration, il vaut vraiment la peine d’en explorer les fonctionnalités maintenant, surtout si vous avez besoin de la compatibilité avec iOS 27 ou souhaitez être à l’avant-garde des modifications de React Native. Les problèmes que vous découvrirez pendant la phase bêta pourront toujours être signalés et corrigés avant la version stable, ce qui est bien plus facile que de les trouver après que tout le monde ait mis à jour son système.
L’unique commande à retenir est celle que vous utilisez pour commencer :
npx expo install expo@next --fix
Exécutez-la sur une branche, et non en production.
Points clés
- Les changements les plus susceptibles de perturber une mise à niveau sont les imports profonds, les API supprimées comme
InteractionManager, le code personnalisé de ainsi que les navigateurs personnalisés d’Expo Router. - Des compilations Android plus rapides, des appels natifs moins coûteux et moins de recompilations déclenchées par l’analyse des empreintes digitales font partie intégrante de la mise à niveau.
- Expo Modules 2.0, l’agent CLI, Device Hub et le transformateur Noxcturnal sont en version expérimentale ou bêta ; évaluez-les, mais ne comptez pas encore sur eux.
expo-app-intentsest en version alpha, tandis que les widgets Android rendent possibles des fonctionnalités d’écran d’accueil pour les équipes multiplateformes.- Mettez à niveau sur une branche dédiée, testez d’abord les flux utilisateurs critiques, et n’expérimentez de nouvelles fonctionnalités qu’une fois ceux-ci validés.