iOS 27, Xcode 27 et le changement cassant de @State

WWDC 2026 est derrière nous, les bêtas d'iOS 27 et d'Xcode 27 sont disponibles, et la plupart des articles se sont concentrés sur Liquid Glass et son curseur de teinte, ou sur Siri devenant plus intelligent. C'est l'histoire côté utilisateur. L'histoire côté développeur est plus précise, et elle commence par trois caractères que vous tapez dans presque chaque vue SwiftUI : @State.

À partir d'Xcode 27, @State n'est plus un property wrapper conforme à DynamicProperty. C'est désormais une macro Swift. Apple a rendu ce nouveau comportement disponible dès iOS 17, macOS 14, tvOS 17, watchOS 10 et visionOS 1 — vous n'avez donc pas besoin de relever votre cible de déploiement pour en bénéficier. Compilez le même code avec Xcode 26 et SwiftUI utilise toujours l'ancien property wrapper. L'avantage pratique : les classes stockées dans @State s'initialisent désormais de façon lazy, une seule fois par durée de vie de la vue, au lieu d'être allouées à chaque réinitialisation de vue.

C'est la bonne nouvelle. Le problème, c'est qu'un pattern courant cesse de compiler. Si vous définissez une valeur par défaut dans la déclaration puis en assignez une autre dans init, Xcode 27 vous bloque avec une erreur dure :

struct ProfileView: View {
    @State private var name = "Guest"   // valeur par défaut ici
    init(user: User) {
        name = user.displayName          // réassigné ici -> erreur dans Xcode 27
    }
}

Avant, cela utilisait silencieusement la mauvaise valeur. Maintenant, c'est une erreur « variable used before being initialized ». Triviale dans une seule vue, mais c'est exactement le genre de chose qui se cache dans des dizaines de vues d'une application mature.

Le calcul des délais joue en votre faveur

Voilà où les équipes se trompent. Elles paniquent ou ignorent le problème, et ni l'une ni l'autre n'est la bonne réaction.

Le plancher de soumission d'Apple n'a pas bougé. Depuis le 28 avril 2026, l'App Store Connect exige uniquement que vous compiliez avec Xcode 26 et le SDK iOS 26. Aucune date limite annoncée ne vous oblige à utiliser le SDK iOS 27, donc vous n'êtes pas contraint de livrer avec iOS 27 dans l'urgence.

Mais « pas de date limite » ne signifie pas « pas de travail ». L'erreur @State est un échec de compilation, et les échecs de compilation coûtent le moins cher à corriger quand vous les cherchez délibérément, pas quand un train de publication de septembre est déjà en marche. Dans nos projets iOS natifs et Android, nous avons réappris la même leçon plus d'une fois : la migration que vous planifiez est sereine, celle qui tombe en plein lancement est le chaos.

Ce que vous pouvez faire aujourd'hui : ajoutez une lane Xcode 27 bêta à votre CI et laissez-la compiler avec la nouvelle chaîne d'outils maintenant. Vous n'avez pas à livrer ce qu'elle produit. Vous voulez juste que la croix rouge apparaisse dans une pull request en juillet plutôt que dans une branche de hotfix en automne. Pendant que vous y êtes, cherchez dans votre codebase les déclarations @State portant une valeur par défaut et réassignées dans un initialiseur. C'est votre liste de corrections, et elle est finie.

Les changements plus discrets qui méritent votre attention

@State fait la une, mais quelques autres mises à jour de SwiftUI changent la façon dont nous construirions les choses.

AsyncImage effectue désormais du cache HTTP par défaut. Il respecte les en-têtes de cache du serveur sans modification du code, donc faire défiler une liste deux fois ne re-télécharge plus les mêmes images. Nous développons des applications riches en images dans le commerce électronique et la santé, et une bonne part des bugs « pourquoi cette liste est-elle saccadée » remonte à un chargement d'images naïf. Le cache gratuit est le bienvenu, avec une mise en garde issue de notre travail sur les infrastructures et la sécurité : le cache vaut ce que valent vos en-têtes. Si votre CDN ou votre serveur d'origine envoie des valeurs Cache-Control faibles, vous ne mettez rien en cache ou vous le faites trop longtemps. Quand nous configurons Cloudflare pour nos clients, les en-têtes de cache sont une vraie surface de configuration que nous réglons délibérément, pas une réflexion après coup. La même rigueur s'applique ici.

Il y a aussi un nouveau modèle de document. SwiftUI ajoute les protocoles WritableDocument et ReadableDocument avec un accès disque asynchrone et incrémental, et les écritures utilisent désormais un diffing basé sur des snapshots de sorte qu'un DocumentWriter ne sauvegarde que les parties modifiées. Si vous maintenez une application basée sur des documents, c'est un vrai levier de performance pour les fichiers volumineux. Les conteneurs réordonnables sont l'autre belle touche : les utilisateurs peuvent maintenant glisser pour réorganiser les éléments dans n'importe quel conteneur, pas seulement List, en utilisant le même code entre List et LazyVStack.

Côté outillage, Swift 6.3 et 6.4 ont été livrés ensemble dans la bêta d'Xcode 27. Le changement que la plupart des équipes ressentiront est l'interopérabilité bidirectionnelle entre Swift Testing et XCTest. Vous pouvez appeler des assertions XCTest depuis un test Swift Testing et l'inverse fonctionne également. En mode limité par défaut, les problèmes inter-frameworks apparaissent comme des avertissements ; passez votre package à swift-tools-version: 6.4 pour le mode complet. Si vous retardiez l'adoption de Swift Testing parce que votre suite XCTest est volumineuse, cette friction est en grande partie disparue. Écrivez votre prochain test en Swift Testing et laissez les anciens où ils sont.

Ce que nous dirions à une équipe cette semaine

Testez avec Xcode 27 maintenant, livrez avec iOS 26 comme vous le faites déjà. Traitez l'erreur @State comme une tâche planifiée, pas une urgence. Auditez votre cache d'images pendant qu'AsyncImage est dans votre esprit, et commencez à écrire de nouveaux tests en Swift Testing. Rien de tout cela n'est urgent dans le calendrier d'Apple. Tout est moins cher en juillet qu'en septembre.

Nous avons fait traverser à de nombreuses codebases mobiles et web exactement ce type de migration de chaîne d'outils sans panique en semaine de lancement, et vous pouvez voir le genre de travail que nous faisons dans nos projets passés.

Si pousser une grande application SwiftUI à travers les changements de build d'Xcode 27 avant le crunch de publication automnal vous parle, discutons-en.