Xcode 27 ist da: Anforderungen, Deployment Targets und was kaputtging

Xcode 27 erschien am 14. September 2026 als Build 27A266a, drei Tage nach dem iOS-27.0-RC-Eintrag im Releases-Feed und zusammen mit iOS 27.0 (24A437), macOS 27.0 (26A428) und den übrigen 27er-Plattformen; App Store Connect nimmt seit demselben Tag Builds mit den 27.0-GA-SDKs an, nachdem es RC-SDK-Builds bereits seit dem 9. September akzeptiert hatte.¹⁵ Es setzt macOS Tahoe 26.6 oder neuer und einen Mac mit Apple Silicon voraus, bringt Swift 6.4 und die 27er-SDKs mit, debuggt Geräte ab iOS 17 und hebt drei Deployment-Untergrenzen an: macOS 12, watchOS 9 und DriverKit 21.²³ Bestehende Projekte treffen auf drei harte Fehler (das @State-Makro, einen Source Break aus SE-0508 und das Linker-Flag -ld64), eine Regel im Abhängigkeitsscan, die einen Fehler melden kann, eine stille Änderung an ARCHS_STANDARD und zwei Warnungen; alles außer der Scan-Regel habe ich unten auf 27A266a nachvollzogen.²⁴⁶ {.answer-block}

Das Wichtigste in Kürze

• Termine und Builds. Apples Releases-Feed führt Xcode 27 (27A266a) und alle sechs 27.0-Betriebssysteme unter Montag, dem 14. September; sein Eintrag „iOS 27.0 RC (24A437)“ trägt das Datum Freitag, 11. September, zwei Tage nachdem App Store Connect begonnen hatte, RC-SDK-Uploads anzunehmen, und die GA trägt dieselbe Build-Nummer.¹⁵ Die eigenen Release Notes von App Store Connect zum 14. September besagen, dass Sie jetzt mit Xcode 27 gebaute Apps für den Store und für TestFlight hochladen können.⁵
• Anforderungen und Untergrenzen sind gestiegen. Xcode 26.6 lief auf macOS 26.2 und debuggte iOS-15-Geräte; Xcode 27 braucht macOS 26.6, läuft nur auf Apple Silicon und debuggt iOS 17, tvOS 17 und watchOS 10 oder neuer, im Simulator ebenso wie auf Hardware. Die Mindest-Deployment-Targets steigen von macOS 11 auf 12, watchOS 8 auf 9 und DriverKit 20 auf 21; iOS, iPadOS und tvOS bleiben bei 15, visionOS bei 1.²³
• Drei harte Fehler. Das @State-Makro: Apples eigenes Beispiel, ein Initializer, der einer @State-Property mit Startwert an der Deklaration vor den anderen gespeicherten Properties einen Wert zuweist, scheitert mit variable 'self.title' used before being initialized; eine berechnete Property mit einem Array- oder Dictionary-Literal als Startwert und einem init-Accessor kompiliert nicht mehr, wenn der Getter zuerst steht, ein Source Break, den Apple SE-0508 zuschreibt; und das Linker-Flag -ld64, das Xcode 15 dokumentierte, lässt das Linken mit ld: library 'd64' not found scheitern.²⁴⁶⁸
• Vier Änderungen, die warnen, Fehler melden können oder schweigen. Der Linker ignoriert -ld_classic mit einer Warnung, weil ld64 verschwunden ist; doppelte Clang-Modulnamen innerhalb eines Abhängigkeitsscans „may report an error“ (können einen Fehler melden); ein reines macOS-Target auf 27.0 baut nur noch arm64, sofern Sie x86_64 nicht selbst wieder hinzufügen, und nichts warnt; und PreviewProvider trägt eine 27.0-Deprecation mit „Use #Preview instead.“, während jeder Preview-Modifier seine eigene Ersatzmeldung trägt, von denen der Compiler unterhalb eines Deployment Targets von 27.0 keine einzige anzeigt.²⁴
• Apple hat Xcode 27.1 mit Stand 15. September nicht veröffentlicht. Weder der Releases-Feed noch der Release-Notes-Index führen es, und Apples Entwicklerseite zum iPhone Duo datiert die 27.1-Beta weiterhin auf „later this month“ (später in diesem Monat); die SDK-Lücke aus meinem Duo-Beitrag für Entwickler besteht weiter.¹

