Xcode 27 lässt Intel fallen: Was endet und was weiterhin ausgeliefert wird

Ausgerechnet jene Intel-Änderung, die am ehesten ein bereits ausgeliefertes Binary verändert, hat Apple unter „Neue Funktionen“ abgelegt statt unter „Veraltete Funktionen“. Die Release Notes zu Xcode 27 führen einen Abschnitt mit dem Titel Intel Deprecation, der genau zwei Einträge enthält — und derjenige, der eine macOS-App standardmäßig nicht mehr Universal bauen lässt, steht auf der Seite der neuen Funktionen.¹²

Kurzfassung

• Hinter der Schlagzeile verbergen sich drei getrennte Änderungen, und Apples eigene Sätze halten sie auseinander. Xcode 27 installiert und startet nur noch auf Macs mit Apple Silicon.² Das macOS-27-SDK liefert Universal-Apps weiterhin bis zurück zu macOS 12 aus.² Und ARCHS_STANDARD enthält kein x86_64 mehr, sobald das macOS- oder DriverKit-Deployment-Target eines Targets 27.0 erreicht.¹
• Nur die dritte Änderung betrifft das, was Sie ausliefern — und sie tut es ohne jede Meldung. Die Abhilfe nennt Apple im selben Eintrag: „The x86_64 architecture can be added to the ARCHS build setting if this is needed.“¹
• Mit Xcode 26.6 lässt sich das neue Verhalten nicht erproben. Ich habe einem reinen macOS-Projekt MACOSX_DEPLOYMENT_TARGET=27.0 aufgezwungen, und ARCHS_STANDARD löste weiterhin zu arm64 x86_64 auf.¹³
• Zwei verbreitete Prüfgewohnheiten produzieren falsche Antworten. Mit -sdk macosx meldete ein reines iOS-Projekt plötzlich SUPPORTED_PLATFORMS = macosx und ARCHS_STANDARD = arm64 x86_64; und wer Einstellungen auf Projektebene auflöst, übersieht zwei macOS-Targets in einem Projekt, dessen Standard-Target iOS ist.¹⁴
• Über 11 meiner Xcode-Projekte mit 44 Targets hinweg: 21 bauen für macOS, das höchste macOS-Deployment-Target darunter ist 26.5, und kein einziges setzt ARCHS oder EXCLUDED_ARCHS.¹⁴ Alle 51 macOS-Archive auf der Platte sind x86_64 arm64.¹⁴
• Das Ende der Intel-Software fällt auf macOS 28, nicht auf Xcode 27, und Apples Satz enthält eine lesenswerte Ausnahme: „All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.“¹⁰

All das veröffentlicht Apple als Beta-Text, in den Release Notes zu Xcode 27 Beta 4 und macOS 27 Beta 4.³⁶

Drei Sätze, drei verschiedene Änderungen

Apples Abschnitt Intel Deprecation umfasst zwei Einträge. Wer sie als eine einzige Aussage liest, trifft in beide Richtungen die falsche Entscheidung.

Der Deprecation-Eintrag betrifft die Maschine auf Ihrem Schreibtisch, und er kennt keine Einschränkung: „Xcode 27 will only install and run on Apple silicon Macs.“² Daran ändert keine Build-Einstellung etwas. Ein Intel-Mac hört auf, eine Maschine zu sein, auf der das aktuelle Xcode läuft, und Apples Kompatibilitätstabelle legt über die Hardwaregrenze noch eine Softwaregrenze: Für Xcode 27 Beta 4 wird macOS Tahoe 26.4 oder neuer verlangt.⁴

Derselbe Eintrag schützt anschließend das Ergebnis: „The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.“² Apples Kompatibilitätstabelle bestätigt das und weist für Xcode 27 Beta 4 einen macOS-Deployment-Bereich von 12 bis 27 aus, gegenüber 11 bis 26.5 bei Xcode 26.6.⁴ Die Untergrenze ist um genau ein Release gestiegen. Universal Binaries überleben.

Und der Eintrag schließt damit, den Arbeitsablauf selbst zu bewahren: „Intel development is still possible with macOS versions that support Rosetta like macOS 27.“²

