Xcode 27 Is Out: Requirements, Targets, and What Broke

Xcode 27 shipped on September 14, 2026 as build 27A266a, three days after the feed’s iOS 27.0 RC item and alongside iOS 27.0 (24A437), macOS 27.0 (26A428), and the rest of the 27 platforms; App Store Connect began accepting builds made with the 27.0 GA SDKs the same day, having taken RC-SDK builds since September 9.¹⁵ It requires macOS Tahoe 26.6 or later and an Apple silicon Mac, carries Swift 6.4 and the 27 SDKs, debugs devices running iOS 17 or later, and raises three deployment floors: macOS 12, watchOS 9, and DriverKit 21.²³ For existing projects it brings three hard failures (the @State macro, an SE-0508 source break, and the -ld64 linker flag), one dependency-scan rule that may error, one silent change to ARCHS_STANDARD, and two warnings; I run all but the scan rule below on 27A266a.²⁴⁶

TL;DR

• Dates and builds. Apple’s releases feed lists Xcode 27 (27A266a) and all six 27.0 operating systems on Monday, September 14; its “iOS 27.0 RC (24A437)” item carries a Friday, September 11 date, two days after App Store Connect began taking RC-SDK uploads, and the GA carries the same build number.¹⁵ App Store Connect’s own release notes for September 14 say you can now upload apps built with Xcode 27 for the store and for TestFlight.⁵
• Requirements and floors moved. Xcode 26.6 ran on macOS 26.2 and debugged iOS 15 devices; Xcode 27 needs macOS 26.6, runs only on Apple silicon, and debugs iOS 17, tvOS 17, and watchOS 10 or later, in the simulator as well as on hardware. Minimum deployment targets rise from macOS 11 to 12, watchOS 8 to 9, and DriverKit 20 to 21; iOS, iPadOS, and tvOS stay at 15, visionOS at 1.²³
• Three hard failures. The @State macro: Apple’s own example, an initializer that assigns a @State property carrying a declaration-site value before the other stored properties, fails with variable 'self.title' used before being initialized; a computed property with an array or dictionary literal initial value and an init accessor fails to compile when the getter comes first, a source break Apple attributes to SE-0508; and the -ld64 linker flag, which Xcode 15 documented, fails the link with ld: library 'd64' not found.²⁴⁶⁸
• Four changes that warn, may error, or say nothing. The linker ignores -ld_classic with a warning because ld64 is gone; duplicate Clang module names within one dependency scan “may report an error”; a macOS-only target set to 27.0 builds arm64 only unless you add x86_64 back, and nothing warns; and PreviewProvider carries a 27.0 deprecation with “Use #Preview instead.” while each preview modifier carries its own replacement message, none of which the compiler shows below a 27.0 deployment target.²⁴
• Apple has not released Xcode 27.1 as of September 15. Neither the releases feed nor the release-notes index lists it, and Apple’s iPhone Duo developer page still dates the 27.1 beta to “later this month”; the SDK gap described in my Duo developer post still stands.¹

What shipped on September 14?

The release notes’ Overview reads: “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.”² On this Mac, xcodebuild -version prints Xcode 27.0 Build version 27A266a and swift --version prints Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1).⁴

What does Xcode 27 require, compared with 26.6?

Apple’s compatibility table is the document to check before upgrading a build machine. The two rows, side by side:³

Two consequences hide behind those rows. Instruments now refuses devices older than iOS 17, watchOS 10, or tvOS 17, so a profiling rig built on an old iPhone stops working before any app code does.² And Apple scopes the Device Hub’s keyboard and pointer interactions with one sentence: “only supported on the following OS versions and newer: macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0.”²

The Apple silicon requirement has no workaround for the Mac you run Xcode on, and it is old news for anyone who read the Intel post in July; the GA notes keep the July wording in full: “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.”² The third sentence is the workaround for the Macs you ship to, not the one you build on.

What changed in the toolchain?

