Xcode 27 verwandelt alte Deployment-Targets in Build-Fehler. Hier ist die Zeile.

Öffnen Sie ein Mac-App-Projekt, das seit Jahren sauber baut, wechseln Sie zur Xcode-27-Beta, drücken Sie auf Build – und alles stoppt:

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.

In Xcode 26 war dieser Satz eine gelbe Warnung, über die man einfach hinwegscrollen konnte. In Xcode 27 ist es ein roter Fehler, und der Build wird nicht fortgesetzt. Das ist die gesamte Änderung – und sie ist zugleich kleiner und größer, als sie klingt: kleiner, weil Apples Dokumentation seit Jahren eine Untergrenze von macOS 11 und iOS 15 behauptet; größer, weil Xcode dies nie durchgesetzt hat und eine ganze Reihe ausgelieferter Apps stillschweigend darauf angewiesen ist.

Dieser Artikel legt dar, was Xcode 27 tatsächlich durchsetzt (auf Basis von Apples eigenen Tabellen und Release Notes), was Xcode 26 tatsächlich erlaubte (basierend auf dem SDK auf unserer eigenen Festplatte), wen es betrifft, die undokumentierte Einstellung, die den Fehler wieder in eine Warnung verwandelt, und warum die eigentlich entscheidende Frist nicht die Veröffentlichung von Xcode 27 ist, sondern die SDK-Anforderung des App Store im kommenden Frühjahr.

Wichtigste Erkenntnisse

• Die von Xcode 27 unterstützten Deployment-Targets sind macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27, laut Apples Xcode-Support-Seite für Beta 6. Darunter schlägt der Build fehl.
• Xcode 26 dokumentierte macOS 11 als Untergrenze, akzeptierte in Wirklichkeit aber 10.13. Wir haben die Settings-Datei des macOS-26.0-SDKs geprüft: 34 gültige Deployment-Targets, beginnend bei 10.13. Xcode 27 schließt diese Lücke, indem der dokumentierte Bereich zum durchgesetzten Bereich wird.
• Die macOS-Untergrenze verschob sich während der Beta-Phase. Im Juni sprach Apples Hinweis von Universal-Rückwärtskompatibilität „bis einschließlich macOS 27"; Entwickler lasen das als Big Sur. Der Hinweis zu Beta 6 spricht von „macOS 12 und neuer". Planen Sie mit Monterey, nicht mit Big Sur.
• Es gibt eine undokumentierte Hintertür, __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO, die den Fehler Berichten zufolge wieder in eine Warnung verwandelt. Sie wird nicht offiziell unterstützt, kann jederzeit verschwinden und ändert nichts daran, dass Apple diese Targets nicht testet.
• Die eigentlich entscheidende Frist ist die SDK-Anforderung des App Store. Das SDK von Xcode 26 wurde am 28. April 2026 für Einreichungen verpflichtend. Wiederholt Apple dieses Muster, wird das SDK von Xcode 27 etwa im April 2027 verpflichtend – und ab diesem Zeitpunkt ist es über den normalen Kanal nicht mehr möglich, in einer App-Store-App macOS 11 oder iOS 14 zu unterstützen.

Die Zahlen, offiziell

Apples Xcode-Support-Seite veröffentlicht eine Tabelle, für welche Systeme jede Xcode-Version bauen kann. Das ist der Vergleich, auf den es ankommt:

Plattform	Xcode 26.6	Xcode 27 Beta 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

Lesen Sie genau hin, denn die Schlagzeile „Xcode 27 hebt die Untergrenze an" ist nur halb wahr. Bei iOS lag die dokumentierte Untergrenze während der gesamten Xcode-26-Reihe bei 15 und bleibt in Xcode 27 bei 15. Bei macOS verschiebt sie sich um eine Version, von 11 auf 12. Bei watchOS von 8 auf 9. Auf dem Papier ist das eine moderate Verschärfung.

Was nicht auf dem Papier steht: Die Zahlen von Xcode 26 wurden nie tatsächlich durchgesetzt.