Dann der Eintrag unter den neuen Funktionen — jener, der ein bereits ausgeliefertes Produkt tatsächlich verändern kann:

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.¹

Vier Details darin verdienen es, auseinandergehalten zu werden. Apple nennt zwei Einstellungen und sonst keine, IPHONEOS_DEPLOYMENT_TARGET und Verwandte fallen also nicht unter die Regel. Apple nennt eine Schwelle statt einer Toolchain-Version, ausgelöst wird die Änderung also davon, dass Ihr eigenes Deployment-Target 27.0 überschreitet. Apple schreibt „will not build Universal by default“ — das beschreibt eine Voreinstellung, kein Verbot. Und im selben Atemzug liefert Apple den Ausweg mit und benennt ARCHS als den Ort, an den x86_64 zurückgehört.

Die Voreinstellung, die sich ohne Fehlermeldung ändert

Der Mechanismus ist gewöhnlich, und genau das macht ihn so leise. Apples Referenz der Build-Einstellungen beschreibt ARCHS als „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.“⁵ Die vordefinierte Einstellung ist ARCHS_STANDARD, und Apple bestätigt die Abhängigkeit an anderer Stelle derselben Referenz: Pointer Authentication bleibt wirkungslos, wenn ARCHS so überschrieben wurde, dass es nicht mehr auf ARCHS_STANDARD beruht — „Has no effect if ARCHS has been overridden to not be based on ARCHS_STANDARD.“⁵

Ein Target, das ARCHS nie erwähnt, erbt also, was die Plattform ihm reicht. Ändern Sie, was die Plattform reicht, und das Produkt ändert seine Gestalt, ohne dass eine einzige versionierte Datei angefasst würde.

Nichts an dieser Änderung erzeugt einen Fehlschlag. Der Compiler läuft, der Linker läuft, und das Archiv besteht die Validierung. Nichts in der Toolchain behandelt einen macOS-Build mit einem einzelnen arm64-Slice als Fehler, denn er ist keiner. Heraus kommt eine korrekte, signierte macOS-App mit einem Architektur-Slice, wo vorher zwei waren. Auf einem Mac mit Apple Silicon — der Maschine, die inzwischen jeder Xcode-27-Entwickler zwangsläufig benutzt — startet der reine arm64-Build und verhält sich identisch. Sichtbar wird die Regression auf Hardware, die im Haus gar nicht mehr steht.

Dass ich diesen Fehlermodus als lautlos bezeichne, ist meine Einordnung, nicht Apples; Apple beschreibt die Voreinstellung und belässt es dabei. Was Apple sehr wohl sagt: Die Behebung ist additiv, und die Formulierung ist für die Planung entscheidend — x86_64 „can be added to the ARCHS build setting if this is needed.“¹ Die Beurteilung, ob es nötig ist, überlässt Apple Ihnen.

Was Xcode 26.6 Ihnen verrät und was nicht

Auf meiner Maschine läuft Xcode 26.6 (Build 17F113) unter macOS 26.5.2, in diesem Artikel taucht also nirgends ein Verhalten von Xcode 27 auf.¹³ Die sinnvolle Frage, die eine ältere Toolchain beantworten kann, lautet, ob sie sich bereits auf die neue Weise verhält. Sie tut es nicht.

Richtet man xcodebuild auf ein reines macOS-Projekt und hebt das Deployment-Target über die von Apple genannte Schwelle, bleibt die Architekturliste unverändert:¹³

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

In der ersten Zeile gibt xcodebuild lediglich die Überschreibung zurück; die übrigen sind aufgelöst. Derselbe Befehl mit 26.0 liefert identische Architekturzeilen.¹³ Xcode 26.6 setzt die Schwelle nicht um, niemand kann die Änderung also auf der aktuellen Toolchain proben; jeder Vorher-Nachher-Vergleich muss auf Xcode 27 auf einem Mac mit Apple Silicon warten.

