Xcode 27 abandonne Intel : ce qui s'arrête et ce qui continue de sortir

Le changement Intel le plus susceptible de modifier un binaire que vous distribuez déjà, Apple l’a classé sous Nouveautés plutôt que sous Dépréciations. Les notes de version de Xcode 27 comportent une section intitulée Intel Deprecation qui contient exactement deux entrées, et celle qui empêche une application macOS de se construire en Universal par défaut se trouve du côté des Nouveautés.¹²

En bref

• Trois changements distincts se cachent derrière le titre, et les phrases d’Apple elles-mêmes les tiennent séparés. Xcode 27 ne s’installe et ne s’exécute que sur les Mac Apple silicon.² Le SDK macOS 27 continue de produire des applications Universal rétrocompatibles jusqu’à macOS 12 et versions ultérieures.² Et ARCHS_STANDARD cesse d’inclure x86_64 dès que la cible de déploiement macOS ou DriverKit d’une target atteint 27.0.¹
• Seul le troisième modifie ce que vous livrez, et il le fait sans le moindre diagnostic. Apple indique le remède dans la même entrée : « The x86_64 architecture can be added to the ARCHS build setting if this is needed. »¹
• Xcode 26.6 ne permet pas de prévisualiser le nouveau comportement. J’ai imposé MACOSX_DEPLOYMENT_TARGET=27.0 à un projet exclusivement macOS et ARCHS_STANDARD s’est malgré tout résolu en arm64 x86_64.¹³
• Deux habitudes d’audit fabriquent de fausses réponses. Passer -sdk macosx a fait dire à un projet exclusivement iOS que SUPPORTED_PLATFORMS = macosx et ARCHS_STANDARD = arm64 x86_64, et résoudre les paramètres au niveau du projet a masqué deux targets macOS dans un projet dont la target par défaut est iOS.¹⁴
• Sur 11 de mes projets Xcode totalisant 44 targets : 21 se construisent pour macOS, la cible de déploiement macOS la plus élevée y est 26.5, et aucune target ne définit ARCHS ni EXCLUDED_ARCHS.¹⁴ Les 51 archives macOS présentes sur le disque sont toutes en x86_64 arm64.¹⁴
• La fin des logiciels Intel arrive avec macOS 28, pas avec Xcode 27, et la phrase d’Apple contient une réserve qui mérite lecture : « All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games. »¹⁰

Tout ce qui précède est publié par Apple sous forme de texte bêta, dans les notes de version de Xcode 27 bêta 4 et de macOS 27 bêta 4.³⁶

Trois phrases, trois changements différents

La section Intel Deprecation d’Apple contient deux entrées. Les lire comme une affirmation unique mène à la mauvaise décision, dans un sens comme dans l’autre.

L’entrée de dépréciation concerne la machine posée sur votre bureau, et elle ne s’embarrasse d’aucune nuance : « Xcode 27 will only install and run on Apple silicon Macs. »² Aucun paramètre de build n’y change quoi que ce soit. Un Mac Intel cesse d’être une machine capable de faire tourner la version actuelle de Xcode, et le tableau de compatibilité d’Apple ajoute un plancher logiciel au plancher matériel en indiquant macOS Tahoe 26.4 ou ultérieur comme prérequis pour Xcode 27 bêta 4.⁴

La même entrée protège ensuite ce que vous produisez : « The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. »² Le tableau de compatibilité d’Apple va dans le même sens, avec une plage de déploiement macOS allant de 12 à 27 pour Xcode 27 bêta 4, contre 11 à 26.5 pour Xcode 26.6.⁴ Le plancher n’a monté que d’une seule version. Les binaires Universal survivent.

Et l’entrée se referme en préservant le flux de travail lui-même : « Intel development is still possible with macOS versions that support Rosetta like macOS 27. »²

Vient alors l’entrée des Nouveautés, celle qui est capable de modifier un produit que vous distribuez déjà :

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. The x86_64 architecture can be added to the ARCHS build setting if this is needed.¹

Quatre détails y méritent d’être distingués. Apple nomme deux paramètres et aucun autre : IPHONEOS_DEPLOYMENT_TARGET et ses équivalents restent donc hors du champ de la règle. Apple nomme un seuil plutôt qu’une version de chaîne d’outils : le déclencheur est donc votre propre cible de déploiement franchissant 27.0. Apple écrit « will not build Universal by default », ce qui décrit un comportement par défaut, pas une interdiction. Et Apple fournit l’échappatoire dans la foulée, en désignant ARCHS comme l’endroit où réintroduire x86_64.