The linker. The GA notes say it in one sentence: “The ld64 linker has been removed and the -ld_classic option is no longer supported.”² What that looks like on 27A266a: the toolchain’s usr/bin contains a single linker binary, ld, which reports itself as ld-27037.1 built August 25, 2026. Passing the old flag does not fail the link. With hello.c holding the one line int main(void){return 0;}, clang hello.o -o hello_classic -Xlinker -ld_classic prints ld: warning: -ld_classic is no longer supported and will be ignored, exits 0, and writes the executable. The other spelling Apple documented in Xcode 15, -ld64, fares worse:⁸ clang hello.c -o hello_ld64 -Wl,-ld64 fails with ld: library 'd64' not found and exits 1, because the new linker reads -ld64 as -l d64, a request for a library named d64.⁴ So a project that carries -ld_classic in OTHER_LDFLAGS keeps building, with a new warning on every link, and any behavior it was buying from the old linker is gone; a project that carries -ld64 stops linking, with an error that never names the linker. My ld64 post audits where those flags came from and records both runs.

The default architectures. The Intel Deprecation section states the rule: “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.”² I reproduced it on a multiplatform project (Yawara, with SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx xros xrsimulator) with xcodebuild -showBuildSettings -sdk macosx; without the -sdk argument the project resolves no ARCHS_STANDARD at all, a wrinkle the Intel post covers. At MACOSX_DEPLOYMENT_TARGET = 26.0 the setting resolves to ARCHS_STANDARD = arm64 x86_64; at 27.0 it resolves to ARCHS_STANDARD = arm64, while ARCHS_STANDARD_64_BIT stays arm64 x86_64 in both.⁴ Nothing warns. If you ship Universal and raise the target, add x86_64 to ARCHS yourself.

The C++ standard library. “The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0,” and the notes list behavior changes under “Potentially breaking changes,” starting with multi{map,set}::find no longer necessarily returning the first matching element.² The new-feature list is long: hashing for std::chrono values, zip, std::optional<T&>, std::views::indices(n), and more.²

Dependency scanning, and the rule that can fail it. Apple says it optimized the Swift dependency scanner “to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action,” and the speed change carries a requirement: “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.”² Apple names the two shapes that trip it: “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.”² Like the linker removal, the rule fires on toolchain upgrade rather than on a deployment target; my ld64 post runs two colliding module maps through the scanner, compiles a vendored SQLite3 shim that hides the SDK module, and audits seven projects for both shapes.

What stops compiling?

The @State macro. The change lives in the iOS 27 release notes rather than the Xcode ones, and it keys off the compiler you build with, not the target you deploy to: “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.”⁶ Apple names four exceptions and gives two of them code listings; the other two get a sentence or two each: “In rare situations, the automatic inference of generic arguments of @State is less flexible with the macro implementation. Write the type with more specificity.” and “Composing @State with other property wrappers or macros is not supported.”⁶ The two with listings are the ones that catch existing code. An initializer that assigns a @State property which already has a declaration-site value: SwiftUI always discarded the assignment, and now “some such cases no longer compile.”⁶ And the private memberwise initializer the compiler synthesizes when every stored member is private: “The state macro disables this synthesized initializer. So the code above no longer compiles.”⁶ On 27A266a the first example fails as written, with error: variable 'self.title' used before being initialized on the line that assigns page, because the macro’s setter runs against self before title exists; move self.title = title above it and the same file compiles, with the @State assignment discarded as before.⁴⁶ The second example, an extension calling self.init(page: page, title: title) on a struct whose @State has no declaration-site value, compiled unchanged in my run, and the macro expansion shows the shape that lets it: the macro emits private var _page: SwiftUICore.State<StickerPage> behind a @storageRestrictions(initializes: _page) init accessor, the construct that lets a memberwise initializer take page:.⁴ Read the note as a description of shapes to check, then confirm each one on your own code. The @State macro post counts both patterns across four shipping apps; I wrote it from the beta notes in July, before this GA test, and its open question closes here as well: assigning the backing storage directly, _page = State(initialValue:) inside an initializer, compiles on 27A266a both with and without a declaration-site value.⁴