Was Xcode 26 tatsächlich erlaubte

Jedes SDK in Xcode enthält eine Settings-Datei, die festlegt, welche Deployment-Targets als gültig gelten. Auf unserem Rechner, mit installiertem Xcode 26.0.1 (17A400), liegt diese Datei unter:

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

Sie mit einem einzigen Befehl auszulesen:

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], "...")
'

Ausgabe unter Xcode 26.0.1:

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

Während Apples Tabelle also „macOS 11" sagte, sagte das SDK „10.13" – und Xcode ließ Sie 10.13 in das Deployment-Target-Feld eintragen, warnte Sie und baute dann trotzdem. Michael Tsai beschreibt die Praxis unverblümt: Entwickler „konnten ältere Targets manuell eingeben", und ein Großteil unabhängiger Mac-Software tat genau das, um Nutzer von High Sierra, Mojave und Catalina auf dem aktuellen Build zu halten.

Wenn Sie die Xcode-27-Beta installiert haben, führen Sie denselben Befehl gegen deren SDK aus (ersetzen Sie dabei Xcode-beta.app), und Sie sehen die neue Untergrenze. Auf diesem Rechner steht uns die Beta nicht zur Verfügung, weshalb wir uns für die Zahl 12.0 auf Apples Tabelle und Entwicklerberichte stützen, statt sie selbst aus der Datei auszulesen.

Von der Warnung zum Fehler

Die Diagnosemeldung selbst ist nicht neu. Apples Build-System gibt seit Jahren die Meldung „the range of supported deployment target versions is X to Y" als Warnung aus. Was sich mit Xcode 27 ändert, ist ihr Schweregrad.

Ein Artikel auf bleepingswift.com zitiert die iOS-Form der Meldung, wie sie in Xcode 27 erscheint:

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

Die macOS-Variante ist dieselbe Meldung mit MACOSX_DEPLOYMENT_TARGET und einem Bereich von 12.0 bis 27.0.99. Sie tritt pro Target auf: Eine App mit einer Extension, einem Widget und einem Test-Bundle, die alle ein altes Target erben, zeigt die Meldung viermal, und allein die Hauptapp zu korrigieren, räumt den Build nicht.

Die Maintainer von Vienna RSS stießen am 10. Juni darauf, zwei Tage nach dem Erscheinen der Beta: Ihr Target lag bei 10.13, das baute unter Xcode 26 ohne Warnungen oder Fehler, und unter Xcode 27 ist es „it's a hard requirement (build error)". Ihre Folgesorge teilt jeder Mac-Entwickler in dieser Lage: Xcode 26 wird auf macOS 27 voraussichtlich nicht unterstützt, weshalb der Ausweg „die alte Xcode-Version behalten" ein Verfallsdatum hat.

Was sich zwischen Juni und Beta 6 änderte

Die macOS-Untergrenze war während der Beta-Phase nicht stabil, und es lohnt sich zu wissen, welche Version der Geschichte man gerade liest.

Im Juni lautete der Release-Note-Hinweis zu Intel, wie in den Apple Developer Forums zitiert:

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)

Das sagt nichts über eine Untergrenze aus. Tsais Zusammenfassung vom ersten Tag deutete die Lage so, dass „the minimum you can target is now Big Sur (or Monterey for Apple Silicon Macs)", und das ViennaRSS-Issue nannte direkt macOS 12. Die aktuellen Release Notes zu Beta 6 klären das:

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)

Dieselbe Issue-Nummer, umformuliert, um macOS 12 explizit zu nennen. Auch Tsais September-Update stellt dasselbe fest: „Xcode 27 Beta 6 documents macOS 12.0 as the minimum deployment target now." Wenn Ihr Migrationsplan auf Big Sur aufbaute, überarbeiten Sie ihn auf Monterey.

Wen es wirklich trifft

Drei Gruppen, in absteigender Reihenfolge des Schmerzes.

Mac-Apps, die weiterhin High Sierra bis Big Sur unterstützen