Le comportement par défaut qui change sans lever d’erreur

Le mécanisme est ordinaire, et c’est précisément ce qui le rend discret. La référence des paramètres de build d’Apple décrit ARCHS ainsi : « A list of the architectures for which the product will be built. This is usually set to a predefined build setting provided by the platform. If more than one architecture is specified, a universal binary will be produced. »⁵ Le paramètre prédéfini, c’est ARCHS_STANDARD, et Apple confirme la dépendance ailleurs dans la même référence en notant que l’authentification de pointeurs « Has no effect if ARCHS has been overridden to not be based on ARCHS_STANDARD. »⁵

Une target qui ne mentionne jamais ARCHS hérite donc de ce que la plateforme lui tend. Changez ce que la plateforme lui tend et le produit change de forme sans la moindre modification d’un fichier sous contrôle de version.

Rien dans ce changement ne provoque d’échec. Le compilateur s’exécute, l’éditeur de liens s’exécute, et l’archive passe la validation. Rien dans la chaîne d’outils ne considère un build macOS arm64 à tranche unique comme une erreur, parce que ce n’en est pas une. Le résultat est une application macOS correcte et signée, portant une seule tranche d’architecture là où elle en portait deux. Sur un Mac Apple silicon, la machine que tout développeur Xcode 27 utilise désormais par obligation, le build arm64 seul se lance et se comporte à l’identique. La régression n’apparaît que sur du matériel qui n’est plus dans les murs.

Qualifier ce mode de défaillance de silencieux relève de ma lecture, pas de celle d’Apple ; Apple décrit le comportement par défaut et s’arrête là. Ce qu’Apple dit en revanche, c’est que le correctif est additif, et la formulation compte pour la planification : x86_64 « can be added to the ARCHS build setting if this is needed. »¹ Apple vous laisse juger de la nécessité.

Ce que Xcode 26.6 vous dira, et ce qu’il ne vous dira pas

Ma machine tourne sous Xcode 26.6 (build 17F113) sur macOS 26.5.2 : aucun comportement de Xcode 27 n’apparaît donc où que ce soit dans cet article.¹³ La question utile à laquelle une chaîne d’outils antérieure peut répondre, c’est de savoir si elle se comporte déjà de la nouvelle façon. Ce n’est pas le cas.

Pointer xcodebuild sur un projet exclusivement macOS et forcer la cible de déploiement au-delà du seuil nommé par Apple laisse la liste des architectures intacte :¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

La première ligne est xcodebuild qui renvoie la valeur forcée en écho ; les suivantes sont les valeurs résolues. La même commande avec 26.0 renvoie des lignes d’architecture identiques.¹³ Xcode 26.6 n’implémente pas le seuil : personne ne peut donc répéter le changement à l’avance sur la chaîne d’outils actuelle, et toute comparaison avant/après devra attendre Xcode 27 sur un Mac Apple silicon.

Le cadrage par plateforme, lui, se reproduit dès aujourd’hui. Le même projet résolu face au SDK iOS renvoie ARCHS_STANDARD = arm64, sans x86_64 à perdre, tandis que le SDK macOS renvoie arm64 x86_64.¹³ L’entrée d’Apple ne nomme que les cibles de déploiement macOS et DriverKit, et le versant iOS d’un projet multiplateforme n’est pas concerné.

Auditer votre propre exposition sans l’inventer

Deux habitudes produisent des réponses fausses avec assurance. Je suis tombé dans les deux.

La première consiste à passer -sdk macosx pour savoir si un projet se construit pour macOS. L’option écrase le SDK propre au projet : Xcode répond alors à une question portant sur l’option, et non sur le projet. Interrogé sans valeur forcée, un de mes projets de navigateur exclusivement iOS indique sa vraie plateforme ; interrogé avec -sdk macosx, le même projet annonce SUPPORTED_PLATFORMS = macosx et ARCHS_STANDARD = arm64 x86_64, ce qui n’est qu’un pur artefact.¹⁴ Commencez sans aucun -sdk :

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

Sur mon unique application exclusivement macOS, deux lignes reviennent :¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