Was erschien am 14. September?

Der Abschnitt Overview der Release Notes lautet: „Xcode 27 includes Swift 6.4 and SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27 requires a Mac running macOS Tahoe 26.6 or later.“ (Xcode 27 enthält Swift 6.4 und die 27er-SDKs, unterstützt Debugging auf Geräten ab iOS 17, tvOS 17 und watchOS 10 sowie unter visionOS und benötigt einen Mac mit macOS Tahoe 26.6 oder neuer.)² Auf diesem Mac gibt xcodebuild -version die Zeile Xcode 27.0 Build version 27A266a aus und swift --version die Zeile Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1).⁴

Was setzt Xcode 27 voraus, verglichen mit 26.6?

Apples Kompatibilitätstabelle ist das Dokument, das Sie vor dem Upgrade eines Build-Rechners prüfen sollten. Die beiden Zeilen nebeneinander:³

Hinter diesen Zeilen verbergen sich zwei Konsequenzen. Instruments weist jetzt Geräte ab, die älter als iOS 17, watchOS 10 oder tvOS 17 sind, sodass ein Profiling-Aufbau auf einem alten iPhone den Dienst quittiert, bevor irgendeine Zeile App-Code das tut.² Und die Tastatur- und Zeigerinteraktionen des Device Hub grenzt Apple mit einem Satz ein: „only supported on the following OS versions and newer: macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0.“ (nur ab macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0 und visionOS 2.0 unterstützt.)²

Für den Mac, auf dem Xcode läuft, gibt es beim Apple-Silicon-Zwang keinen Workaround, und für alle, die den Intel-Beitrag im Juli gelesen haben, ist das nichts Neues; die GA-Notes behalten den Wortlaut vom Juli vollständig bei: „Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27.“ (Xcode 27 lässt sich nur auf Macs mit Apple Silicon installieren und ausführen; das macOS-27-SDK unterstützt Universal-Apps bis zurück zu macOS 12; Intel-Entwicklung bleibt auf macOS-Versionen mit Rosetta wie macOS 27 möglich.)² Der dritte Satz ist der Workaround für die Macs, an die Sie ausliefern, nicht für den, auf dem Sie bauen.

Was hat sich in der Toolchain geändert?

Der Linker. Die GA-Notes sagen es in einem Satz: „The ld64 linker has been removed and the -ld_classic option is no longer supported.“ (Der Linker ld64 wurde entfernt, die Option -ld_classic wird nicht mehr unterstützt.)² So sieht das auf 27A266a aus: Das usr/bin der Toolchain enthält eine einzige Linker-Binary, ld, die sich als ld-27037.1 meldet, gebaut am 25. August 2026. Das alte Flag lässt den Link nicht scheitern. Mit einer hello.c, die nur die Zeile int main(void){return 0;} enthält, gibt clang hello.o -o hello_classic -Xlinker -ld_classic die Meldung ld: warning: -ld_classic is no longer supported and will be ignored aus, endet mit 0 und schreibt die ausführbare Datei. Die andere Schreibweise, die Apple in Xcode 15 dokumentierte, -ld64, kommt schlechter weg:⁸ clang hello.c -o hello_ld64 -Wl,-ld64 scheitert mit ld: library 'd64' not found und endet mit 1, weil der neue Linker -ld64 als -l d64 liest, also als Wunsch nach einer Bibliothek namens d64.⁴ Ein Projekt mit -ld_classic in OTHER_LDFLAGS baut also weiter, mit einer neuen Warnung bei jedem Link, und jedes Verhalten, das es sich vom alten Linker erkaufte, ist weg; ein Projekt mit -ld64 linkt nicht mehr, mit einem Fehler, der den Linker nie beim Namen nennt. Mein ld64-Beitrag geht der Herkunft dieser Flags nach und protokolliert beide Läufe.