Was sich heute schon reproduzieren lässt, ist die Plattformbindung. Dasselbe Projekt, gegen das iOS-SDK aufgelöst, liefert ARCHS_STANDARD = arm64 und hat gar kein x86_64 zu verlieren, während das macOS-SDK arm64 x86_64 liefert.¹³ Apples Eintrag nennt ausschließlich macOS- und DriverKit-Deployment-Targets, für die iOS-Seite eines Multiplattform-Projekts steht nichts auf dem Spiel.

Die eigene Betroffenheit prüfen, ohne sie zu erfinden

Zwei Gewohnheiten erzeugen selbstbewusste Fehlurteile. Ich bin in beide getappt.

Die erste besteht darin, -sdk macosx zu übergeben, um herauszufinden, ob ein Projekt für macOS baut. Der Schalter überschreibt das projekteigene SDK, Xcode beantwortet also eine Frage über den Schalter statt über das Projekt. Ohne Überschreibung gefragt, meldet ein reines iOS-Browserprojekt von mir seine tatsächliche Plattform; mit -sdk macosx gefragt, meldet dasselbe Projekt SUPPORTED_PLATFORMS = macosx und ARCHS_STANDARD = arm64 x86_64 — ein reines Artefakt.¹⁴ Fangen Sie ganz ohne -sdk an:

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

Bei meiner einzigen reinen macOS-App kommen zwei Zeilen zurück:¹⁴

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

Lesen Sie stets beide Zeilen, nie nur eine. Jenes Projekt deklariert SDKROOT = macosx und überhaupt keine SUPPORTED_PLATFORMS-Zeile, eine Textsuche in den Projektdateien nach SUPPORTED_PLATFORMS bewertet es also mit null und überspringt ausgerechnet die einzige reine macOS-App, die ich besitze.¹⁴ Aufgelöste Einstellungen füllen die Lücke aus dem SDK; grep kann das nicht. MACOSX_DEPLOYMENT_TARGET bleibt in diesem Schritt außen vor, denn Xcode liefert immer eines mit: Drei meiner reinen iOS-Projekte melden nach wie vor ein macOS-Deployment-Target, zwei davon 26.5 und eines 26.2.¹⁴

Die zweite Gewohnheit ist, Einstellungen auf Projektebene aufzulösen. xcodebuild -showBuildSettings ohne -target antwortet für ein einziges Target, und ein gemischtes Projekt verbirgt den Rest. Mein Projekt für die Safari-Erweiterung löste zu SUPPORTED_PLATFORMS = iphoneos iphonesimulator und ARCHS_STANDARD = arm64 auf — was sich wie ein reines iOS-Projekt ohne jede Intel-Betroffenheit liest. Die Aufzählung seiner Targets förderte vier zutage, zwei davon macOS, beide mit 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

Auf eine Eigenheit sollten Sie gefasst sein: Ein Target mit SDKROOT = auto löst kein ARCHS_STANDARD auf, solange Sie kein SDK benennen — 15 meiner 21 macOS-Targets geben in dieser Zeile also nichts aus, bis der Befehl -sdk macosx ergänzt, woraufhin ihre Projekte arm64 x86_64 auflösen.¹⁴ Eine leere Ausgabe bedeutet, dass die Einstellung nicht aufgelöst wurde — nicht, dass sie leer wäre.

Dann hören Sie auf, den Einstellungen zu trauen, und lesen Sie ein Binary. Build-Einstellungen beschreiben die Absicht; lipo beschreibt das Artefakt, das Sie tatsächlich ausgeliefert haben:

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

x86_64 arm64

Bevorzugen Sie lipo gegenüber den Metadaten des Archivs. Zwei meiner Archive führen in ihrer Info.plist überhaupt keine ApplicationProperties-Architekturliste, eine plutil-Abfrage gegen das Archiv liefert also nichts, während lipo gegen das darin enthaltene Binary x86_64 arm64 zurückgibt.¹⁴ Fehlt der Eintrag in den Metadaten, wurde das Archiv anders geschrieben; verloren hat die App deswegen keinen Slice.

Was 11 Projekte tatsächlich enthalten

Ich habe die Prüfung über 11 Xcode-Projekte mit 44 Targets laufen lassen. Acht Projekte enthalten mindestens ein macOS-Target, 21 Targets bauen für macOS, und die Betroffenheit von der neuen Voreinstellung liegt heute bei null.¹⁴