Lisez les deux lignes, jamais une seule. Ce projet déclare SDKROOT = macosx et pas la moindre ligne SUPPORTED_PLATFORMS : une recherche textuelle de SUPPORTED_PLATFORMS dans les fichiers de projet lui attribue donc zéro et passe à côté de la seule application exclusivement macOS que je possède.¹⁴ Les paramètres résolus comblent le manque à partir du SDK ; grep en est incapable. Ignorez MACOSX_DEPLOYMENT_TARGET à ce stade, car Xcode en fournit une quoi qu’il arrive : trois de mes projets exclusivement iOS déclarent malgré tout une cible de déploiement macOS, deux à 26.5 et une à 26.2.¹⁴

La seconde habitude consiste à résoudre les paramètres au niveau du projet. xcodebuild -showBuildSettings sans -target répond pour une seule target, et un projet mixte enterre les autres. Mon projet d’extension Safari se résolvait en SUPPORTED_PLATFORMS = iphoneos iphonesimulator et ARCHS_STANDARD = arm64, ce qui se lit comme un projet exclusivement iOS sans aucune exposition à Intel. L’énumération de ses targets en a révélé quatre, dont deux macOS, résolvant toutes deux arm64 x86_64 :¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

Une bizarrerie à anticiper : une target portant SDKROOT = auto ne résout aucun ARCHS_STANDARD tant que vous ne nommez pas un SDK ; 15 de mes 21 targets macOS n’affichent donc rien sur cette ligne jusqu’à ce que la commande ajoute -sdk macosx, moment où leurs projets résolvent arm64 x86_64.¹⁴ Une ligne vide signifie « non résolu », pas « valeur vide ».

Cessez ensuite de faire confiance aux paramètres et lisez un binaire. Les paramètres de build décrivent une intention ; lipo décrit l’artefact que vous avez réellement livré :

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

Préférez lipo aux métadonnées de l’archive elle-même. Deux de mes archives ne contiennent aucune liste d’architectures ApplicationProperties dans leur Info.plist : une requête plutil sur l’archive ne renvoie donc rien, tandis que lipo sur le binaire qu’elle contient renvoie x86_64 arm64.¹⁴ Une absence dans les métadonnées signifie que l’archive a été écrite autrement, pas que l’application a perdu une tranche.

Ce que contiennent réellement 11 projets

J’ai mené l’audit sur 11 projets Xcode totalisant 44 targets. Huit projets contiennent au moins une target macOS, 21 targets se construisent pour macOS, et l’exposition au nouveau comportement par défaut est aujourd’hui nulle.¹⁴

La cible de déploiement macOS la plus élevée du parc est 26.5, la plus basse 13.0 sur une extension Safari que personne n’a rouverte depuis un moment. Aucune target ne franchit 27.0 : aucune n’entre donc dans le régime au comportement par défaut modifié tant que quelqu’un ne relève pas un numéro à la main. Aucune target ne définit ARCHS, aucune ne définit EXCLUDED_ARCHS, et le parc ne contient aucun fichier .xcconfig : chaque décision d’architecture dans les 44 targets vient donc de ARCHS_STANDARD.¹⁴

La preuve par les archives pèse plus lourd que la preuve par les paramètres, car les archives enregistrent ce qui est réellement parti. Ma machine héberge 79 archives construites entre avril et juillet 2026. Les 51 archives macOS, réparties sur sept produits distincts, indiquent toutes x86_64 arm64. Les 28 archives de la famille iOS indiquent toutes arm64.¹⁴ Personne, sur aucun de ces projets, n’a jamais choisi Universal ; c’est le comportement par défaut qui l’a produit, à chaque fois. Voilà la population sur laquelle agit le changement d’Apple, et précisément la raison pour laquelle personne ne le remarquera.

Une lacune qu’il faut assumer : relever une cible de déploiement à 27.0 est un acte délibéré, et aucun de mes projets n’a encore de raison de le faire. Le résultat impeccable du parc mesure un instant, pas une politique.

Où les logiciels Intel s’arrêtent vraiment

Le changement Xcode porte sur les architectures d’un build. La fin des logiciels Intel en tant que catégorie, elle, se situe dans macOS 28, et Apple l’a consignée à la fois dans sa documentation Rosetta et dans les notes de version de macOS 27, qui concordent.

