Xcode 27 transforme les cibles de déploiement obsolètes en erreurs de build : voici la limite exacte.

Ouvrez un projet d'application Mac qui compile sans problème depuis des années, passez à la bêta de Xcode 27, lancez le build, et tout s'arrête net :

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

Dans Xcode 26, cette phrase n'était qu'un avertissement jaune que l'on pouvait ignorer en faisant défiler l'écran. Dans Xcode 27, c'est une erreur rouge et le build ne va pas plus loin. C'est tout le changement, et il est à la fois plus petit et plus important qu'il n'y paraît : plus petit, parce que la documentation d'Apple annonce depuis des années un plancher de macOS 11 et iOS 15 ; plus important, parce que Xcode ne l'a jamais réellement imposé, et qu'un grand nombre d'applications publiées en dépendent discrètement.

Cet article détaille ce que Xcode 27 impose réellement (d'après les tableaux et les notes de version d'Apple elles-mêmes), ce que Xcode 26 autorisait réellement (d'après le SDK présent sur notre propre disque), qui est concerné, le réglage non documenté qui transforme l'erreur en simple avertissement, et pourquoi l'échéance qui compte vraiment n'est pas la sortie de Xcode 27, mais l'exigence de SDK de l'App Store au printemps prochain.

Points clés à retenir

• Les cibles de déploiement prises en charge par Xcode 27 sont macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27, selon la page d'assistance Xcode d'Apple pour la bêta 6. En dessous de ces valeurs, le build échoue.
• Xcode 26 documentait macOS 11 comme plancher, mais acceptait en réalité 10.13. Nous avons vérifié le fichier de réglages du SDK macOS 26.0 : 34 cibles de déploiement valides, à partir de 10.13. Xcode 27 comble cet écart en faisant de la plage documentée la plage réellement imposée.
• Le plancher macOS a évolué pendant la bêta. En juin, la note d'Apple évoquait un back-deployment Universal « up to and including macOS 27 » ; les développeurs y ont lu Big Sur. La note de la bêta 6 indique « macOS 12 and later ». Prévoyez Monterey, pas Big Sur.
• Il existe une échappatoire non documentée, __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO, qui transformerait à nouveau l'erreur en avertissement selon les témoignages. Elle n'est pas prise en charge, peut disparaître à tout moment, et ne change rien au fait qu'Apple ne teste pas ces cibles.
• L'échéance qui compte vraiment est l'exigence de SDK de l'App Store. Le SDK de Xcode 26 est devenu obligatoire pour les soumissions le 28 avril 2026. Si Apple répète ce schéma, le SDK de Xcode 27 deviendra obligatoire vers avril 2027, et c'est à ce moment-là que la prise en charge de macOS 11 ou d'iOS 14 dans une application App Store cessera d'être possible par la voie normale.

Les chiffres, officiellement

La page d'assistance Xcode d'Apple publie un tableau indiquant ce que chaque version de Xcode peut cibler. Voici la comparaison qui compte :

Plateforme	Xcode 26.6	Xcode 27 bêta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

Lisez-le attentivement, car le titre qui claironnerait « Xcode 27 relève le minimum » n'est vrai qu'à moitié. Pour iOS, le plancher documenté est resté à 15 pendant toute la durée de Xcode 26 et reste à 15 dans Xcode 27. Pour macOS, il progresse d'une version, de 11 à 12. Pour watchOS, de 8 à 9. Sur le papier, c'est un resserrement modeste.

Ce qui ne figure pas sur le papier, c'est que les chiffres de Xcode 26 n'ont jamais été réellement appliqués.

Ce que Xcode 26 autorisait réellement

Chaque SDK intégré à Xcode embarque un fichier de réglages qui déclare les cibles de déploiement qu'il considère comme valides. Sur notre machine, avec Xcode 26.0.1 (17A400) installé, ce fichier se trouve à :

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

Une seule commande suffit pour le lire :

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Résultat sur Xcode 26.0.1 :

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

Ainsi, alors que le tableau d'Apple indiquait « macOS 11 », le SDK indiquait « 10.13 », et Xcode vous laissait saisir 10.13 dans le champ de la cible de déploiement, vous avertissait, puis compilait quand même. Michael Tsai décrit cette pratique sans détour : les développeurs « have been able to enter older targets manually », et un grand nombre de logiciels Mac indépendants ont fait exactement cela pour garder leurs utilisateurs de High Sierra, Mojave et Catalina sur la version actuelle.

Si vous avez la bêta de Xcode 27 installée, exécutez la même commande sur son SDK (en remplaçant par Xcode-beta.app) et vous verrez le nouveau plancher. Nous n'avons pas la bêta sur cette machine, nous nous appuyons donc sur le tableau d'Apple et sur les témoignages des développeurs pour le chiffre de 12.0, plutôt que de le lire nous-mêmes dans le fichier.

De l'avertissement à l'erreur

Le diagnostic lui-même n'est pas nouveau. Le système de build d'Apple émet depuis des années le message « the range of supported deployment target versions is X to Y », sous forme d'avertissement. Ce qui change avec Xcode 27, c'est sa gravité.

Un article sur bleepingswift.com cite la forme iOS de ce message telle qu'elle apparaît dans Xcode 27 :

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

La forme macOS est le même message avec MACOSX_DEPLOYMENT_TARGET et une plage de 12.0 à 27.0.99. Il se déclenche par cible, donc une application dotée d'une extension, d'un widget et d'un bundle de tests héritant tous d'une ancienne cible l'affichera quatre fois, et corriger uniquement l'application principale ne suffit pas à débloquer le build.

Les mainteneurs de Vienna RSS sont tombés dessus le 10 juin, deux jours après la sortie de la bêta : leur cible était 10.13, cela compilait sans avertissement ni erreur sous Xcode 26, et sous Xcode 27 « it's a hard requirement (build error) ». Leur inquiétude suivante est celle que partage tout développeur Mac dans cette situation : Xcode 26 ne devrait pas être pris en charge sous macOS 27, si bien que la solution de repli « keep the old Xcode » a une date de péremption.

Ce qui a changé entre juin et la bêta 6

Le plancher macOS n'est pas resté stable pendant toute la période de bêta, et il vaut la peine de savoir quelle version de l'histoire vous avez lue.

En juin, la note de version concernant Intel disait, selon la citation reprise sur les forums Apple Developer :

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

Cela ne dit rien sur un minimum. Le résumé du premier jour de Tsai interprétait la situation ainsi : « the minimum you can target is now Big Sur (or Monterey for Apple Silicon Macs) », et le ticket de ViennaRSS parlait carrément de macOS 12. Les notes de version actuelles de la bêta 6 tranchent la question :

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. (162138432)

Même numéro de ticket, reformulé pour nommer macOS 12. La mise à jour de septembre de Tsai indique la même chose : « Xcode 27 Beta 6 documents macOS 12.0 as the minimum deployment target now ». Si votre plan de migration reposait sur Big Sur, révisez-le pour viser Monterey.

Qui est vraiment concerné

Trois groupes, par ordre décroissant de douleur.

Les applications Mac qui prennent encore en charge High Sierra jusqu'à Big Sur

C'est le groupe dont parle l'article de Tsai, et celui qui bénéficie le moins de la sympathie de la plateforme. Matthias Gansrigler-Hrad, d'Eternal Storms, l'a formulé sans détour sur Mastodon :

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

Pour ces développeurs, Xcode 27 impose un choix forcé : relever le plancher et couper l'accès aux utilisateurs de systèmes 2017-2020, ou rester sur Xcode 26 et renoncer au SDK macOS 27 et à tout ce qui en dépend.

Les applications iOS, et surtout les bibliothèques iOS en dessous de 15

Le plancher iOS d'Apple est fixé à 15 depuis Xcode 26, donc une application déjà sur 15 ne voit rien changer. Mais l'écosystème regorgeait de bibliothèques déclarant des minimums plus bas, et chacune d'elles génère désormais le diagnostic dans tout projet qui l'importe. Les trackers d'issues GitHub se sont remplis, dès la première semaine de juin, de demandes quasi identiques intitulées « Support Xcode 27: raise minimum iOS deployment target to 15 » — contre le SDK iOS de Facebook, qui déclarait .iOS(.v12) dans son Package.swift, contre Adjust, DataDog, SDWebImage et d'autres. Si vous dépendez d'un paquet dont le mainteneur n'a pas répondu, vous êtes bloqué jusqu'à ce qu'il le fasse, ou jusqu'à ce que vous forkiez le projet.

Quiconque a une ancienne cible enfouie dans une dépendance

Le cas subtil. Votre application cible 15. Un paquet Swift transitif cible 13. Xcode 27 compile ce paquet avec votre toolchain, voit 13, et fait échouer votre build. Il n'existe aucune surcharge côté consommateur dans Swift Package Manager : la conclusion de bleepingswift, qui rejoint la nôtre, est que « packages declaring older minimums in their platforms declaration require either upgrading to a newer package version or forking and updating the requirement yourself ».

L'échappatoire cachée

Elle existe, vous devez la connaître, et vous devez vous en méfier.

Ighor July, dans un billet du 24 juillet cité par Tsai, rapporte que dans la bêta de Xcode 27, « a hidden setting changed those errors back into warnings, and the compiler still produced the older targets I tested ». Il décrit ce réglage comme « undocumented, absent from the normal Xcode interface, and currently being tested only » dans une toolchain bêta. Un lecteur du billet de Tsai, Harald Striepe, le nomme :

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

C'est un réglage de build, donc il se place là où vont les réglages de build : un fichier .xcconfig attaché à la configuration, ou un réglage défini par l'utilisateur (User-Defined) ajouté en bas du panneau Build Settings de la cible. Une fois défini, la vérification de la cible de déploiement revient au comportement de Xcode 26.

Voici maintenant les réserves, et elles ne sont pas anodines.

Ce n'est pas pris en charge. Les deux tirets bas en préfixe sont la convention d'Apple pour les réglages internes. Il peut être renommé ou supprimé dans n'importe quelle bêta, y compris celle qui suit le moment où vous commencez à en dépendre.

Il rétablit l'avertissement, pas les tests. L'appréciation de Tsai sur l'ensemble de ce changement mérite d'être citée intégralement, car elle pose le cadre honnête de la situation :

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

Désactiver l'erreur vous ramène à compiler pour une cible qu'Apple ne testait déjà pas auparavant, et qu'elle ne prend désormais plus en charge explicitement. Tout ce qui était cassé sous Catalina dans Xcode 26 le restera.

Cela ne règle rien du côté de l'App Store. Ce qui nous amène à l'échéance qui compte vraiment.

La véritable échéance, c'est avril 2027

La sortie de Xcode 27 n'oblige personne à l'utiliser. L'exigence de SDK de l'App Store, si.

La page des exigences à venir d'Apple indique que depuis le 28 avril 2026, les applications envoyées à App Store Connect doivent être compilées avec Xcode 26 et les SDK 26. Apple applique la même règle à chaque nouveau SDK, chaque printemps, depuis des années : le SDK courant devient obligatoire en avril, environ sept mois après sa sortie.

Si ce schéma se confirme — et Apple n'a pas annoncé la date pour 2027, il s'agit donc d'une projection fondée sur ce schéma, pas d'un fait établi — alors à partir d'environ avril 2027, toute soumission à l'App Store devra être compilée avec le SDK de Xcode 27. À ce moment-là :

• Une application Mac App Store ne pourra plus être mise à jour avec une cible de déploiement inférieure à 12.0, car la seule toolchain acceptée par la boutique refusera de la compiler.
• Une application iOS App Store ne pourra plus être mise à jour en dessous de 15.0, pour la même raison.
• Le réglage d'échappatoire pourrait survivre ou non à la validation de l'App Store. Personne n'a rapporté l'avoir testé, et nous ne bâtirions pas une activité dessus.

En dehors de l'App Store — distribution directe avec Developer ID — rien de tout cela ne s'applique. Vous pouvez continuer à compiler avec Xcode 26 aussi longtemps que Xcode 26 tourne sur un Mac que vous possédez. Ce qui nous amène au problème suivant.

Garder Xcode 26 sous la main, et pourquoi cela cesse de fonctionner

La solution évidente consiste à installer les deux. Des outils comme xcodes permettent de garder facilement Xcode 26.6 aux côtés de la bêta 27 et de basculer entre les deux avec xcode-select. Pour un projet ciblant 10.13 que vous devez encore livrer cette année, c'est la bonne décision.

Elle a une date de péremption. Le tableau d'assistance d'Apple indique que Xcode 26.6 requiert « macOS Tahoe 26.2 – macOS Tahoe 26.x ». Rien n'indique qu'il tourne sous macOS 27, et la lecture de Tsai est que « using old versions of Xcode isn't a great solution because they aren't supported on Golden Gate ». Il se peut qu'il se lance ; Apple ne le corrigera pas si ce n'est pas le cas. Et il ajoute un coût plus subtil :

Swift also makes it more difficult to call newer APIs when using an older SDK.

Rester sur Xcode 26 signifie rester sur le SDK macOS 26, ce qui veut dire que les API de macOS 27 ne sont accessibles que par résolution dynamique, voire pas du tout. Pour une application en mode maintenance, cela passe. Pour tout ce que vous développez activement, c'est un étranglement lent.

Xcode 27 lui-même est réservé à Apple Silicon

Il s'agit d'un changement distinct, qui arrive dans la même version et se mêle facilement à l'histoire de la cible de déploiement ; autant préciser clairement lequel est lequel.

Les notes de version sont sans ambiguïté : « Xcode 27 will only install and run on Apple silicon Macs ». Le binaire est exclusivement en arm64, comme l'a confirmé sur les forums un propriétaire de MacBook Pro Intel, après que la mention « requires macOS Tahoe 26.4 or later » des notes de version lui avait laissé croire le contraire — Tahoe tourne sur une poignée de Mac Intel, pas Xcode 27.

Le SDK reste Universal. Vous pouvez toujours compiler des tranches x86_64 et des binaires Universal depuis Xcode 27 ; il faut simplement le faire sur Apple Silicon. C'est une exigence matérielle pour le développeur, pas une restriction de distribution pour l'application.

L'autre changement Intel : Universal n'est plus la valeur par défaut à partir de 27.0

Un dernier point lié à Intel dans les notes de la bêta 6, classé sous « Intel Deprecation », que la plupart des articles ont passé sous silence :

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. (161837535)

C'est logique — macOS 27 ne tourne sur aucun Mac Intel, donc une cible exclusivement 27.0 n'a aucune machine Intel sur laquelle s'exécuter — mais cela a un effet de bord. Rosetta est toujours présent dans macOS 27, et la note développeur du 1er septembre d'Apple a réaffirmé que la version 27 en est la dernière édition. Une application exclusivement 27.0 qui abandonne x86_64 par défaut ne peut plus non plus tourner sous Rosetta sur Apple Silicon, ce qui ne compte que si vous distribuiez un hôte de plug-in exclusivement Intel ou quelque chose de similaire. Ajoutez explicitement x86_64 à ARCHS si vous en avez besoin.

Un troisième plancher que personne ne mentionne : libc++ à 11.0

Enfoui dans la même liste de dépréciations : « The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0 ». C'est un plancher différent, plus bas que le plancher de 12.0 imposé par le système de build, et il s'applique au runtime C++ auquel vous vous liez plutôt qu'à la cible de déploiement que vous déclarez. En pratique, cela ne se manifeste que si vous avez contourné la vérification du système de build — avec le réglage caché, par exemple — et que vous ciblez encore 10.15 ou une version antérieure avec du code C++. C'est alors libc++ lui-même qui devient le prochain obstacle.

Corriger le problème : les dépendances

Pour vos propres cibles, la correction se résume à un chiffre dans un champ de texte. Pour les dépendances :

CocoaPods. Ajoutez un hook post_install qui réécrit la cible de déploiement de chaque pod à la valeur plancher, puis relancez pod install et nettoyez le dossier de build. La version de ce hook proposée par bleepingswift a la forme standard ; l'essentiel est qu'elle s'applique à tous les pods, pas seulement à ceux qui se plaignent aujourd'hui.

Swift Package Manager. Aucune surcharge n'existe. Vos options sont : passer à une version du paquet qui a relevé son platforms ; ouvrir ou soutenir l'issue existante ; ou forker le projet, modifier Package.swift, et pointer votre projet vers ce fork jusqu'à ce que l'amont rattrape son retard. Vérifiez d'abord le tracker d'issues — pour les principaux SDK, quelqu'un a déposé la demande dès la première semaine de juin, et une pull request y est généralement déjà attachée.

Frameworks vendorisés et XCFrameworks. Ils portent leur propre minimum dans leur Info.plist et leurs commandes de chargement Mach-O. Xcode 27 ne refuse pas de lier un ancien framework binaire, mais l'éditeur de liens signalera l'incompatibilité de version, et le comportement sur l'ancienne cible correspond exactement à ce qui a été testé — c'est-à-dire rien.

Ce que signifie « honnête » ici

Il vaut la peine de s'arrêter un instant sur la manière dont Tsai pose le problème, car cela change ce contre quoi vous devriez être en colère.

Xcode 26 ne prenait pas en charge macOS 10.13. Il vous permettait de saisir 10.13, il générait du code, et Apple n'a pas testé que les frameworks du SDK 26 se comportaient correctement sur un système d'exploitation de 2017. Les développeurs qui publiaient ces builds faisaient leur propre assurance qualité face à un OS qu'Apple avait laissé derrière lui, et, la plupart du temps, cela fonctionnait, parce que les frameworks sont rétrocompatibles par conception. Mais « la plupart du temps » faisait tout le travail dans cette phrase, et chaque année, l'écart entre le SDK et la cible s'élargissait.

Xcode 27 fait de la plage documentée la plage réelle. C'est une perte pour les utilisateurs de vieux Mac et pour les développeurs qui les servaient. Ce n'est pas la perte de quelque chose qu'Apple avait un jour promis.

La complication réglementaire

Un dernier fil à tirer. Le 26 août, Tsai a rassemblé des commentaires sur le Cyber Resilience Act de l'UE, dont les principales obligations entrent en vigueur le 11 décembre 2027 et qui exige des mises à jour de sécurité pendant au moins cinq ans. Un lecteur identifié comme Frederik a soulevé l'interaction avec l'App Store :

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

C'est exactement le mécanisme que décrit cet article. L'App Store n'a qu'une seule version courante par application. Si le SDK de Xcode 27 devient obligatoire et que votre plancher passe à macOS 12, les utilisateurs de macOS 11 conservent le dernier build qu'ils ont reçu, pour toujours, sans aucune mise à jour de sécurité. Que le CRA considère cela comme une obligation du développeur, d'Apple, ou de personne, est une question pour les juristes ; le fait technique est que le modèle de distribution d'Apple n'a aucun mécanisme de branche, et Xcode 27 est sur le point de rendre cela visible à beaucoup plus de développeurs.

Liste de contrôle pour la migration

Pour une application Mac avec une ancienne cible, dans l'ordre :

1. Faites l'inventaire de vos utilisateurs réels. Si vos statistiques indiquent que personne n'est en dessous de macOS 12, il s'agit d'un changement d'une ligne et d'une note de version. La plupart des applications sont dans ce cas.
2. Réglez la cible de déploiement sur 12.0 (macOS) ou 15.0 (iOS) sur chaque cible, y compris les extensions, les helpers et les tests. Compilez avec la bêta de Xcode 27 et éliminez chaque occurrence du diagnostic.
3. Auditez vos dépendances à la recherche de déclarations platforms et de podspecs en dessous du plancher. Forkez ce qui doit l'être.
4. Tranchez le sort des irréductibles. Si vous devez réellement continuer à livrer aux utilisateurs de 10.13-11.0, planifiez un dernier build sur Xcode 26 avant avril 2027, distribuez-le en dehors de l'App Store ou comme version héritée figée, et annoncez-le publiquement.
5. N'expédiez pas le réglage caché en production, sauf si vous avez vous-même testé le résultat sur l'ancien OS et que vous acceptez que ce réglage puisse disparaître dans la prochaine bêta.
6. Si vous ciblez exclusivement 27.0, vérifiez ARCHS. Vous venez peut-être d'abandonner x86_64 sans vous en rendre compte.

Résolution des problèmes courants

L'erreur persiste après avoir relevé la cible de l'application

Une autre cible du projet conserve encore l'ancienne valeur. Sélectionnez le projet (et non une cible) dans le navigateur, vérifiez la cible de déploiement au niveau du projet, puis chaque cible et chaque bundle de tests. Les widgets et les extensions d'application sont les coupables habituels.

L'erreur nomme un paquet dont je ne dépends pas directement

Une dépendance transitive. Utilisez swift package show-dependencies (ou le graphe de paquets de Xcode) pour trouver qui l'introduit, puis mettez à jour ce paquet intermédiaire ou forkez la feuille en question.

xcodebuild en ligne de commande échoue mais l'interface graphique de Xcode compile

Vérifiez quelle toolchain la ligne de commande utilise : xcode-select -p. Il se peut que vous ayez l'interface graphique sur 26 et la ligne de commande sur 27, ou l'inverse.

J'ai activé le drapeau caché et cela n'a rien changé

Le drapeau doit être visible du système de build au niveau où s'exécute la vérification — un xcconfig au niveau du projet est l'endroit le plus sûr. S'il n'est défini que sur une seule cible, les autres cibles continueront à générer l'erreur. Si cela ne change toujours rien, la bêta que vous utilisez l'a peut-être supprimé.

Mes runners CI sont sous Intel

Xcode 27 ne s'installera pas dessus. C'est une migration matérielle, pas un problème de configuration. Les fournisseurs hébergés sont passés aux runners Apple Silicon depuis un certain temps déjà ; les Mac mini Intel auto-hébergés sont désormais en fin de vie pour les builds utilisant la toolchain actuelle.

FAQ

Xcode 27 relève-t-il le minimum iOS ?

Pas sur le papier — le tableau d'Apple indique iOS 15 depuis Xcode 26. Ce qui change, c'est l'application de la règle : les cibles en dessous de 15, qui compilaient avec un avertissement dans Xcode 26, échouent dans Xcode 27.

Quel est le minimum macOS dans Xcode 27 ?

macOS 12 Monterey, selon la page d'assistance Xcode d'Apple et les notes de version de la bêta 6. Plus tôt dans le cycle de bêta, la note avait été lue comme désignant Big Sur ; cette lecture est désormais dépassée.

Puis-je encore compiler des applications Universal (Intel + Apple Silicon) ?

Oui, depuis un Mac Apple Silicon. Le SDK macOS 27 prend en charge le back-deployment Universal jusqu'à macOS 12 et versions ultérieures. Le seul cas où x86_64 disparaît par défaut est une cible réglée sur 27.0 ou plus récent.

Quand dois-je passer à Xcode 27 ?

Pour la distribution directe, jamais — tant que vous disposez d'un Mac capable de faire tourner Xcode 26. Pour l'App Store, lorsqu'Apple rendra le SDK 27 obligatoire, ce qui, selon le schéma établi, se situerait vers avril 2027. Apple n'a pas annoncé cette date.

Le réglage caché est-il sûr pour les builds destinés à l'App Store ?

Inconnu. Personne n'a rapporté de soumission compilée avec ce réglage, et il s'agit d'un drapeau interne non documenté. Considérez-le comme un outil pour les builds locaux et les branches héritées, pas pour votre pipeline de release.

Conclusion

Le changement de cible de déploiement dans Xcode 27 est une modification minime aux conséquences durables. Apple n'a pas beaucoup relevé le plancher — une version sur macOS, aucune sur iOS — mais elle a cessé de faire semblant que ce plancher était optionnel, et une décennie de logiciels Mac indépendants s'est construite sur cette fiction. L'erreur de build que vous obtenez aujourd'hui est facile à corriger si vos utilisateurs sont sur des systèmes modernes, et impossible à corriger proprement s'ils ne le sont pas.

Sachez dans quel cas vous êtes. Si vous livrez encore à macOS 11 ou antérieur, la fenêtre qu'il vous reste est Xcode 26 sur un Mac qui le fait encore tourner, et elle se referme pour les applications App Store dans environ sept mois. Si ce n'est pas votre cas, relevez le chiffre, corrigez les dépendances, vérifiez ARCHS si vous êtes exclusivement en 27, et passez à autre chose — Apple a enfin documenté ce qu'elle allait de toute façon finir par faire.

À lire aussi : auditez vos applications Intel avant la fin de Rosetta, la date limite de compatibilité Intel de macOS 27, résoudre une configuration de développement macOS Tahoe, et les meilleurs outils de développement Mac de l'année.