SDK 58 beta : organiser les essais par chantier natif

La beta SDK 58 démarre le 15 septembre. Elle rassemble plusieurs évolutions qui n’ont ni le même impact ni le même statut. Pour une app existante, un essai utile commence par cette séparation.

Une beta qui embarque une candidate

L’annonce Expo (nouvelle fenêtre) prévoit trois à quatre semaines de beta et indique React Native 0.88 Release Candidate. La stable RN n’est donc pas encore publiée au moment de cette annonce. Expo Go SDK 58 suit aussi un canal de distribution spécifique pendant la beta, distinct des versions des stores.

Un package dont le numéro commence par 58 n’est pas une preuve suffisante de disponibilité générale. Conserver version exacte, canal et build permet de relire les résultats plus tard.

D’abord le démarrage iOS

SDK 58 adopte le cycle de vie scene-based (UIScene) exigé par iOS 27 : prebuild génère désormais un SceneDelegate. Une app qui personnalise AppDelegate doit examiner ses callbacks plutôt que considérer le changement comme une simple mise à jour JavaScript.

Un parcours de validation doit inclure lancement à froid, retour par URL et reprise de session. Les modules natifs qui supposent une fenêtre unique ou un état global au niveau de l’application sont des points à inventorier.

Séparer les expérimentations

L’aperçu comprend Expo Modules 2.0, un transformer Rust expérimental et des évolutions d’outillage. Ils ne doivent pas tous être activés pour vérifier que l’app supporte le nouveau SDK.

Une séquence lisible consiste à compiler d’abord avec la configuration la plus proche de l’existant, exercer les parcours importants, puis introduire une expérimentation à la fois. Le résultat doit permettre de revenir précisément au changement responsable d’un problème.

Vérifier aussi la machine de build

La note de beta précise les versions Node supportées et la transition des images Xcode. Une réussite locale peut masquer une CI encore sur une autre toolchain.

Avant un rollout, garder une compilation release représentative sur chaque plateforme. Le test de la beta gagne en valeur lorsqu’il produit une reproduction minimale, un identifiant de build et la liste des comportements attendus. Les listes quotidiennes de dist-tags sont un complément de veille ; elles ne remplacent pas ce dossier de compatibilité.