Das ist die Gruppe, um die es in Tsais Beitrag geht, und die Gruppe, der die Plattform am wenigsten Verständnis entgegenbringt. Matthias Gansrigler-Hrad von Eternal Storms brachte es auf Mastodon direkt auf den Punkt:

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

Für diese Entwickler bedeutet Xcode 27 eine Zwangswahl: entweder die Untergrenze anheben und Nutzer von Systemen aus 2017–2020 abschneiden, oder bei Xcode 26 bleiben und auf das macOS-27-SDK sowie alles, was davon abhängt, verzichten.

iOS-Apps und vor allem iOS-Bibliotheken unterhalb von 15

Apples Untergrenze für iOS liegt seit Xcode 26 bei 15, eine App, die bereits auf 15 steht, merkt also nichts. Aber das Ökosystem war voller Bibliotheken, die niedrigere Minima deklarierten, und jede einzelne erzeugt jetzt die Diagnosemeldung in jedem Projekt, das sie importiert. Die GitHub-Issue-Tracker füllten sich in der ersten Juniwoche mit nahezu identischen Anfragen unter dem Titel „Support Xcode 27: raise minimum iOS deployment target to 15" — gegen das Facebook iOS SDK, das in seiner Package.swift .iOS(.v12) deklarierte, gegen Adjust, DataDog, SDWebImage und andere. Hängen Sie von einem Paket ab, dessen Maintainer nicht reagiert hat, sind Sie blockiert, bis das geschieht oder bis Sie forken.

Wer ein altes Target tief in einer Abhängigkeit vergraben hat

Der subtile Fall. Ihre App zielt auf 15. Ein transitives Swift-Package zielt auf 13. Xcode 27 baut dieses Package mit Ihrer Toolchain, sieht die 13 und lässt Ihren Build fehlschlagen. Im Swift Package Manager gibt es keine konsumentenseitige Override-Möglichkeit: bleepingswifts Fazit, das sich mit unserem deckt, lautet, dass „packages declaring older minimums in their platforms declaration require either upgrading to a newer package version or forking and updating the requirement yourself."

Die versteckte Hintertür

Es gibt eine, und Sie sollten sie kennen und vorsichtig mit ihr umgehen.

Ighor July berichtet in einem Beitrag vom 24. Juli, den Tsai zitiert, dass in der Xcode-27-Beta „a hidden setting changed those errors back into warnings, and the compiler still produced the older targets I tested." Er beschreibt die Einstellung als „undocumented, absent from the normal Xcode interface, and currently being tested only" in einer Beta-Toolchain. Ein Leser von Tsais Beitrag, Harald Striepe, nennt sie beim Namen:

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

Das ist eine Build-Einstellung und gehört daher dorthin, wo Build-Einstellungen hingehören: in eine .xcconfig-Datei, die der Konfiguration zugeordnet ist, oder als benutzerdefinierte Einstellung (User-Defined Setting) am unteren Ende des Build-Settings-Bereichs des Targets. Setzen Sie sie, kehrt die Deployment-Target-Prüfung zum Verhalten von Xcode 26 zurück.

Nun zu den Einschränkungen, die nicht klein sind.

Sie wird nicht offiziell unterstützt. Zwei führende Unterstriche sind Apples Konvention für interne Einstellungen. Sie kann in jeder Beta umbenannt oder entfernt werden – auch in der, direkt nachdem Sie beginnen, sich darauf zu verlassen.

Sie stellt die Warnung wieder her, nicht die Tests. Tsais Einschätzung der gesamten Änderung lohnt sich im vollen Wortlaut, weil sie die ehrliche Einordnung liefert:

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.

Den Fehler abzuschalten bringt Sie zurück in einen Zustand, in dem Sie für ein Target bauen, das Apple zuvor nicht getestet hat und jetzt ausdrücklich nicht unterstützt. Was unter Catalina in Xcode 26 kaputt war, bleibt kaputt.

Sie löst das App-Store-Problem nicht. Damit kommen wir zu der Frist, auf die es wirklich ankommt.