Die Standardarchitekturen. Der Abschnitt Intel Deprecation formuliert die Regel: „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.“ (Build-Targets mit einem Mindest-Deployment-Target von macOS 27.0 oder DriverKit 27.0 bauen standardmäßig nicht mehr Universal; die Build-Einstellung ARCHS_STANDARD enthält kein x86_64 mehr, sobald MACOSX_DEPLOYMENT_TARGET oder DRIVERKIT_DEPLOYMENT_TARGET >= 27.0 ist.)² Ich habe das an einem Multiplattform-Projekt (Yawara, mit SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx xros xrsimulator) per xcodebuild -showBuildSettings -sdk macosx nachvollzogen; ohne das Argument -sdk löst das Projekt überhaupt kein ARCHS_STANDARD auf, eine Eigenheit, die der Intel-Beitrag behandelt. Bei MACOSX_DEPLOYMENT_TARGET = 26.0 löst die Einstellung zu ARCHS_STANDARD = arm64 x86_64 auf; bei 27.0 zu ARCHS_STANDARD = arm64, während ARCHS_STANDARD_64_BIT in beiden Fällen arm64 x86_64 bleibt.⁴ Nichts warnt. Wenn Sie Universal ausliefern und das Target anheben, fügen Sie x86_64 selbst zu ARCHS hinzu.

Die C++-Standardbibliothek. „The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0.“ (Das minimale Deployment Target der C++-Standardbibliothek unter macOS wurde auf 11.0 angehoben.) Die Notes listen Verhaltensänderungen unter „Potentially breaking changes“ (potenziell inkompatible Änderungen), beginnend damit, dass multi{map,set}::find nicht mehr zwingend das erste passende Element liefert.² Die Liste neuer Funktionen ist lang: Hashing für std::chrono-Werte, zip, std::optional<T&>, std::views::indices(n) und mehr.²

Der Abhängigkeitsscan und die Regel, die ihn scheitern lassen kann. Apple hat den Swift-Abhängigkeitsscanner nach eigener Aussage optimiert, „to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action“ (um beim Nachschlagen von Clang-Modulen innerhalb eines Scans redundante Vorbereitung und Header-Suchen zu vermeiden), und der Geschwindigkeitsgewinn bringt eine Anforderung mit: „every Clang module reachable from a single Swift dependency-scan action must have a unique module name. If two module maps visible to the same scan declare a Clang module with the same name, the scan may report an error. Previously, the scanner may have tolerated duplicating names.“ (Jedes Clang-Modul, das ein einzelner Swift-Abhängigkeitsscan erreicht, muss einen eindeutigen Modulnamen haben; deklarieren zwei für denselben Scan sichtbare Module Maps ein Clang-Modul mit gleichem Namen, kann der Scan einen Fehler melden; früher tolerierte der Scanner doppelte Namen unter Umständen.)² Apple nennt die beiden Konstellationen, die darüber stolpern: „projects or SDKs that vend the same Clang module name from more than one location on the header search path, and vendored third-party sources that ship a module.modulemap redeclaring an SDK module.“ (Projekte oder SDKs, die denselben Clang-Modulnamen von mehr als einem Ort im Header-Suchpfad anbieten, sowie eingebettete Drittanbieter-Quellen mit einer module.modulemap, die ein SDK-Modul erneut deklariert.)² Wie die Entfernung des Linkers greift die Regel beim Toolchain-Upgrade und nicht ab einem Deployment Target; mein ld64-Beitrag schickt zwei kollidierende Module Maps durch den Scanner, kompiliert einen eingebetteten SQLite3-Shim, der das SDK-Modul verdeckt, und prüft sieben Projekte auf beide Konstellationen.

Was kompiliert nicht mehr?

