Xcode 27 est sorti : configuration requise, cibles de déploiement et ce qui casse

Xcode 27 est sorti le 14 septembre 2026 sous le build 27A266a, trois jours après l’entrée iOS 27.0 RC du flux Releases et en même temps qu’iOS 27.0 (24A437), macOS 27.0 (26A428) et le reste des plateformes 27 ; App Store Connect a commencé le jour même à accepter les builds produits avec les SDK 27.0 GA, après avoir pris les builds RC depuis le 9 septembre.¹⁵ Il exige macOS Tahoe 26.6 ou plus récent et un Mac Apple Silicon, embarque Swift 6.4 et les SDK 27, débogue les appareils sous iOS 17 ou plus récent, et relève trois planchers de déploiement : macOS 12, watchOS 9 et DriverKit 21.²³ Pour les projets existants, il apporte trois échecs bloquants (la macro @State, une rupture de compatibilité source liée à SE-0508 et le drapeau d’édition de liens -ld64), une règle d’analyse des dépendances qui peut produire une erreur, un changement silencieux d’ARCHS_STANDARD et deux avertissements ; j’ai reproduit tout cela sur 27A266a, sauf la règle d’analyse, dans la suite de ce billet.²⁴⁶ {.answer-block}

L’essentiel

• Dates et builds. Le flux Releases d’Apple liste Xcode 27 (27A266a) et les six systèmes 27.0 au lundi 14 septembre ; son entrée « iOS 27.0 RC (24A437) » porte la date du vendredi 11 septembre, deux jours après qu’App Store Connect a commencé à accepter les envois compilés avec le SDK RC, et la GA porte le même numéro de build.¹⁵ Les notes de version d’App Store Connect du 14 septembre indiquent que vous pouvez désormais envoyer des apps compilées avec Xcode 27 vers le store et vers TestFlight.⁵
• Configuration requise et planchers relevés. Xcode 26.6 tournait sur macOS 26.2 et déboguait des appareils iOS 15 ; Xcode 27 exige macOS 26.6, ne tourne que sur Apple Silicon et ne débogue qu’iOS 17, tvOS 17 et watchOS 10 ou plus récent, dans le simulateur comme sur le matériel. Les cibles de déploiement minimales passent de macOS 11 à 12, de watchOS 8 à 9 et de DriverKit 20 à 21 ; iOS, iPadOS et tvOS restent à 15, visionOS à 1.²³
• Trois échecs bloquants. La macro @State : l’exemple d’Apple lui-même, un initialiseur qui affecte une propriété @State dotée d’une valeur à la déclaration avant les autres propriétés stockées, échoue avec variable 'self.title' used before being initialized ; une propriété calculée avec un littéral de tableau ou de dictionnaire comme valeur initiale et un accesseur init ne compile plus si le getter vient en premier, une rupture source qu’Apple attribue à SE-0508 ; et le drapeau -ld64, documenté par Xcode 15, fait échouer l’édition de liens avec ld: library 'd64' not found.²⁴⁶⁸
• Quatre changements qui avertissent, peuvent échouer ou ne disent rien. L’éditeur de liens ignore -ld_classic avec un avertissement, puisque ld64 a disparu ; des noms de modules Clang en double au sein d’une même analyse des dépendances « may report an error » (peuvent produire une erreur) ; une cible macOS seule réglée sur 27.0 ne compile qu’en arm64 sauf si vous rajoutez x86_64 vous-même, sans aucun avertissement ; et PreviewProvider porte une dépréciation 27.0 avec « Use #Preview instead. », tandis que chaque modificateur d’aperçu porte son propre message de remplacement, dont le compilateur n’affiche aucun sous une cible de déploiement 27.0.²⁴
• Apple n’a pas publié Xcode 27.1 au 15 septembre. Ni le flux Releases ni l’index des notes de version ne le listent, et la page développeur d’Apple pour l’iPhone Duo date toujours la bêta 27.1 de « later this month » (plus tard ce mois-ci) ; le trou de SDK décrit dans mon billet Duo pour les développeurs tient toujours.¹