Die eigentliche Frist ist April 2027

Die Veröffentlichung von Xcode 27 selbst zwingt niemanden, es zu nutzen. Die SDK-Anforderung des App Store schon.

Apples Seite zu kommenden Anforderungen hält fest, dass Apps, die seit dem 28. April 2026 zu App Store Connect hochgeladen werden, mit Xcode 26 und den 26er-SDKs gebaut sein müssen. Apple wendet diese Regel seit Jahren jeden Frühling auf jedes neue SDK an: Das aktuelle SDK wird im April verpflichtend, etwa sieben Monate nach seiner Veröffentlichung.

Hält sich dieses Muster — und Apple hat das Datum für 2027 nicht angekündigt, das ist also eine Hochrechnung aus dem Muster, keine feststehende Tatsache —, dann muss ab etwa April 2027 jede App-Store-Einreichung mit dem Xcode-27-SDK gebaut sein. Zu diesem Zeitpunkt gilt:

• Eine Mac-App-Store-App kann nicht mehr mit einem Deployment-Target unter 12.0 aktualisiert werden, weil die einzige vom Store akzeptierte Toolchain den Build verweigert.
• Eine iOS-App-Store-App kann aus demselben Grund nicht mehr unter 15.0 aktualisiert werden.
• Ob die Hintertür-Einstellung die App-Store-Validierung übersteht, ist offen. Niemand hat berichtet, dies getestet zu haben, und wir würden kein Geschäftsmodell darauf aufbauen.

Außerhalb des App Store — bei direkter Distribution mit Developer ID — gilt nichts davon. Sie können mit Xcode 26 weiterbauen, solange Xcode 26 auf einem Mac läuft, den Sie besitzen. Das ist das nächste Problem.

Xcode 26 behalten – und warum das aufhört zu funktionieren

Die naheliegende Abhilfe ist, beide Versionen zu installieren. Tools wie xcodes machen es einfach, Xcode 26.6 neben der 27er-Beta zu behalten und mit xcode-select zu wechseln. Für ein Projekt mit einem 10.13-Target, das Sie dieses Jahr noch ausliefern müssen, ist das die richtige Entscheidung.

Sie hat ein Ablaufdatum. Apples Support-Tabelle listet für Xcode 26.6 als Voraussetzung „macOS Tahoe 26.2 – macOS Tahoe 26.x." Nirgends steht, dass es unter macOS 27 läuft, und Tsais Einschätzung ist, dass „using old versions of Xcode isn't a great solution because they aren't supported on Golden Gate." Es mag starten; falls nicht, wird Apple es nicht reparieren. Und er fügt einen subtileren Preis hinzu:

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

Bei Xcode 26 zu bleiben bedeutet, beim macOS-26-SDK zu bleiben, was wiederum bedeutet, dass die macOS-27-APIs nur per dynamischem Lookup erreichbar sind oder gar nicht. Für eine App im Wartungsmodus ist das in Ordnung. Für alles, was Sie aktiv weiterentwickeln, ist es eine langsame Erdrosselung.

Xcode 27 selbst läuft nur auf Apple Silicon

Das ist eine eigenständige Änderung, die im selben Release landet und sich mit der Deployment-Target-Geschichte vermischt — daher hier explizit auseinandergehalten.

Die Release Notes sind eindeutig: „Xcode 27 will only install and run on Apple silicon Macs." Das Binary ist ausschließlich arm64, wie ein Besitzer eines Intel-MacBook-Pro in den Foren bestätigte, nachdem ihn die Zeile „requires macOS Tahoe 26.4 or later" in den Notes zunächst etwas anderes hatte erwarten lassen — Tahoe läuft auf einer Handvoll Intel-Macs, Xcode 27 nicht.

Das SDK bleibt Universal. Sie können aus Xcode 27 heraus weiterhin x86_64-Slices und Universal-Binaries bauen; Sie müssen es nur auf Apple Silicon tun. Das ist eine Hardware-Anforderung für den Entwickler, keine Distributionsbeschränkung für die App.