Das @State-Makro. Die Änderung steht in den Release Notes zu iOS 27, nicht in denen zu Xcode, und sie hängt am Compiler, mit dem Sie bauen, nicht am Target, für das Sie ausliefern: „Xcode 27 introduces a new @State implementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new @State is implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions.“ (Xcode 27 führt eine neue @State-Implementierung ein, die die wiederholte Auswertung vermeidet; das neue Verhalten reicht bis zu den mit iOS 17 ausgerichteten Systemen zurück; das neue @State ist als Swift-Makro umgesetzt und mit wenigen Ausnahmen quellkompatibel zur Property-Wrapper-Variante.)⁶ Apple nennt vier Ausnahmen und gibt zu zweien Codelistings; die anderen beiden bekommen je ein bis zwei Sätze: „In rare situations, the automatic inference of generic arguments of @State is less flexible with the macro implementation. Write the type with more specificity.“ (In seltenen Fällen ist die automatische Ableitung generischer Argumente von @State mit dem Makro weniger flexibel; schreiben Sie den Typ genauer aus.) und „Composing @State with other property wrappers or macros is not supported.“ (Die Kombination von @State mit anderen Property Wrappern oder Makros wird nicht unterstützt.)⁶ Die beiden mit Listings sind die, die bestehenden Code erwischen. Ein Initializer, der einer @State-Property etwas zuweist, die bereits einen Wert an der Deklaration hat: SwiftUI hat die Zuweisung schon immer verworfen, und jetzt „some such cases no longer compile.“ (kompilieren manche dieser Fälle nicht mehr.)⁶ Und der private Memberwise Initializer, den der Compiler synthetisiert, wenn jedes gespeicherte Mitglied privat ist: „The state macro disables this synthesized initializer. So the code above no longer compiles.“ (Das State-Makro deaktiviert diesen synthetisierten Initializer, der gezeigte Code kompiliert daher nicht mehr.)⁶ Auf 27A266a scheitert das erste Beispiel wie geschrieben, mit error: variable 'self.title' used before being initialized in der Zeile, die page zuweist, weil der Setter des Makros gegen self läuft, bevor title existiert; verschieben Sie self.title = title darüber, und dieselbe Datei kompiliert, wobei die @State-Zuweisung wie zuvor verworfen wird.⁴⁶ Das zweite Beispiel, eine Extension, die self.init(page: page, title: title) auf einem Struct aufruft, dessen @State keinen Wert an der Deklaration hat, kompilierte in meinem Lauf unverändert, und die Makroexpansion zeigt die Form, die das erlaubt: Das Makro erzeugt private var _page: SwiftUICore.State<StickerPage> hinter einem @storageRestrictions(initializes: _page)-init-Accessor, dem Konstrukt, das einen Memberwise Initializer page: annehmen lässt.⁴ Lesen Sie die Note als Beschreibung von Mustern, die es zu prüfen gilt, und bestätigen Sie dann jedes an Ihrem eigenen Code. Der Beitrag zum @State-Makro zählt beide Muster über vier ausgelieferte Apps; ich schrieb ihn im Juli anhand der Beta-Notes, vor diesem GA-Test, und seine offene Frage schließt sich hier ebenfalls: Die direkte Zuweisung an den Speicher dahinter, _page = State(initialValue:) innerhalb eines Initializers, kompiliert auf 27A266a mit und ohne Wert an der Deklaration.⁴

Der SE-0508-Bruch. Unter Swift Compiler, Known Issues: „A computed property with both an init accessor and an array/dictionary literal initial value will no longer compile if the getter is declared before the init accessor.“ (Eine berechnete Property mit init-Accessor und einem Array- oder Dictionary-Literal als Startwert kompiliert nicht mehr, wenn der Getter vor dem init-Accessor deklariert ist.) Es folgt ein Codelisting, dann die Zuordnung: „This is a known source break from SE-0508.“ (Dies ist ein bekannter Source Break aus SE-0508.) Der Workaround im vollen Wortlaut: „Swap the init accessor and the getter such that the init accessor is declared first.“ (Tauschen Sie init-Accessor und Getter, sodass der init-Accessor zuerst deklariert ist.)² SE-0508 ist „Array expression trailing closures“ (Trailing Closures in Array-Ausdrücken), umgesetzt in Swift 6.4, und der Proposal sagt genau diesen Fall voraus: „If the getter is declared before the init accessor, we will now attempt to parse as a trailing closure.“ (Steht der Getter vor dem init-Accessor, versuchen wir jetzt, als Trailing Closure zu parsen.) Ergänzend heißt es, „init accessors are however considered for disambiguation, so swapping the accessors is sufficient to make this valid regardless of initial value used.“ (init-Accessoren werden zur Disambiguierung herangezogen, das Tauschen der Accessoren genügt also unabhängig vom Startwert.) und der Fall „does not appear in the source compatibility suite, or for internal Swift projects at Apple.“ (taucht weder in der Source-Compatibility-Suite noch in internen Swift-Projekten bei Apple auf.)⁷ Ein neunzeiliges Struct reicht zur Reproduktion. Mit dem Getter zuerst scheitert swiftc in der Accessor-Zeile mit error: initializers may only be declared within a type; verschieben Sie den init-Accessor mit @storageRestrictions(initializes:) über get, und dieselbe Datei kompiliert.⁴