Qu’est-ce qui est sorti le 14 septembre ?

La section Overview des notes de version dit : « Xcode 27 includes Swift 6.4 and SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27 requires a Mac running macOS Tahoe 26.6 or later. » (Xcode 27 inclut Swift 6.4 et les SDK 27, prend en charge le débogage sur appareil à partir d’iOS 17, tvOS 17 et watchOS 10 ainsi que sous visionOS, et exige un Mac sous macOS Tahoe 26.6 ou plus récent.)² Sur ce Mac, xcodebuild -version affiche Xcode 27.0 Build version 27A266a et swift --version affiche Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1).⁴

Que demande Xcode 27, comparé à 26.6 ?

Le tableau de compatibilité d’Apple est le document à consulter avant de mettre à niveau une machine de build. Les deux lignes, côte à côte :³

Deux conséquences se cachent derrière ces lignes. Instruments refuse désormais les appareils plus anciens qu’iOS 17, watchOS 10 ou tvOS 17, si bien qu’un banc de profilage monté sur un vieil iPhone cesse de fonctionner avant la moindre ligne de code de l’app.² Et Apple délimite les interactions clavier et pointeur du Device Hub en une phrase : « only supported on the following OS versions and newer : macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0. » (pris en charge uniquement à partir de macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0 et visionOS 2.0.)²

L’exigence Apple Silicon n’a aucun contournement pour le Mac sur lequel vous exécutez Xcode, et ce n’est pas une nouvelle pour qui a lu le billet Intel en juillet ; les notes de la GA reprennent intégralement la formulation de juillet : « Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. » (Xcode 27 ne s’installe et ne s’exécute que sur les Mac Apple Silicon ; le SDK macOS 27 permet de déployer des apps Universal jusqu’à macOS 12 ; le développement Intel reste possible sur les versions de macOS qui prennent en charge Rosetta, comme macOS 27.)² La troisième phrase est le contournement pour les Mac auxquels vous livrez, pas pour celui sur lequel vous compilez.

Qu’est-ce qui a changé dans la chaîne d’outils ?

L’éditeur de liens. Les notes de la GA le disent en une phrase : « The ld64 linker has been removed and the -ld_classic option is no longer supported. » (L’éditeur de liens ld64 a été supprimé et l’option -ld_classic n’est plus prise en charge.)² Voici à quoi cela ressemble sur 27A266a : le usr/bin de la chaîne d’outils contient un seul binaire d’édition de liens, ld, qui se présente comme ld-27037.1, compilé le 25 août 2026. Passer l’ancien drapeau ne fait pas échouer l’édition de liens. Avec un hello.c contenant la seule ligne int main(void){return 0;}, clang hello.o -o hello_classic -Xlinker -ld_classic affiche ld: warning: -ld_classic is no longer supported and will be ignored, se termine avec le code 0 et écrit l’exécutable. L’autre orthographe documentée par Apple dans Xcode 15, -ld64, s’en sort moins bien :⁸ clang hello.c -o hello_ld64 -Wl,-ld64 échoue avec ld: library 'd64' not found et se termine avec le code 1, parce que le nouvel éditeur de liens lit -ld64 comme -l d64, une demande de bibliothèque nommée d64.⁴ Un projet qui garde -ld_classic dans OTHER_LDFLAGS continue donc de compiler, avec un nouvel avertissement à chaque édition de liens, et tout comportement qu’il obtenait de l’ancien éditeur a disparu ; un projet qui porte -ld64 cesse de se lier, avec une erreur qui ne nomme jamais l’éditeur de liens. Mon billet ld64 retrace l’origine de ces drapeaux et consigne les deux exécutions.