Die andere Intel-Änderung: Universal ist ab 27.0 nicht mehr Standard

Noch ein Intel-bezogener Punkt in den Beta-6-Notes, verzeichnet unter „Intel Deprecation", den die meiste Berichterstattung überging:

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)

Das ist logisch — macOS 27 läuft auf keinem Intel-Mac, ein reines 27.0-Target hat also gar keine Intel-Maschinen, auf denen es laufen könnte —, hat aber einen Nebeneffekt. Rosetta ist in macOS 27 weiterhin vorhanden, und Apples Entwicklerhinweis vom 1. September bekräftigte, dass 27 dessen letztes Release ist. Eine reine 27.0-App, die x86_64 standardmäßig fallen lässt, ist damit auch unter Rosetta auf Apple Silicon nicht mehr lauffähig — was nur relevant ist, wenn Sie einen reinen Intel-Plug-in-Host oder Ähnliches ausgeliefert haben. Fügen Sie x86_64 bei Bedarf explizit zu ARCHS hinzu.

Eine dritte Untergrenze, die niemand erwähnt: libc++ bei 11.0

Versteckt in derselben Deprecations-Liste: „The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0." Das ist eine andere, niedrigere Untergrenze als die 12.0 des Build-Systems, und sie betrifft die C++-Laufzeitbibliothek, gegen die Sie linken, nicht das von Ihnen deklarierte Deployment-Target. In der Praxis taucht sie nur auf, wenn Sie die Build-System-Prüfung umgangen haben — etwa mit der versteckten Einstellung — und mit C++-Code weiterhin auf 10.15 oder älter zielen. Dann ist libc++ selbst das Nächste, was Sie aufhält.

Die Lösung: Abhängigkeiten

Für Ihre eigenen Targets besteht die Lösung aus einer Zahl in einem Textfeld. Für Abhängigkeiten:

CocoaPods. Fügen Sie einen post_install-Hook hinzu, der das Deployment-Target jedes Pod-Targets auf die Untergrenze umschreibt, dann pod install ausführen und den Build-Ordner leeren. bleepingswifts Version des Hooks hat die Standardform; entscheidend ist, dass er auf alle Pod-Targets angewendet wird, nicht nur auf die, die heute meckern.

Swift Package Manager. Hier gibt es keine Override-Möglichkeit. Ihre Optionen: auf eine Paketversion aktualisieren, die ihre platforms bereits angehoben hat; das Issue eröffnen oder hochvoten; oder forken, Package.swift bearbeiten und Ihr Projekt auf den Fork zeigen lassen, bis Upstream nachzieht. Prüfen Sie zuerst den Issue-Tracker — bei den großen SDKs hat jemand die Anfrage in der ersten Juniwoche eingereicht, meist mit angehängtem Pull Request.

Vendored Frameworks und XCFrameworks. Diese tragen ihr eigenes Minimum in ihrer Info.plist und ihren Mach-O-Load-Commands. Xcode 27 verweigert nicht das Linken eines alten Binary-Frameworks, aber der Linker warnt vor der Versionsabweichung, und das Verhalten auf dem alten Target entspricht genau dem Stand der Tests — also keinem.

Was „ehrlich" hier bedeutet

Es lohnt sich, bei Tsais Einordnung einen Moment zu verweilen, denn sie verändert, worüber man eigentlich verärgert sein sollte.

Xcode 26 unterstützte macOS 10.13 nicht. Es erlaubte Ihnen, 10.13 einzutragen, und erzeugte Code, aber Apple testete nicht, ob sich die Frameworks im 26er-SDK auf einem Betriebssystem von 2017 korrekt verhielten. Entwickler, die solche Builds auslieferten, betrieben ihre eigene Qualitätssicherung gegen ein von Apple aufgegebenes Betriebssystem, und meistens funktionierte es, weil die Frameworks per Design abwärtskompatibel sind. Aber „meistens" leistete in diesem Satz echte Arbeit, und die Lücke zwischen SDK und Target wurde jedes Jahr größer.