struct Container {
    private var storage: [Int] = []
    var items: [Int] = [] {
        @storageRestrictions(initializes: storage)
        init(initialValue) { storage = initialValue }   // muss vor get stehen
        get { storage }
        set { storage = newValue }
    }
}

PreviewProvider. Der Abschnitt Previews führt eine Deprecation auf: „PreviewProvider and its family of preview modifiers.“ (PreviewProvider und seine Familie von Preview-Modifiern.)² Das SDK trägt sie, mit einer Meldung für das Protokoll und einer anderen für jeden Modifier. Im SwiftUI-Interface des iOS-27-SDK steht public protocol PreviewProvider unter @available(anyAppleOS, deprecated: 27.0, message: "Use #Preview instead."); previewLayout sagt „Use #Preview(traits: .sizeThatFitsLayout) or .fixedLayout(width:height:) instead.“; previewDisplayName sagt „Use #Preview("name") instead.“; previewInterfaceOrientation sagt „Use #Preview(traits: .landscapeLeft) or other orientation traits instead.“; previewDevice sagt „Use the device picker in Xcode’s canvas.“ (Verwenden Sie die Geräteauswahl im Canvas von Xcode.); und previewContext sagt zusammen mit den Protokollen PreviewContext und PreviewContextKey „Use #Preview with a Widget timeline provider or entries instead.“ (Verwenden Sie stattdessen #Preview mit einem Widget-Timeline-Provider oder Entries.)⁴ Ob Sie diese Meldungen je zu sehen bekommen, entscheiden zwei Tatsachen. Der Compiler vergleicht eine Deprecation-Version mit dem Deployment Target, die Modifier warnen also nur in einem Target, dessen Minimum 27.0 ist: Eine Datei mit previewLayout, previewDisplayName und previewDevice erzeugte drei Warnungen bei -target arm64-apple-ios27.0-simulator und keine bei 17.0 oder 26.0. Und PreviewProvider selbst warnt nie, aus einem anderen Grund. Das SDK deklariert es mit @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) direkt über der anyAppleOS-Deprecation, und in meiner Sonde erzeugte ein Protokoll mit diesem Paar bei einem 27.0-Target keine Warnung, weder für eine Konformität noch für die Verwendung als Parametertyp, während dasselbe Protokoll, nur mit @available(iOS, deprecated: 27.0) oder nur mit der anyAppleOS-Form als veraltet markiert, in beiden Fällen warnte; die Modifier tragen an ihren eigenen Deklarationen nur die anyAppleOS-Deprecation (die extension SwiftUICore.View, die sie enthält, trägt das introduced-Attribut, und diese geerbte Form unterdrückt die Warnung nicht), weshalb sie warnen und das Protokoll nicht.⁴ Bei jedem realen Deployment Target bleibt das Build-Log so oder so stumm; suchen Sie also nach PreviewProvider und den Modifiern und wechseln Sie zu #Preview, das der Canvas über die neue Syntax #Preview(arguments:) jetzt pro Argument in Rastern darstellt.²⁴

Das neue stat() in System. Die Bibliothek System bietet jetzt Swift-APIs für stat, lstat, fstat und fstatat, mit einem Typ Stat und Instanzmethoden FilePath.stat().² Die Notes führen als behoben einen Konflikt auf, bei dem eine Extension mit einem unqualifizierten stat()-Aufruf mit den neuen Methoden kollidierte; wenn Sie die Qualifikation Darwin. hinzugefügt haben, solange der Konflikt bestand, kann sie bleiben.²

Address Sanitizer, in umgekehrter Richtung. „Address Sanitizer might fail to launch on iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 when building with Xcode 26.4 or older.“ (Address Sanitizer startet unter iOS 27.0, tvOS 27.0, watchOS 27.0 und visionOS 27.0 möglicherweise nicht, wenn mit Xcode 26.4 oder älter gebaut wird.) Der Workaround ist Xcode 26.5 oder neuer, was Teams betrifft, die auf dem CI-Rechner ein älteres Xcode behalten, während die Geräte auf 27.0 aktualisieren.²

Was hat sich in der IDE und den Werkzeugen geändert?