The SE-0508 break. Under 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.” A code listing follows, then the attribution: “This is a known source break from SE-0508.” The workaround, in full: “Swap the init accessor and the getter such that the init accessor is declared first.”² SE-0508 is “Array expression trailing closures,” implemented in Swift 6.4, and the proposal predicts this exact case: “If the getter is declared before the init accessor, we will now attempt to parse as a trailing closure,” adding that “init accessors are however considered for disambiguation, so swapping the accessors is sufficient to make this valid regardless of initial value used,” and that the case “does not appear in the source compatibility suite, or for internal Swift projects at Apple.”⁷ It reproduces with a nine-line struct. With the getter first, swiftc fails on the accessor line with error: initializers may only be declared within a type; move the @storageRestrictions(initializes:) init accessor above get, and the same file compiles.⁴

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

PreviewProvider. The Previews section lists one deprecation: “PreviewProvider and its family of preview modifiers.”² The SDK carries it, with one message for the protocol and a different one for each modifier. In the iOS 27 SDK’s SwiftUI interface, public protocol PreviewProvider sits under @available(anyAppleOS, deprecated: 27.0, message: "Use #Preview instead."); previewLayout says “Use #Preview(traits: .sizeThatFitsLayout) or .fixedLayout(width:height:) instead.”; previewDisplayName says “Use #Preview(“name”) instead.”; previewInterfaceOrientation says “Use #Preview(traits: .landscapeLeft) or other orientation traits instead.”; previewDevice says “Use the device picker in Xcode’s canvas.”; and previewContext, with the PreviewContext and PreviewContextKey protocols, says “Use #Preview with a Widget timeline provider or entries instead.”⁴ Two facts decide whether you ever see those messages. The compiler compares a deprecation version against the deployment target, so the modifiers warn only in a target whose minimum is 27.0: a file that uses previewLayout, previewDisplayName, and previewDevice produced three warnings at -target arm64-apple-ios27.0-simulator and none at 17.0 or 26.0. And PreviewProvider itself never warns, for a different reason. The SDK declares it with @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) directly above the anyAppleOS deprecation, and in my probe a protocol carrying that pair produced no warning for a conformance or a use as a parameter type at a 27.0 target, while the same protocol deprecated with @available(iOS, deprecated: 27.0) alone, or with the anyAppleOS form alone, warned on both; the modifiers carry only the anyAppleOS deprecation on their own declarations (the extension SwiftUICore.View that holds them carries the introduced attribute, and that inherited form does not suppress the warning), which is why they warn and the protocol does not.⁴ At any shipping deployment target the build log is silent either way, so search for PreviewProvider and the modifiers and move to #Preview, which the canvas now renders in grids per argument through the new #Preview(arguments:) syntax.²⁴

System’s new stat(). The System library now provides Swift APIs for stat, lstat, fstat, and fstatat, with a Stat type and FilePath.stat() instance methods.² The notes list as fixed a conflict where an extension calling an unqualified stat() collided with the new methods; if you added the Darwin. qualification while that conflict was live, it can stay.²

Address Sanitizer, the other direction. “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.” The workaround is Xcode 26.5 or later, which matters for teams that keep an older Xcode on the CI box while devices update to 27.0.²

What changed in the IDE and the tools?

• Interface Builder builds without a simulator. A new compilation mode, 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.”²
• Simulators boot faster, and reboot. “The simulator runtimes now contain a pre-built dyld cache. This will make first launch of a simulator much faster,” and simctl gains a reboot command.² One known issue survives, in Apple’s words: “Some simulator runtimes are not completely deleted when removed, re-appearing after a reboot.”²
• devicectl JSON is at version 5. xcrun devicectl --version reports 642.16 and list devices --json-output writes "jsonVersion": 5; Apple deprecates the hardwareProperties, deviceProperties, and connectionProperties fields in favor of a properties dictionary, and any result that still contains them carries a _deprecationNotice.²⁴
• StoreKit testing. The StoreKit configuration UI can define offer codes, you can configure subscription bundles for local testing, and the Transaction Manager can exercise purchases with offer codes off-device.²
• Organizer. An Insights Overview “summarizes high-impact performance regressions,” and a Hitches metric replaces the Scrolling metric.²
• Coding assistant. Google Gemini joins the model list, and “Planning with agents is now first class in Xcode,” with plans as editable Markdown artifacts you approve before the agent proceeds; my coding-agents post covers the workflow from the beta, and the GA notes list a Markdown editor for exactly those artifacts.²
• Localization. Agents can translate String Catalog entries, and exporting localizations now extracts NSLocalizedString and similar macros from header files.²
• Icon Composer. The notes call it Icon Composer 2.0, “a new sharper rendering mode for upcoming 2027 operating systems”; the bundle inside 27A266a reports version 27.0.²⁴
• Testing. A test plan can set how Xcode treats a target app crash during UI testing, from off to fatal failure, and swift test gains --maximum-repetitions with --repeat-until [pass|fail] plus a failure summary at the end.²
• Debugging. With bridging headers, LLDB “can now directly import explicitly built Swift modules and PCH from DerivedData,” and a language swift task tree command lists Swift concurrency tasks.²