La documentation Rosetta d’Apple fixe l’échéance sans détour. Rosetta « was designed to make the transition to Apple silicon easier, and will be available through macOS 27 » en tant qu’outil polyvalent pour les applications Intel, et « Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks. »⁷ Les notes de version de macOS 27 en énoncent la conséquence avec la même réserve : « All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games. »¹⁰ Une commande réservée aux bêtas, ailleurs dans ces mêmes notes, donne une forme concrète à cette réserve : sudo game-test-tool enable active la prise en charge des jeux Intel hérités, et Apple avertit qu’« enabling legacy game support disables Rosetta. »¹⁵

macOS 27 met l’intervalle à profit pour nommer ce qui ne survivra pas. La section Deprecation Information d’Apple signale que « Intel-based applications that will no longer run in macOS 28.0 now display a treatment in Get Info », et une entrée distincte ajoute que « Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0 », y compris les « unused Intel-based software discovered on the system ».⁸⁹

Trois entrées plus discrètes comptent davantage pour quiconque livre un produit Mac.

Rosetta cesse d’être persistant : « If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0. »¹¹ La documentation d’Apple fournit le contexte en notant que macOS 27 « directly integrates support for Intel binary translation, without needing to install Rosetta », au service des binaires Linux Intel dans des machines virtuelles ARM et des conteneurs Linux Intel.⁷ Les applications qu’un utilisateur avait épinglées changent elles aussi : celles réglées auparavant sur « Open using Rosetta » vont désormais « have the application launch natively », et Apple conseille que « Any compatibility issues requiring Rosetta from the past should be re-assessed on macOS 27. »¹²

Les programmes d’installation changent de valeur par défaut : « Installer packages which specify no hostArchitecture will now default to arm64 », et Apple vous demande de « Ensure any pre and post install scripts behave as intended under arm64. »¹¹ Tout produit Mac distribué hors de l’App Store hérite de cette contrainte, que son application soit Universal ou non.

Ce sont les hôtes de plugins qui portent l’arête la plus vive. Apple prévient que « Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility », et nomme les répertoires à vérifier à la main, dont ~/Library/Audio/Plug-Ins/, ~/Library/Printers/ et ~/Library/ColorPickers/.¹⁰ La raison pour laquelle un plugin peut immobiliser une application par ailleurs native figure dans la documentation Rosetta d’Apple : « The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically. »⁷ Un plugin Intel force donc son hôte à s’exécuter en mode traduit, transformant un composant non maintenu en une dépendance de l’application entière à un dispositif dont Apple a programmé la réduction.

Universal existe pour atteindre les Mac Intel tournant sous macOS 12 à 27, la plage que publie le tableau de compatibilité d’Apple pour Xcode 27.⁴ Apple a daté la fin des logiciels Intel à macOS 28 et laissé la plage de déploiement intacte : la vraie question, pour une équipe macOS, est donc de savoir combien de ses utilisateurs tournent encore sur un Mac qui a besoin de cette tranche.

Deux points que j’ai vérifiés sans rien trouver : ni les notes de version de Xcode 27 ni celles de macOS 27 ne disent quoi que ce soit sur une évolution des exigences d’achat universel (Universal Purchase) du Mac App Store, et aucune des deux ne fixe de date pour macOS 28.³⁶ Toute date que vous lirez ailleurs est à traiter comme une déduction.

FAQ

Xcode 27 m’empêche-t-il de livrer des applications Intel ?

Non, et Apple affirme le contraire dans l’entrée même qui déprécie les Mac Intel comme machines de développement : « The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. »² Le tableau de compatibilité d’Apple confirme la plage, en indiquant macOS 12 à 27 comme cibles de déploiement pour Xcode 27 bêta 4.⁴ Ce qui change, c’est le comportement par défaut. Une target dont la cible de déploiement macOS atteint 27.0 cesse de recevoir x86_64 depuis ARCHS_STANDARD, et le correctif énoncé par Apple consiste à ajouter vous-même x86_64 à ARCHS.¹ Livrer pour Intel devient un choix que vous déclarez, plutôt qu’un choix dont vous héritez.

Mon build va-t-il échouer si ARCHS_STANDARD retire x86_64 ?

Rien dans l’entrée d’Apple ne décrit d’erreur, d’avertissement ni de diagnostic d’aucune sorte. Apple décrit un comportement par défaut qui change : les targets à macOS ou DriverKit 27.0 et au-delà « will not build Universal by default. »¹ Un build qui compile, édite les liens et signe avec une seule tranche d’architecture au lieu de deux reste un build valide, et sur le Mac Apple silicon que Xcode 27 vous impose d’utiliser, la différence est invisible à l’exécution.² Apple énonce le comportement par défaut et laisse la conséquence non écrite : le mot « silencieux » est de moi, pas d’Apple. Vérifiez avec lipo -archs sur le binaire archivé plutôt que d’attendre qu’un journal de build aborde le sujet.