• Interface Builder baut ohne Simulator. Ein neuer Kompilierungsmodus, toolchain, „for UIKit (Cocoa Touch) based documents. Enabled by default, toolchain allows compiling IB documents without the need to download a simulator, which is especially useful for build servers.“ (für UIKit-basierte Dokumente; standardmäßig aktiv, erlaubt er das Kompilieren von IB-Dokumenten ohne Simulator-Download, was vor allem Build-Servern hilft.)²
• Simulatoren starten schneller und lassen sich neu starten. „The simulator runtimes now contain a pre-built dyld cache. This will make first launch of a simulator much faster.“ (Die Simulator-Runtimes enthalten jetzt einen vorgebauten dyld-Cache, der erste Start eines Simulators wird dadurch deutlich schneller.) Und simctl bekommt einen Befehl reboot.² Ein bekanntes Problem überlebt, in Apples Worten: „Some simulator runtimes are not completely deleted when removed, re-appearing after a reboot.“ (Manche Simulator-Runtimes werden beim Entfernen nicht vollständig gelöscht und tauchen nach einem Neustart wieder auf.)²
• Das JSON von devicectl steht bei Version 5. xcrun devicectl --version meldet 642.16, und list devices --json-output schreibt "jsonVersion": 5; Apple markiert die Felder hardwareProperties, deviceProperties und connectionProperties zugunsten eines properties-Dictionarys als veraltet, und jedes Ergebnis, das sie noch enthält, trägt einen _deprecationNotice.²⁴
• StoreKit-Tests. Die StoreKit-Konfigurationsoberfläche kann Angebotscodes definieren, Sie können Abo-Bundles für lokale Tests konfigurieren, und der Transaction Manager kann Käufe mit Angebotscodes ohne Gerät durchspielen.²
• Organizer. Eine Insights Overview „summarizes high-impact performance regressions“ (fasst Performance-Regressionen mit großer Wirkung zusammen), und eine Metrik Hitches ersetzt die Metrik Scrolling.²
• Coding-Assistent. Google Gemini kommt in die Modellliste, und „Planning with agents is now first class in Xcode“ (Planen mit Agenten ist in Xcode jetzt ein vollwertiges Feature), mit Plänen als editierbaren Markdown-Artefakten, die Sie freigeben, bevor der Agent weitermacht; mein Beitrag zu Coding-Agenten beschreibt den Workflow aus der Beta, und die GA-Notes führen einen Markdown-Editor für genau diese Artefakte auf.²
• Lokalisierung. Agenten können Einträge im String Catalog übersetzen, und der Export von Lokalisierungen extrahiert jetzt NSLocalizedString und ähnliche Makros aus Header-Dateien.²
• Icon Composer. Die Notes nennen es Icon Composer 2.0, „a new sharper rendering mode for upcoming 2027 operating systems“ (ein neuer, schärferer Rendering-Modus für die kommenden Betriebssysteme von 2027); das Bundle in 27A266a meldet Version 27.0.²⁴
• Testing. Ein Testplan kann festlegen, wie Xcode einen Absturz der Ziel-App während UI-Tests behandelt, von aus bis fataler Fehler, und swift test bekommt --maximum-repetitions mit --repeat-until [pass|fail] sowie eine Fehlerzusammenfassung am Ende.²
• Debugging. Mit Bridging Headern gilt für LLDB: „can now directly import explicitly built Swift modules and PCH from DerivedData“ (LLDB kann jetzt explizit gebaute Swift-Module und PCH direkt aus DerivedData importieren), und ein Befehl language swift task tree listet Swift-Concurrency-Tasks auf.²

Was ich diese Woche tun würde