Les architectures par défaut. La section Intel Deprecation énonce la règle : « Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. » (Les cibles dont le déploiement minimal est macOS 27.0 ou DriverKit 27.0 ne compilent plus en Universal par défaut ; le réglage ARCHS_STANDARD n’inclut plus x86_64 lorsque MACOSX_DEPLOYMENT_TARGET ou DRIVERKIT_DEPLOYMENT_TARGET >= 27.0.)² Je l’ai reproduit sur un projet multiplateforme (Yawara, avec SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx xros xrsimulator) au moyen de xcodebuild -showBuildSettings -sdk macosx ; sans l’argument -sdk, le projet ne résout aucun ARCHS_STANDARD du tout, une subtilité que couvre le billet Intel. À MACOSX_DEPLOYMENT_TARGET = 26.0, le réglage se résout en ARCHS_STANDARD = arm64 x86_64 ; à 27.0, en ARCHS_STANDARD = arm64, tandis qu’ARCHS_STANDARD_64_BIT reste arm64 x86_64 dans les deux cas.⁴ Rien n’avertit. Si vous livrez en Universal et relevez la cible, ajoutez x86_64 à ARCHS vous-même.

La bibliothèque standard C++. « The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0. » (La cible de déploiement minimale de la bibliothèque standard C++ sur macOS passe à 11.0.) Les notes listent des changements de comportement sous « Potentially breaking changes » (changements potentiellement incompatibles), à commencer par multi{map,set}::find qui ne renvoie plus nécessairement le premier élément correspondant.² La liste des nouveautés est longue : hachage des valeurs std::chrono, zip, std::optional<T&>, std::views::indices(n) et plus encore.²

L’analyse des dépendances, et la règle qui peut la faire échouer. Apple dit avoir optimisé l’analyseur de dépendances Swift « to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action » (pour éviter les préparations et recherches d’en-têtes redondantes lors de la résolution des modules Clang au sein d’une même analyse), et ce gain de vitesse s’accompagne d’une exigence : « every Clang module reachable from a single Swift dependency-scan action must have a unique module name. If two module maps visible to the same scan declare a Clang module with the same name, the scan may report an error. Previously, the scanner may have tolerated duplicating names. » (Chaque module Clang atteignable depuis une même analyse des dépendances Swift doit porter un nom unique ; si deux module maps visibles par la même analyse déclarent un module Clang du même nom, l’analyse peut produire une erreur ; auparavant, l’analyseur tolérait parfois les doublons.)² Apple nomme les deux configurations qui trébuchent dessus : « projects or SDKs that vend the same Clang module name from more than one location on the header search path, and vendored third-party sources that ship a module.modulemap redeclaring an SDK module. » (les projets ou SDK qui exposent le même nom de module Clang depuis plusieurs emplacements du chemin de recherche des en-têtes, et les sources tierces embarquées livrées avec un module.modulemap qui redéclare un module du SDK.)² Comme la suppression de l’éditeur de liens, la règle se déclenche à la mise à niveau de la chaîne d’outils, et non selon la cible de déploiement ; mon billet ld64 fait passer deux module maps en collision dans l’analyseur, compile un shim SQLite3 embarqué qui masque le module du SDK, et audite sept projets sur ces deux configurations.

Qu’est-ce qui ne compile plus ?