Puis-je tester le nouveau comportement sur Xcode 26 ?

Non. J’ai fait la vérification directement sur Xcode 26.6 (build 17F113) : forcer MACOSX_DEPLOYMENT_TARGET à 27.0 sur un projet exclusivement macOS résout toujours ARCHS_STANDARD = arm64 x86_64, à l’identique de la même commande avec 26.0.¹³ La chaîne d’outils précédente n’implémente pas le seuil : aucune expérimentation sur les paramètres de build dans Xcode 26 ne permet donc de prévisualiser le changement. Ce que Xcode 26.6 reproduit bel et bien, c’est le cadrage : le même projet résout ARCHS_STANDARD = arm64 face au SDK iOS et arm64 x86_64 face au SDK macOS, conformément à une entrée qui ne nomme que les cibles de déploiement macOS et DriverKit, et rien d’autre.¹¹³

Ai-je désormais besoin d’un Mac Apple silicon ?

Pour faire tourner Xcode 27, oui, sans nuance : « Xcode 27 will only install and run on Apple silicon Macs. »² Apple ajoute un plancher logiciel au plancher matériel, en exigeant macOS Tahoe 26.4 ou ultérieur pour Xcode 27 bêta 4.⁴ Le développement Intel survit sur les chaînes d’outils plus anciennes, ce qui est la façon dont Apple le présente : « Intel development is still possible with macOS versions that support Rosetta like macOS 27. »² La documentation Rosetta d’Apple pose une limite à cette voie, en indiquant que Rosetta « will be available through macOS 27 » en tant qu’outil polyvalent, avec ensuite un sous-ensemble réduit destiné aux jeux anciens non maintenus.⁷

À retenir

Pour les développeurs d’applications macOS : - Auditez d’abord sans aucune option -sdk, lisez SUPPORTED_PLATFORMS et SDKROOT ensemble, et ignorez MACOSX_DEPLOYMENT_TARGET lorsque la question est de savoir si une target se construit pour macOS tout court. Xcode inscrit une cible de déploiement macOS jusque dans des projets exclusivement iOS : trois des miens en déclarent une (26.5, 26.5 et 26.2) tout en ne se construisant pour aucun Mac.¹⁴ - Énumérez les targets avec xcodebuild -list avant de résoudre les paramètres. Une requête au niveau du projet sur mon extension Safari annonçait un projet exclusivement iOS et masquait deux targets macOS.¹⁴

Pour les équipes dont les utilisateurs ont des Mac Intel : - Décidez explicitement de x86_64 au lieu d’en hériter. Définissez ARCHS au moment où vous relevez une cible de déploiement macOS à 27.0, car l’entrée d’Apple offre exactement ce remède et aucun avertissement si vous l’oubliez.¹ - Vérifiez avec lipo -archs sur le binaire archivé, pas sur les paramètres de build ni sur l’Info.plist de l’archive. Deux de mes archives ne portent aucune métadonnée d’architecture alors que leurs binaires sont Universal.¹⁴

Pour les responsables de publication : - Séparez l’échéance matérielle de l’échéance de livraison. Xcode 27 exige un Mac Apple silicon dès le premier jour ; la sortie Universal survit jusqu’à macOS 12 et versions ultérieures, et Apple n’a publié aucune date pour macOS 28.²⁴ - Inventoriez les plugins et les paquets d’installation Intel, pas seulement les applications. Apple prévient que les plugins Intel « may not appear in Settings », et un plugin Intel force l’intégralité de son processus hôte à s’exécuter en mode traduit.⁷¹⁰

Le cycle 27 continue de dissimuler des changements lourds de conséquences dans des recoins anodins. La suppression de l’éditeur de liens et la règle sur les noms de modules cassent purement et simplement les builds à la mise à jour de la chaîne d’outils, la macro @State les casse au niveau du code source, et la clé d’écran de lancement bloque une soumission. Le comportement par défaut d’Intel ne casse rien et modifie tout de même le produit, ce qui rend l’audit préférable avant la mise à jour plutôt qu’après. Le sommaire complet de la série se trouve sur la page Série Écosystème Apple.

Références