Das höchste macOS-Deployment-Target der Flotte ist 26.5, das niedrigste 13.0 in einer Safari-Erweiterung, die schon eine Weile niemand mehr angefasst hat. Kein einziges Target überschreitet 27.0, keines gerät also in das Regime der geänderten Voreinstellung, bis jemand von Hand eine Zahl anhebt. Null Targets setzen ARCHS, null setzen EXCLUDED_ARCHS, und die Flotte enthält überhaupt keine .xcconfig-Datei — jede Architekturentscheidung in allen 44 Targets stammt somit aus ARCHS_STANDARD.¹⁴

Die Archive wiegen als Beleg schwerer als die Einstellungen, weil Archive festhalten, was tatsächlich ausgeliefert wurde. Auf meiner Maschine liegen 79 Archive, gebaut zwischen April und Juli 2026. Alle 51 macOS-Archive, verteilt auf sieben verschiedene Produkte, melden x86_64 arm64. Alle 28 Archive der iOS-Familie melden arm64.¹⁴ Universal hat in keinem dieser Projekte jemals jemand gewählt; die Voreinstellung hat es erzeugt, jedes Mal. Genau auf diese Grundgesamtheit wirkt Apples Änderung — und genau deshalb wird es niemandem auffallen.

Eine ehrliche Lücke bleibt: Ein Deployment-Target auf 27.0 anzuheben ist eine bewusste Handlung, und keines meiner Projekte hat bislang einen Grund dazu. Das saubere Ergebnis der Flotte misst einen Moment, keine Richtlinie.

Wo Intel-Software tatsächlich endet

Die Xcode-Änderung betrifft Architekturen innerhalb eines Builds. Das Ende der Intel-Software als Kategorie liegt in macOS 28, und Apple hat es sowohl in der Rosetta-Dokumentation als auch in den Release Notes zu macOS 27 festgehalten, die einander bestätigen.

Apples Rosetta-Dokumentation setzt den Zeitrahmen unmissverständlich. Rosetta „was designed to make the transition to Apple silicon easier, and will be available through macOS 27“ als Allzweckwerkzeug für Intel-Apps, und „Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.“⁷ Die Release Notes zu macOS 27 formulieren die Konsequenz mit derselben Ausnahme: „All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.“¹⁰ Ein Beta-Befehl an anderer Stelle derselben Notes gibt dieser Ausnahme Gestalt: sudo game-test-tool enable schaltet die Unterstützung für ältere Intel-Spiele frei, wobei Apple warnt: „enabling legacy game support disables Rosetta.“¹⁵

macOS 27 nutzt die Zwischenzeit, um zu benennen, was nicht überleben wird. Apples Abschnitt Deprecation Information meldet: „Intel-based applications that will no longer run in macOS 28.0 now display a treatment in Get Info.“ Und ein eigener Eintrag ergänzt: „Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0“, einschließlich „unused Intel-based software discovered on the system“.⁸⁹

Drei leisere Einträge wiegen für alle, die ein Mac-Produkt ausliefern, schwerer.

Rosetta selbst überdauert das Upgrade nicht mehr: „If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0.“¹¹ Den Zusammenhang liefert Apples Dokumentation mit dem Hinweis, macOS 27 „directly integrates support for Intel binary translation, without needing to install Rosetta“ — zugunsten von Intel-Linux-Binaries in ARM-VMs und Intel-Linux-Containern.⁷ Auch Apps, die ein Nutzer fest auf Rosetta gestellt hatte, ändern ihr Verhalten: Anwendungen, die zuvor auf „Open using Rosetta“ gesetzt waren, starten künftig nativ („will have the application launch natively“), und Apple rät: „Any compatibility issues requiring Rosetta from the past should be re-assessed on macOS 27.“¹²

Installer ändern ihre Voreinstellungen: „Installer packages which specify no hostArchitecture will now default to arm64.“ Und Apple fordert dazu auf, die Pre- und Post-Install-Skripte zu prüfen: „Ensure any pre and post install scripts behave as intended under arm64.“¹¹ Jedes Mac-Produkt, das außerhalb des App Store vertrieben wird, erbt das — unabhängig davon, ob seine App Universal ist.