La macro @State. Le changement figure dans les notes de version d’iOS 27, pas dans celles de Xcode, et il dépend du compilateur avec lequel vous compilez, pas de la cible vers laquelle vous déployez : « Xcode 27 introduces a new @State implementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new @State is implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions. » (Xcode 27 introduit une nouvelle implémentation de @State qui évite cette évaluation répétée ; ce nouveau comportement se rétro-déploie jusqu’aux systèmes alignés sur iOS 17 ; le nouveau @State est implémenté par une macro Swift, largement compatible au niveau source avec la version property wrapper, à quelques exceptions près.)⁶ Apple nomme quatre exceptions et en illustre deux par du code ; les deux autres reçoivent une phrase ou deux chacune : « In rare situations, the automatic inference of generic arguments of @State is less flexible with the macro implementation. Write the type with more specificity. » (Dans de rares cas, l’inférence automatique des arguments génériques de @State est moins souple avec la macro ; écrivez le type plus précisément.) et « Composing @State with other property wrappers or macros is not supported. » (Combiner @State avec d’autres property wrappers ou macros n’est pas pris en charge.)⁶ Les deux exceptions illustrées sont celles qui attrapent le code existant. Un initialiseur qui affecte une propriété @State ayant déjà une valeur à la déclaration : SwiftUI a toujours ignoré cette affectation, et désormais « some such cases no longer compile. » (certains de ces cas ne compilent plus.)⁶ Et l’initialiseur membre à membre privé que le compilateur synthétise quand tous les membres stockés sont privés : « The state macro disables this synthesized initializer. So the code above no longer compiles. » (La macro state désactive cet initialiseur synthétisé ; le code ci-dessus ne compile donc plus.)⁶ Sur 27A266a, le premier exemple échoue tel quel, avec error: variable 'self.title' used before being initialized sur la ligne qui affecte page, parce que le setter de la macro s’exécute sur self avant que title n’existe ; déplacez self.title = title au-dessus et le même fichier compile, l’affectation de @State étant ignorée comme avant.⁴⁶ Le second exemple, une extension appelant self.init(page: page, title: title) sur une struct dont le @State n’a pas de valeur à la déclaration, a compilé sans modification dans mon test, et l’expansion de la macro montre la forme qui le permet : la macro émet private var _page: SwiftUICore.State<StickerPage> derrière un accesseur init @storageRestrictions(initializes: _page), la construction qui permet à un initialiseur membre à membre d’accepter page:.⁴ Lisez la note comme une description des formes à vérifier, puis confirmez chacune sur votre propre code. Le billet sur la macro @State compte les deux motifs dans quatre apps en production ; je l’ai écrit en juillet à partir des notes de la bêta, avant ce test sur la GA, et sa question ouverte se referme ici aussi : affecter directement le stockage sous-jacent, _page = State(initialValue:) dans un initialiseur, compile sur 27A266a avec ou sans valeur à la déclaration.⁴

La rupture SE-0508. Sous Swift Compiler, Known Issues : « A computed property with both an init accessor and an array/dictionary literal initial value will no longer compile if the getter is declared before the init accessor. » (Une propriété calculée dotée à la fois d’un accesseur init et d’un littéral de tableau ou de dictionnaire comme valeur initiale ne compile plus si le getter est déclaré avant l’accesseur init.) Un listing suit, puis l’attribution : « This is a known source break from SE-0508. » (C’est une rupture source connue, issue de SE-0508.) Le contournement, en entier : « Swap the init accessor and the getter such that the init accessor is declared first. » (Intervertissez l’accesseur init et le getter de sorte que l’accesseur init soit déclaré en premier.)² SE-0508, c’est « Array expression trailing closures » (trailing closures dans les expressions de tableau), implémenté dans Swift 6.4, et la proposition prédit exactement ce cas : « If the getter is declared before the init accessor, we will now attempt to parse as a trailing closure. » (Si le getter est déclaré avant l’accesseur init, nous tentons désormais de l’analyser comme une trailing closure.) Elle ajoute que « init accessors are however considered for disambiguation, so swapping the accessors is sufficient to make this valid regardless of initial value used. » (les accesseurs init servent toutefois à lever l’ambiguïté, intervertir les accesseurs suffit donc quelle que soit la valeur initiale.) et que ce cas « does not appear in the source compatibility suite, or for internal Swift projects at Apple. » (n’apparaît ni dans la suite de compatibilité source ni dans les projets Swift internes d’Apple.)⁷ Une struct de neuf lignes suffit à le reproduire. Avec le getter en premier, swiftc échoue sur la ligne de l’accesseur avec error: initializers may only be declared within a type ; déplacez l’accesseur init @storageRestrictions(initializes:) au-dessus de get, et le même fichier compile.⁴