What I would do this week

1. Read the compatibility rows before touching CI: macOS 26.6 on the build Macs, Apple silicon only, iOS 17 as the oldest test device, and whichever of macOS 12, watchOS 9, or DriverKit 21 your product falls under.²³
2. Grep for -ld_classic and -ld64 and remove both; the linker ignores the first with a warning on every link and fails outright on the second. While you are in the build settings, look for hand-authored module.modulemap files that redeclare an SDK module, the shape Apple names for the unique-module-name rule.²⁴
3. If you set any macOS or DriverKit target to 27.0 and ship Intel, set ARCHS explicitly; ARCHS_STANDARD alone gives you arm64, which I reproduced for macOS and Apple states for both.²⁴
4. Search for PreviewProvider, previewLayout, previewDisplayName, and previewDevice, and follow each annotation’s own message: the protocol to #Preview, previewLayout to #Preview(traits: .sizeThatFitsLayout) or .fixedLayout(width:height:), previewDisplayName to #Preview("name"), and previewDevice to the device picker in the canvas. The modifiers warn only at a 27.0 deployment target and the PreviewProvider conformance never warns at any target, so a shipping target’s build log stays silent.⁴
5. Build once with Xcode 27 and read two diagnostics: variable 'self.title' used before being initialized on an initializer that assigns a @State property that already carries a declaration-site value before the other stored properties, which the @State macro post walks through, and initializers may only be declared within a type on properties with an array or dictionary literal initial value and an init accessor, where you move the accessor above the getter.²⁴⁶
6. Upload a TestFlight build with the 27 SDKs now that App Store Connect accepts them, and keep the launch screen rule and the UIKit scene mandate in mind, since both bind an app the moment it links against 27.⁵⁶

FAQ

When did Xcode 27 come out?

Monday, September 14, 2026, as build 27A266a, on the same day as iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0, and watchOS 27.0; the feed dates its iOS 27.0 RC (24A437) item September 11, two days after App Store Connect began taking RC-SDK builds.¹⁵

What macOS does Xcode 27 require?

macOS Tahoe 26.6 or later on an Apple silicon Mac. It does not install or run on Intel Macs. It runs on macOS 27.0, which shipped the same day.²³

What are the minimum deployment targets in Xcode 27?

iOS 15, iPadOS 15, tvOS 15, watchOS 9, visionOS 1, macOS 12, and DriverKit 21. Compared with Xcode 26.6, watchOS rose from 8, macOS from 11, and DriverKit from 20.³

Does Xcode 27 still build Universal Mac apps?

Yes, back to macOS 12, but not by default once a target’s MACOSX_DEPLOYMENT_TARGET is 27.0: ARCHS_STANDARD then resolves to arm64 alone, and you add x86_64 to ARCHS yourself.²⁴

Is Xcode 27.1 out?

Not as of September 15, 2026. Apple’s releases feed and the Xcode release-notes index list only Xcode 27, and Apple’s iPhone Duo developer page still lists the Xcode 27.1 beta as “Coming later this month”; the iPhone Duo SDK is not part of this release.¹

Where are the Xcode 27 release notes?

On Apple’s developer documentation site under Xcode Release Notes, one page for the release; the sections cited here are 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, and System.² The @State macro change is in the iOS and iPadOS 27 release notes instead, under SwiftUI.⁶

Sources