Am schärfsten trifft es Plugin-Hosts. Apple warnt, Intel-Plugins und -Loader tauchten in den Einstellungen möglicherweise gar nicht auf und lösten auch keine Hinweise auf ihre Inkompatibilität aus — „Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility“ —, und nennt die Verzeichnisse, die man von Hand prüfen sollte, darunter ~/Library/Audio/Plug-Ins/, ~/Library/Printers/ und ~/Library/ColorPickers/.¹⁰ Warum ein Plugin eine ansonsten native App lahmlegen kann, steht in Apples Rosetta-Dokumentation: „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.“⁷ Ein Intel-Plugin zwingt seinen Host also in den Übersetzungsmodus und macht aus einer einzigen ungepflegten Komponente eine Abhängigkeit der gesamten App von einer Funktion, deren Rückbau Apple bereits terminiert hat.

Universal existiert, um Intel-Macs mit macOS 12 bis 27 zu erreichen — jenen Bereich, den Apples Kompatibilitätstabelle für Xcode 27 ausweist.⁴ Apple hat das Ende der Intel-Software auf macOS 28 datiert und den Deployment-Bereich unangetastet gelassen; die eigentliche Frage eines macOS-Teams lautet daher, wie viele seiner Nutzer noch auf einem Mac arbeiten, der den Slice braucht.

Zwei Dinge habe ich geprüft und nicht gefunden: Weder die Release Notes zu Xcode 27 noch die zu macOS 27 sagen etwas über geänderte Anforderungen an Universal Purchase im Mac App Store, und keine der beiden nennt ein Kalenderdatum für macOS 28.³⁶ Betrachten Sie jedes Datum, das Sie dazu lesen, als bloße Schlussfolgerung.

FAQ

Hindert Xcode 27 mich daran, Intel-Apps auszuliefern?

Nein — in genau dem Eintrag, der Intel-Macs als Entwicklungsmaschinen für veraltet erklärt, sagt Apple das Gegenteil: „The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.“² Apples Kompatibilitätstabelle bestätigt den Bereich und führt für Xcode 27 Beta 4 macOS 12 bis 27 als Deployment-Targets.⁴ Was sich ändert, ist die Voreinstellung. Ein Target, dessen macOS-Deployment-Target 27.0 erreicht, bekommt x86_64 nicht mehr aus ARCHS_STANDARD, und Apples ausdrückliche Abhilfe lautet, x86_64 selbst in ARCHS einzutragen.¹ Intel auszuliefern wird damit zu einer Entscheidung, die Sie ausdrücklich treffen, statt zu einer, die Sie erben.

Schlägt mein Build fehl, wenn ARCHS_STANDARD x86_64 fallen lässt?

Nichts in Apples Eintrag beschreibt einen Fehler, eine Warnung oder irgendeine Meldung. Apple beschreibt eine sich ändernde Voreinstellung: Targets ab macOS oder DriverKit 27.0 „will not build Universal by default.“¹ Ein Build, der mit einem statt zwei Architektur-Slices kompiliert, linkt und signiert, ist ein gültiger Build — und auf dem Mac mit Apple Silicon, den Xcode 27 voraussetzt, ist der Unterschied zur Laufzeit unsichtbar.² Apple benennt die Voreinstellung und lässt die Konsequenz ungeschrieben; das Wort „lautlos“ stammt daher von mir, nicht von Apple. Prüfen Sie lipo -archs am archivierten Binary, statt darauf zu warten, dass ein Build-Log das Thema anspricht.

Kann ich das neue Verhalten unter Xcode 26 testen?

Nein. Ich habe die Prüfung direkt auf Xcode 26.6 (Build 17F113) durchgeführt: Überschreibt man MACOSX_DEPLOYMENT_TARGET in einem reinen macOS-Projekt auf 27.0, löst ARCHS_STANDARD weiterhin zu arm64 x86_64 auf — identisch zum selben Befehl mit 26.0.¹³ Die vorige Toolchain setzt die Schwelle nicht um, kein noch so ausgiebiges Experimentieren mit Build-Einstellungen unter Xcode 26 nimmt die Änderung also vorweg. Was Xcode 26.6 sehr wohl reproduziert, ist die Plattformbindung: Dasselbe Projekt löst gegen das iOS-SDK zu ARCHS_STANDARD = arm64 auf und gegen das macOS-SDK zu arm64 x86_64 — passend zu einem Eintrag, der macOS- und DriverKit-Deployment-Targets nennt und sonst nichts.¹¹³