struct Container {
    private var storage: [Int] = []
    var items: [Int] = [] {
        @storageRestrictions(initializes: storage)
        init(initialValue) { storage = initialValue }   // doit précéder get
        get { storage }
        set { storage = newValue }
    }
}

PreviewProvider. La section Previews liste une dépréciation : « PreviewProvider and its family of preview modifiers. » (PreviewProvider et sa famille de modificateurs d’aperçu.)² Le SDK la porte, avec un message pour le protocole et un message différent pour chaque modificateur. Dans l’interface SwiftUI du SDK iOS 27, public protocol PreviewProvider se trouve sous @available(anyAppleOS, deprecated: 27.0, message: "Use #Preview instead.") ; previewLayout dit « Use #Preview(traits: .sizeThatFitsLayout) or .fixedLayout(width:height:) instead. » ; previewDisplayName dit « Use #Preview("name") instead. » ; previewInterfaceOrientation dit « Use #Preview(traits: .landscapeLeft) or other orientation traits instead. » ; previewDevice dit « Use the device picker in Xcode’s canvas. » (Utilisez le sélecteur d’appareil du canvas de Xcode.) ; et previewContext, avec les protocoles PreviewContext et PreviewContextKey, dit « Use #Preview with a Widget timeline provider or entries instead. » (Utilisez plutôt #Preview avec un timeline provider ou des entries de Widget.)⁴ Deux faits décident si vous verrez un jour ces messages. Le compilateur compare la version de dépréciation à la cible de déploiement, donc les modificateurs n’avertissent que dans une cible dont le minimum est 27.0 : un fichier utilisant previewLayout, previewDisplayName et previewDevice a produit trois avertissements à -target arm64-apple-ios27.0-simulator et aucun à 17.0 ou 26.0. Et PreviewProvider lui-même n’avertit jamais, pour une autre raison. Le SDK le déclare avec @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) juste au-dessus de la dépréciation anyAppleOS, et dans ma sonde, un protocole portant cette paire n’a produit aucun avertissement pour une conformité ni pour un usage comme type de paramètre à une cible 27.0, alors que le même protocole déprécié avec @available(iOS, deprecated: 27.0) seul, ou avec la forme anyAppleOS seule, avertissait dans les deux cas ; les modificateurs ne portent que la dépréciation anyAppleOS sur leurs propres déclarations (l’extension SwiftUICore.View qui les contient porte l’attribut introduced, et cette forme héritée ne supprime pas l’avertissement), ce qui explique qu’ils avertissent et que le protocole non.⁴ À toute cible de déploiement réellement livrée, le journal de build reste muet dans les deux cas, alors cherchez PreviewProvider et les modificateurs et passez à #Preview, que le canvas affiche désormais en grilles par argument grâce à la nouvelle syntaxe #Preview(arguments:).²⁴

Le nouveau stat() de System. La bibliothèque System fournit désormais des API Swift pour stat, lstat, fstat et fstatat, avec un type Stat et des méthodes d’instance FilePath.stat().² Les notes signalent comme corrigé un conflit où une extension appelant un stat() non qualifié entrait en collision avec les nouvelles méthodes ; si vous avez ajouté la qualification Darwin. pendant que ce conflit existait, elle peut rester.²

Address Sanitizer, dans l’autre sens. « Address Sanitizer might fail to launch on iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 when building with Xcode 26.4 or older. » (Address Sanitizer peut ne pas se lancer sur iOS 27.0, tvOS 27.0, watchOS 27.0 et visionOS 27.0 lorsqu’on compile avec Xcode 26.4 ou plus ancien.) Le contournement est Xcode 26.5 ou plus récent, ce qui compte pour les équipes qui gardent un Xcode plus ancien sur la machine de CI pendant que les appareils passent à 27.0.²

Qu’est-ce qui a changé dans l’IDE et les outils ?