1. Lesen Sie die Kompatibilitätszeilen, bevor Sie CI anfassen: macOS 26.6 auf den Build-Macs, nur Apple Silicon, iOS 17 als ältestes Testgerät und je nach Produkt macOS 12, watchOS 9 oder DriverKit 21.²³
2. Greppen Sie nach -ld_classic und -ld64 und entfernen Sie beides; der Linker ignoriert das erste mit einer Warnung bei jedem Link und scheitert am zweiten komplett. Wenn Sie schon in den Build-Einstellungen sind, suchen Sie nach handgeschriebenen module.modulemap-Dateien, die ein SDK-Modul erneut deklarieren, die Konstellation, die Apple für die Regel eindeutiger Modulnamen nennt.²⁴
3. Wenn Sie ein macOS- oder DriverKit-Target auf 27.0 setzen und Intel ausliefern, setzen Sie ARCHS explizit; ARCHS_STANDARD allein liefert arm64, was ich für macOS nachvollzogen habe und Apple für beide angibt.²⁴
4. Suchen Sie nach PreviewProvider, previewLayout, previewDisplayName und previewDevice und folgen Sie der Meldung der jeweiligen Annotation: das Protokoll zu #Preview, previewLayout zu #Preview(traits: .sizeThatFitsLayout) oder .fixedLayout(width:height:), previewDisplayName zu #Preview("name") und previewDevice zur Geräteauswahl im Canvas. Die Modifier warnen nur bei einem Deployment Target von 27.0, und die PreviewProvider-Konformität warnt bei keinem Target, das Build-Log eines ausgelieferten Targets bleibt also stumm.⁴
5. Bauen Sie einmal mit Xcode 27 und achten Sie auf zwei Diagnosen: variable 'self.title' used before being initialized bei einem Initializer, der einer @State-Property mit Wert an der Deklaration vor den anderen gespeicherten Properties etwas zuweist, was der Beitrag zum @State-Makro Schritt für Schritt durchgeht, und initializers may only be declared within a type bei Properties mit einem Array- oder Dictionary-Literal als Startwert und einem init-Accessor, wo Sie den Accessor über den Getter verschieben.²⁴⁶
6. Laden Sie jetzt, da App Store Connect sie annimmt, einen TestFlight-Build mit den 27er-SDKs hoch, und behalten Sie die Launch-Screen-Regel und die UIKit-Scene-Pflicht im Blick, denn beide binden eine App in dem Moment, in dem sie gegen 27 linkt.⁵⁶

Häufige Fragen

Wann ist Xcode 27 erschienen?

Am Montag, dem 14. September 2026, als Build 27A266a, am selben Tag wie iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0 und watchOS 27.0; der Feed datiert seinen Eintrag iOS 27.0 RC (24A437) auf den 11. September, zwei Tage nachdem App Store Connect begonnen hatte, RC-SDK-Builds anzunehmen.¹⁵

Welches macOS setzt Xcode 27 voraus?

macOS Tahoe 26.6 oder neuer auf einem Mac mit Apple Silicon. Auf Intel-Macs lässt es sich weder installieren noch ausführen. Es läuft unter macOS 27.0, das am selben Tag erschien.²³

Was sind die Mindest-Deployment-Targets in Xcode 27?

iOS 15, iPadOS 15, tvOS 15, watchOS 9, visionOS 1, macOS 12 und DriverKit 21. Verglichen mit Xcode 26.6 stieg watchOS von 8, macOS von 11 und DriverKit von 20.³

Baut Xcode 27 noch Universal-Apps für den Mac?

Ja, bis zurück zu macOS 12, aber nicht mehr standardmäßig, sobald das MACOSX_DEPLOYMENT_TARGET eines Targets 27.0 ist: ARCHS_STANDARD löst dann nur noch zu arm64 auf, und Sie fügen x86_64 selbst zu ARCHS hinzu.²⁴

Ist Xcode 27.1 draußen?

Nicht mit Stand 15. September 2026. Apples Releases-Feed und der Index der Xcode Release Notes führen nur Xcode 27, und Apples Entwicklerseite zum iPhone Duo listet die Xcode-27.1-Beta weiterhin als „Coming later this month“ (kommt später in diesem Monat); das iPhone-Duo-SDK ist nicht Teil dieser Veröffentlichung.¹

Wo stehen die Release Notes zu Xcode 27?

Auf Apples Entwicklerdokumentationsseite unter Xcode Release Notes, eine Seite pro Release; die hier zitierten Abschnitte sind Overview, Linking, Intel Deprecation, Previews, Swift Compiler, Address Sanitizer, Instruments, Device Hub, devicectl, Simulator, Interface Builder, C++ Standard Library, Organizer, Coding Intelligence, Source Editor, Icon Composer, StoreKit Testing in Xcode, Localization, Testing, Swift Package Manager, Debugging und System.² Die Änderung am @State-Makro steht stattdessen in den Release Notes zu iOS und iPadOS 27, unter SwiftUI.⁶

Quellen