Brauche ich jetzt einen Mac mit Apple Silicon?

Um Xcode 27 auszuführen: ja, ohne Einschränkung. „Xcode 27 will only install and run on Apple silicon Macs.“² Über die Hardwaregrenze legt Apple noch eine Softwaregrenze und verlangt für Xcode 27 Beta 4 macOS Tahoe 26.4 oder neuer.⁴ Intel-Entwicklung überlebt auf älteren Toolchains, so rahmt Apple es selbst: „Intel development is still possible with macOS versions that support Rosetta like macOS 27.“² Apples Rosetta-Dokumentation setzt diesem Weg eine Grenze und hält fest, Rosetta „will be available through macOS 27“ als Allzweckwerkzeug, danach folgt nur noch eine reduzierte Teilmenge für ältere, ungepflegte Spiele.⁷

Die wichtigsten Erkenntnisse

Für macOS-App-Entwickler: - Prüfen Sie zuerst ganz ohne -sdk-Schalter, lesen Sie SUPPORTED_PLATFORMS und SDKROOT gemeinsam, und lassen Sie MACOSX_DEPLOYMENT_TARGET außen vor, wenn Sie überhaupt erst herausfinden wollen, ob ein Target für macOS baut. Xcode schreibt auch reinen iOS-Projekten ein macOS-Deployment-Target hinein: Drei meiner Projekte melden eines (26.5, 26.5 und 26.2), obwohl sie für keinen Mac bauen.¹⁴ - Zählen Sie die Targets mit xcodebuild -list auf, bevor Sie Einstellungen auflösen. Eine Abfrage auf Projektebene meldete für meine Safari-Erweiterung ein reines iOS-Projekt und verbarg zwei macOS-Targets.¹⁴

Für Teams, zu deren Nutzern Intel-Macs zählen: - Entscheiden Sie über x86_64 ausdrücklich, statt es zu erben. Setzen Sie ARCHS, wenn Sie ein macOS-Deployment-Target auf 27.0 anheben, denn Apples Eintrag bietet genau diese Abhilfe an — und keine Warnung, falls Sie sie auslassen.¹ - Verifizieren Sie mit lipo -archs am archivierten Binary, nicht anhand von Build-Einstellungen und nicht anhand der Info.plist des Archivs. Zwei meiner Archive führen überhaupt keine Architektur-Metadaten, obwohl ihre Binaries Universal sind.¹⁴

Für Release-Verantwortliche: - Trennen Sie die Hardwarefrist von der Auslieferungsfrist. Xcode 27 verlangt vom ersten Tag an einen Mac mit Apple Silicon; Universal-Ausgabe überlebt bis zurück zu macOS 12, und für macOS 28 hat Apple kein Kalenderdatum veröffentlicht.²⁴ - Inventarisieren Sie Intel-Plugins und Installer-Pakete, nicht nur Apps. Apple warnt, Intel-Plugins tauchten in den Einstellungen möglicherweise gar nicht auf („may not appear in Settings“), und ein Intel-Plugin zwingt seinen gesamten Host-Prozess in den Übersetzungsmodus.⁷¹⁰

Der 27er-Zyklus versteckt folgenreiche Änderungen beharrlich an unauffälligen Stellen. Der Wegfall des Linkers und die Regel für Modulnamen lassen Builds beim Toolchain-Wechsel unmittelbar scheitern, das @State-Makro bricht sie auf Quelltextebene, und der Launch-Screen-Schlüssel blockiert eine Einreichung. Die Intel-Voreinstellung bricht nichts und verändert das Produkt trotzdem — weshalb es sich lohnt, sie vor dem Upgrade zu prüfen statt danach. Alle Teile bündelt die Apple-Ecosystem-Reihe.

Quellen