• Interface Builder compile sans simulateur. Un nouveau mode de compilation, toolchain, « for UIKit (Cocoa Touch) based documents. Enabled by default, toolchain allows compiling IB documents without the need to download a simulator, which is especially useful for build servers. » (pour les documents basés sur UIKit ; activé par défaut, il permet de compiler les documents IB sans télécharger de simulateur, ce qui est surtout utile aux serveurs de build.)²
• Les simulateurs démarrent plus vite, et redémarrent. « The simulator runtimes now contain a pre-built dyld cache. This will make first launch of a simulator much faster. » (Les runtimes de simulateur contiennent désormais un cache dyld préconstruit, ce qui accélère nettement le premier lancement.) Et simctl gagne une commande reboot.² Un problème connu subsiste, dans les termes d’Apple : « Some simulator runtimes are not completely deleted when removed, re-appearing after a reboot. » (Certains runtimes de simulateur ne sont pas entièrement supprimés lors de leur retrait et réapparaissent après un redémarrage.)²
• Le JSON de devicectl est en version 5. xcrun devicectl --version rapporte 642.16 et list devices --json-output écrit "jsonVersion": 5 ; Apple déprécie les champs hardwareProperties, deviceProperties et connectionProperties au profit d’un dictionnaire properties, et tout résultat qui les contient encore porte un _deprecationNotice.²⁴
• Tests StoreKit. L’interface de configuration StoreKit peut définir des codes promotionnels, vous pouvez configurer des lots d’abonnements pour les tests locaux, et le Transaction Manager peut exercer des achats avec codes promotionnels sans appareil.²
• Organizer. Un Insights Overview « summarizes high-impact performance regressions » (résume les régressions de performance à fort impact), et une métrique Hitches remplace la métrique Scrolling.²
• Assistant de codage. Google Gemini rejoint la liste des modèles, et « Planning with agents is now first class in Xcode » (la planification avec des agents est désormais une fonctionnalité de premier ordre dans Xcode), avec des plans sous forme d’artefacts Markdown modifiables que vous approuvez avant que l’agent ne poursuive ; mon billet sur les agents de codage couvre le flux de travail depuis la bêta, et les notes de la GA listent un éditeur Markdown pour exactement ces artefacts.²
• Localisation. Les agents peuvent traduire les entrées d’un String Catalog, et l’export des localisations extrait désormais NSLocalizedString et les macros similaires des fichiers d’en-tête.²
• Icon Composer. Les notes l’appellent Icon Composer 2.0, « a new sharper rendering mode for upcoming 2027 operating systems » (un nouveau mode de rendu plus net pour les systèmes d’exploitation 2027 à venir) ; le bundle inclus dans 27A266a rapporte la version 27.0.²⁴
• Tests. Un plan de test peut définir comment Xcode traite un plantage de l’app cible pendant les tests d’interface, de désactivé à échec fatal, et swift test gagne --maximum-repetitions avec --repeat-until [pass|fail] plus un résumé des échecs à la fin.²
• Débogage. Avec des bridging headers, LLDB « can now directly import explicitly built Swift modules and PCH from DerivedData » (peut désormais importer directement depuis DerivedData les modules Swift et PCH compilés explicitement), et une commande language swift task tree liste les tâches de concurrence Swift.²

Ce que je ferais cette semaine