Xcode 27 macht den dokumentierten Bereich zum tatsächlichen Bereich. Das ist ein Verlust für Nutzer alter Macs und für die Entwickler, die sie bedient haben. Es ist kein Verlust von etwas, das Apple je versprochen hätte.

Die regulatorische Komplikation

Noch ein Nebenstrang. Am 26. August sammelte Tsai Kommentare zum EU Cyber Resilience Act, dessen Hauptpflichten am 11. Dezember 2027 in Kraft treten und der Sicherheitsupdates für mindestens fünf Jahre vorschreibt. Ein Leser namens Frederik brachte die Wechselwirkung mit dem App Store zur Sprache:

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.

Das ist genau der Mechanismus, den dieser Artikel beschreibt. Der App Store kennt eine aktuelle Version pro App. Wird das SDK von Xcode 27 verpflichtend und steigt Ihre Untergrenze auf macOS 12, behalten Nutzer von macOS 11 für immer den letzten erhaltenen Build — ohne Sicherheitsupdates. Ob der CRA das als Pflicht des Entwicklers, von Apple oder von niemandem behandelt, ist eine Frage für Juristen; die technische Tatsache ist, dass Apples Vertriebsmodell über keinen Branch-Mechanismus verfügt, und Xcode 27 wird das für deutlich mehr Entwickler sichtbar machen.

Migrations-Checkliste

Für eine Mac-App mit altem Target, der Reihe nach:

1. Machen Sie eine Bestandsaufnahme Ihrer tatsächlichen Nutzer. Zeigt Ihre Analytics, dass niemand unter macOS 12 liegt, ist dies eine Einzeiler-Änderung plus Release Note. Die meisten Apps befinden sich in dieser Lage.
2. Setzen Sie das Deployment-Target bei jedem Target auf 12.0 (macOS) beziehungsweise 15.0 (iOS), einschließlich Extensions, Helpern und Tests. Bauen Sie mit der Xcode-27-Beta und beheben Sie jedes Auftreten der Diagnosemeldung.
3. Prüfen Sie Abhängigkeiten auf platforms-Deklarationen und Podspecs unterhalb der Untergrenze. Forken Sie, was nötig ist.
4. Entscheiden Sie über die Nachzügler. Müssen Sie wirklich weiterhin an Nutzer von 10.13–11.0 ausliefern, planen Sie einen finalen Build mit Xcode 26 vor April 2027, verteilen Sie ihn außerhalb des App Store oder als eingefrorene Legacy-Version, und kommunizieren Sie das öffentlich.
5. Liefern Sie die versteckte Einstellung nicht in Produktion aus, es sei denn, Sie haben das Ergebnis selbst auf dem alten Betriebssystem getestet und akzeptieren, dass die Einstellung in der nächsten Beta verschwinden kann.
6. Zielen Sie ausschließlich auf 27.0, prüfen Sie ARCHS. Möglicherweise haben Sie gerade unbemerkt x86_64 verloren.

Häufige Probleme beheben

Der Fehler bleibt bestehen, obwohl ich das Target der App angehoben habe

Ein anderes Target im Projekt hat noch den alten Wert. Wählen Sie im Navigator das Projekt (nicht ein Target) aus, prüfen Sie das Deployment-Target auf Projektebene, dann jedes Target und jedes Test-Bundle. Widgets und App-Extensions sind die üblichen Übeltäter.

Der Fehler nennt ein Paket, von dem ich nicht direkt abhänge

Eine transitive Abhängigkeit. Verwenden Sie swift package show-dependencies (oder Xcodes Package Graph), um herauszufinden, wer sie hereinzieht, und aktualisieren Sie dann entweder das zwischengeschaltete Paket oder forken Sie das Blattpaket.

xcodebuild von der Kommandozeile schlägt fehl, die Xcode-Oberfläche baut aber

Prüfen Sie, welche Toolchain die Kommandozeile verwendet: xcode-select -p. Möglicherweise nutzt die GUI Version 26 und die CLI Version 27, oder umgekehrt.