1. Lisez les lignes de compatibilité avant de toucher à la CI : macOS 26.6 sur les Mac de build, Apple Silicon uniquement, iOS 17 comme appareil de test le plus ancien, et celui de macOS 12, watchOS 9 ou DriverKit 21 qui concerne votre produit.²³
2. Cherchez -ld_classic et -ld64 avec grep et supprimez les deux ; l’éditeur de liens ignore le premier avec un avertissement à chaque édition de liens et échoue franchement sur le second. Pendant que vous êtes dans les réglages de build, repérez les fichiers module.modulemap écrits à la main qui redéclarent un module du SDK, la configuration qu’Apple nomme pour la règle d’unicité des noms de modules.²⁴
3. Si vous réglez une cible macOS ou DriverKit sur 27.0 et livrez pour Intel, définissez ARCHS explicitement ; ARCHS_STANDARD seul vous donne arm64, ce que j’ai reproduit pour macOS et qu’Apple annonce pour les deux.²⁴
4. Cherchez PreviewProvider, previewLayout, previewDisplayName et previewDevice, et suivez le message propre à chaque annotation : le protocole vers #Preview, previewLayout vers #Preview(traits: .sizeThatFitsLayout) ou .fixedLayout(width:height:), previewDisplayName vers #Preview("name"), et previewDevice vers le sélecteur d’appareil du canvas. Les modificateurs n’avertissent qu’à une cible de déploiement 27.0 et la conformité à PreviewProvider n’avertit à aucune cible, donc le journal de build d’une cible livrée reste muet.⁴
5. Compilez une fois avec Xcode 27 et lisez deux diagnostics : variable 'self.title' used before being initialized sur un initialiseur qui affecte une propriété @State déjà dotée d’une valeur à la déclaration avant les autres propriétés stockées, ce que le billet sur la macro @State détaille pas à pas, et initializers may only be declared within a type sur des propriétés avec un littéral de tableau ou de dictionnaire comme valeur initiale et un accesseur init, où vous remontez l’accesseur au-dessus du getter.²⁴⁶
6. Envoyez un build TestFlight avec les SDK 27 maintenant qu’App Store Connect les accepte, et gardez en tête la règle de l’écran de lancement et l’obligation de scène UIKit, puisque toutes deux s’appliquent à une app dès qu’elle se lie à 27.⁵⁶

Questions fréquentes

Quand Xcode 27 est-il sorti ?

Le lundi 14 septembre 2026, sous le build 27A266a, le même jour qu’iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0 et watchOS 27.0 ; le flux date son entrée iOS 27.0 RC (24A437) du 11 septembre, deux jours après qu’App Store Connect a commencé à accepter les builds compilés avec le SDK RC.¹⁵

Quel macOS Xcode 27 exige-t-il ?

macOS Tahoe 26.6 ou plus récent sur un Mac Apple Silicon. Il ne s’installe pas et ne s’exécute pas sur les Mac Intel. Il fonctionne sur macOS 27.0, sorti le même jour.²³

Quelles sont les cibles de déploiement minimales de Xcode 27 ?

iOS 15, iPadOS 15, tvOS 15, watchOS 9, visionOS 1, macOS 12 et DriverKit 21. Par rapport à Xcode 26.6, watchOS est passé de 8, macOS de 11 et DriverKit de 20.³

Xcode 27 compile-t-il encore des apps Mac Universal ?

Oui, jusqu’à macOS 12, mais plus par défaut dès que le MACOSX_DEPLOYMENT_TARGET d’une cible est 27.0 : ARCHS_STANDARD se résout alors en arm64 seul, et vous ajoutez x86_64 à ARCHS vous-même.²⁴

Xcode 27.1 est-il sorti ?

Pas au 15 septembre 2026. Le flux Releases d’Apple et l’index des notes de version de Xcode ne listent que Xcode 27, et la page développeur d’Apple pour l’iPhone Duo affiche toujours la bêta de Xcode 27.1 comme « Coming later this month » (à venir plus tard ce mois-ci) ; le SDK iPhone Duo ne fait pas partie de cette version.¹

Où sont les notes de version de Xcode 27 ?

Sur le site de documentation développeur d’Apple, sous Xcode Release Notes, une page par version ; les sections citées ici sont Overview, Linking, Intel Deprecation, Previews, Swift Compiler, Address Sanitizer, Instruments, Device Hub, devicectl, Simulator, Interface Builder, C++ Standard Library, Organizer, Coding Intelligence, Source Editor, Icon Composer, StoreKit Testing in Xcode, Localization, Testing, Swift Package Manager, Debugging et System.² Le changement de la macro @State figure plutôt dans les notes de version d’iOS et iPadOS 27, sous SwiftUI.⁶

Sources