Ich habe das versteckte Flag gesetzt, und es hat nichts geändert

Das Flag muss dem Build-System auf der Ebene sichtbar sein, auf der die Prüfung läuft — eine xcconfig-Datei auf Projektebene ist der sicherste Ort. Ist es nur auf einem Target gesetzt, melden die übrigen Targets weiterhin den Fehler. Bleibt die Wirkung trotzdem aus, hat die Beta, die Sie nutzen, es möglicherweise entfernt.

Meine CI-Runner laufen auf Intel

Xcode 27 lässt sich dort nicht installieren. Das ist eine Hardware-Migration, kein Konfigurationsproblem. Gehostete Anbieter sind schon vor einiger Zeit auf Apple-Silicon-Runner umgestiegen; selbstgehostete Intel Mac minis sind für Builds mit der aktuellen Toolchain nun am Ende ihrer Nutzungsdauer.

FAQ

Hebt Xcode 27 das iOS-Minimum an?

Auf dem Papier nicht — Apples Tabelle nennt seit Xcode 26 iOS 15. Was sich ändert, ist die Durchsetzung: Targets unter 15, die in Xcode 26 mit einer Warnung bauten, schlagen in Xcode 27 fehl.

Was ist das macOS-Minimum in Xcode 27?

macOS 12 Monterey, laut Apples Xcode-Support-Seite und den Release Notes zu Beta 6. Früher im Beta-Zyklus wurde der Hinweis als Big Sur gelesen; diese Lesart ist überholt.

Kann ich weiterhin Universal-Apps (Intel + Apple Silicon) bauen?

Ja, von einem Apple-Silicon-Mac aus. Das macOS-27-SDK unterstützt Universal-Rückwärtskompatibilität bis macOS 12 und neuer. Der einzige Fall, in dem x86_64 standardmäßig entfällt, ist ein auf 27.0 oder neuer gesetztes Target.

Wann muss ich auf Xcode 27 umsteigen?

Für die direkte Distribution: nie — solange Sie einen Mac besitzen, auf dem Xcode 26 läuft. Für den App Store: sobald Apple das 27er-SDK verpflichtend macht, was nach dem etablierten Muster etwa April 2027 wäre. Apple hat dieses Datum nicht angekündigt.

Ist die versteckte Einstellung sicher für App-Store-Builds?

Unbekannt. Niemand hat von einer damit gebauten Einreichung berichtet, und es handelt sich um ein undokumentiertes internes Flag. Behandeln Sie es als Werkzeug für lokale Builds und Legacy-Branches, nicht für Ihre Release-Pipeline.

Fazit

Die Deployment-Target-Änderung in Xcode 27 ist eine kleine Anpassung mit langem Nachhall. Apple hat die Untergrenze nicht stark angehoben — eine Version bei macOS, keine bei iOS —, hat aber aufgehört, so zu tun, als sei die Untergrenze optional, und ein Jahrzehnt unabhängiger Mac-Software wurde auf genau dieser Fiktion aufgebaut. Der Build-Fehler, den Sie heute bekommen, lässt sich leicht beheben, wenn Ihre Nutzer auf modernen Systemen sind, und lässt sich unmöglich sauber beheben, wenn nicht.

Wissen Sie, wo Sie stehen. Liefern Sie noch an macOS 11 oder älter aus, bleibt Ihnen als Fenster Xcode 26 auf einem Mac, der es noch ausführt, und dieses Fenster schließt sich für App-Store-Apps in etwa sieben Monaten. Falls nicht: Zahl anheben, Abhängigkeiten reparieren, ARCHS prüfen, falls Sie nur auf 27.0 zielen, und weitermachen — Apple hat endlich dokumentiert, was ohnehin immer die Absicht war.

Weiterführende Lektüre: Prüfen Sie Ihre Intel-Apps, bevor Rosetta endet, die Intel-Kompatibilitätsgrenze von macOS 27, ein macOS-Tahoe-Entwicklersetup reparieren, und die besten Mac-Entwicklertools dieses Jahr.