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 every one of them 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.¹ (September 17: still no 27.1, but Xcode 27.2 beta shipped on September 16 and its notes name 27.1 as the release that carries the Duo SDK; the update below has the detail.⁹) (September 19: Xcode 27.1 beta (27A9269) shipped on September 18 with an iOS 27.1 SDK; the second update below has its notes.¹⁰) (October 1: still only that first 27.1 beta.¹¹) (October 11: Xcode 27.1 RC (27A9275) shipped on October 5, a release candidate rather than the release, and App Store Connect’s entry for that day reads “You can now upload apps built with Xcode 27.1 RC using the SDK for iOS 27.1, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0, and watchOS 27.0 for the App Store, and for internal and external testing through TestFlight.”¹²) (October 14: Xcode 27.2 beta 3 (27B5038j) shipped; Xcode 27.1 is still at its RC and Xcode 27 is still the release; the fourth update below has the beta 3 notes.¹³)

Update, September 17: the 27.2 beta came first, and 27.1 has a job

Apple’s releases feed dates a full 27.2 beta wave to Wednesday, September 16: Xcode 27.2 beta (27B5019j), iOS and iPadOS 27.2 beta (24B5084k), macOS 27.2 beta (26B5086k), tvOS 27.2 beta (24K5088l), visionOS 27.2 beta (24N5088l), and watchOS 27.2 beta (24S5086l), plus a TestFlight update, and no item in the feed names 27.1.⁹ The Xcode 27.2 beta notes explain the gap in one sentence: “The iOS SDK and simulator support for iPhone Duo will be available later this month in an upcoming release of Xcode 27.1.” So 27.1 carries the Duo SDK, 27.2 is a separate beta with its own new features, and the beta keeps the GA floor: “Xcode 27.2 beta requires a Mac running macOS Tahoe 26.6 or later.”⁹

Two entries in that beta’s notes add to this post, and the simulator-runtime Known Issue quoted below, 141290052, is still open in 27.2. Under Project Format: “Xcode now supports a JSON-based project format (.xcproj) that’s more readable, merge-friendly, and easier for coding agents to edit,” enabled in the file inspector, and “Projects using .xcproj also open in earlier versions of Xcode 27.” Under SDK, a Known Issue: “macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target,” with “unexpected behavior if this deployment target is used,” and “Mac Catalyst builds with a 27.1 or 27.2 deployment target may be unable to use newly introduced API.”⁹ Apple also added one Known Issue to the Xcode 27 notes themselves between my September 16 and September 17 fetches, under Enhanced Security: “Apps with Hardware-Checked Pointer Arithmetic Slice feature enabled cannot be uploaded to the App Store on macOS Tahoe 26.6 with Xcode automatic signing enabled.” The workaround is “Distribute with macOS 27 and Xcode 27 or use manual signing.” My arm64e.x1 post carries it.⁹ Nothing in the 27.2 beta notes touches the linker, the module-name rule, the @State macro, or the preview deprecations below; the first three live in the Xcode 27 notes and the @State entry in the iOS and iPadOS 27 notes, and the Xcode 27 entries quoted in this post read the same on September 17 as on September 15.⁶⁹

Update, September 19: Xcode 27.1 beta is out, with an iOS 27.1 SDK

Apple’s releases feed dates Xcode 27.1 beta (27A9269) to Friday, September 18, two days after the 27.2 beta wave, and the Xcode release-notes index now lists three 27 entries: Xcode 27, Xcode 27.1 Beta, and Xcode 27.2 Beta.¹⁰ The 27.1 beta notes are short. Their Overview: “Xcode 27.1 beta includes Swift 6.4 and SDKs for iOS 27.1, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27,” with the same on-device debugging floors as 27.0 and the same requirement, “a Mac running macOS Tahoe 26.6 or later.” Read that SDK list as written, with one wrinkle: the Overview puts iPadOS at 27 while App Store Connect’s line below and Apple’s API pages say iPadOS 27.1 beta, and I quote both rather than resolve it. iOS 27.1 is the release Apple’s September 16 news post says iPhone Duo “will run” when it ships on October 23.¹⁰ App Store Connect’s release notes carry the matching line for September 18, under TestFlight: “You can now submit apps built with Xcode 27.1 beta using the SDK for iOS 27.1 beta or iPadOS 27.1 beta for internal and external testing.”¹⁰ Apple also rewrote the 27.2 beta notes’ Overview between my September 17 and September 19 fetches: the sentence quoted in the update above, “The iOS SDK and simulator support for iPhone Duo will be available later this month in an upcoming release of Xcode 27.1,” is gone, and an aside in its place reads “Download Xcode 27.1 beta to get the iOS SDK and simulator support for iPhone Duo,” linking to the downloads page.¹⁰ Apple’s documentation now lists five of the iPhone Duo APIs at iOS 27.1, in beta; my Duo developer post has the names.

The 27.1 beta notes have three sections, and two of them hold Known Issues. Under Mac Catalyst: “Projects that use APIs specific to iOS 27.1 show compile errors when building for Mac Catalyst (“undeclared identifier”, “not found”, “has no member”, “cannot find”, etc).” (185924957), with the workaround “Use build-time conditionals like #if !targetEnvironment(macCatalyst) (Swift) or #if !TARGET_OS_MACCATALYST (ObjC) to isolate affected code,” and “Projects that target iOS 27.1 show no Mac Catalyst run destination available.” (187046347), with the workaround “Add a Mac Catalyst 27.0 minimum deployment in target settings.” They sit beside the 27.2 beta’s SDK Known Issue quoted in the September 17 update, 187160501, which on my reading is the same 27.1 gap seen from the macOS SDK. Under Simulator, three Known Issues: “Initial Simulator launch can take several minutes.” (187708500), “StandBy is unavailable in the iPhone Duo Simulator runtime.” (187708663), and “Running and debugging most app extensions is unavailable in the iPhone Duo Simulator runtime.” (187708767). The third section, Previews, carries one New Feature: “The canvas overrides picker now includes a Display group for previewing content on a device’s alternative display.” (182598534).¹⁰ Nothing in the 27.1 beta notes touches the linker, the module-name rule, the @State macro, or the preview deprecations below, and the Xcode 27 notes re-fetched on September 19 read the same as on September 17.¹⁰

One more date belongs in this post, from Apple’s September 9 news post on App Store submissions: “Starting April 2027, apps and games uploaded to App Store Connect need to meet the following minimum requirements: iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later,” with tvOS, visionOS, and watchOS apps held to their 27 SDKs the same way. Apple’s Upcoming Requirements page did not list it as of September 19; its newest entry is still the April 28, 2026 floor of Xcode 26 and the 26 SDKs. So the 27 SDKs this post describes become the upload floor in April 2027.¹⁰

Update, October 1: Xcode 27.2 beta 2, and no Xcode 27.0.1

Apple’s releases feed dates Xcode 27.2 beta 2 (27B5028f) to Monday, September 28, the same day as the 27.0.1 updates for iOS, iPadOS, macOS, visionOS, and watchOS. There is no Xcode 27.0.1 in the feed: Xcode 27 (27A266a) is still the release, and the text of its notes page is identical to my September 26 copy.¹¹ The beta 2 notes add a GetCodeCoverage MCP tool, list the first beta’s Device Hub input problems as fixed, and still send iPhone Duo work to Xcode 27.1 beta while listing two iPhone Duo known issues of their own and repeating two 27.1 beta entries quoted in the September 19 update, 185924957 and 182598534; the 27.2 post reads them entry by entry. The simulator-runtime issue quoted below, 141290052, is listed as fixed in 27.2 beta 2; Xcode 27 still lists it as a Known Issue.¹¹

Update, October 14: Xcode 27.2 beta 3, and the Duo aside is gone

Apple’s releases feed dates Xcode 27.2 beta 3 (27B5038j) to Wednesday, October 14, the day after the fourth 27.2 betas of iOS, iPadOS, macOS, visionOS, and watchOS (tvOS had none). Xcode 27 (27A266a) is still the release, Xcode 27.1 is still at its October 5 RC, and the text of the Xcode 27 notes page is unchanged from a copy I saved on October 11.¹³ The beta 3 notes drop the aside that sent iPhone Duo work to Xcode 27.1 beta and put nothing in its place, so nothing says the Duo SDK moved to 27.2, and on my reading the 27.1 RC stays the Duo build; add two Interface Builder fixes for the toolchain compilation mode; move the simulator-cloning issue under a Simulator Runtimes heading with a find command as its workaround; and refile the runtime-reinstall issue, 187950199, as resolved in beta 2; the 27.2 post reads them entry by entry. The simulator-runtime issue quoted below, 141290052, a different entry, is still listed as fixed in 27.2 beta 2 and still a Known Issue on the Xcode 27 page. App Store Connect’s TestFlight entry of the same day accepts builds from 27.2 beta 3 for testing, not for the store.¹³

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 do the Xcode 27 release notes contain?

The notes are one page under Xcode Release Notes on Apple’s developer documentation site, and they are long: 41 headed areas and 296 list entries, which count out to 134 new features, 134 resolved issues, 19 known issues, and 9 deprecations. Instruments carries the most entries at 60, then Device Hub at 36, Coding Intelligence at 29, Previews at 27, Previews & Playgrounds at 18, Testing at 16, and Localization at 15. The nine deprecations sit under C++ Standard Library, Device Hub, devicectl, Instruments, Intel Deprecation, Linking, On Demand Resources, Previews, and USDKit; the Linking and Intel entries are the ones that change builds, and the sections below quote them. The counts are my tally of the list items under each heading on September 26.²

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. On 27A266a the first shape reports the error Apple’s “may” anticipates: two module maps declaring module Widget on one search path make swiftc -scan-dependencies print error: redefinition of module 'Widget' on 20 runs out of 20 while exiting 0 on 20 out of 20 and resolving the module to the first -I directory; Xcode 26.6 crashed or aborted 14 of 20 runs of the same input in July. The compile still stops, because -typecheck fails 20 of 20 with the same error. The second shape, a vendored map redeclaring the SDK’s SQLite3, scans clean with nothing on stderr and shadows the SDK module silently.⁴ My ld64 post has both runs on 26.6 and on GA, plus an audit of 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.¹ (September 17: still no 27.1. Xcode 27.2 beta (27B5019j) shipped on September 16, and its release notes say the iOS SDK and simulator support for iPhone Duo “will be available later this month in an upcoming release of Xcode 27.1.”⁹) (September 19: as a beta, yes. Xcode 27.1 beta (27A9269) shipped on September 18 with an iOS 27.1 SDK and, in the 27.2 beta notes’ words, “simulator support for iPhone Duo,” and App Store Connect accepts its builds for TestFlight; there is no 27.1 release yet, and Apple’s September 16 news post says iPhone Duo “will run iOS 27.1” when it ships on October 23.¹⁰) (October 1: still only the first 27.1 beta, 27A9269.¹¹) (October 11: as a release candidate, yes. Xcode 27.1 RC (27A9275) shipped on October 5 with Swift 6.4 and the iOS 27.1 SDK, and App Store Connect takes its builds for the App Store; the releases feed lists no final Xcode 27.1 yet.¹²) (October 14: still the RC; Xcode 27.2 beta 3 shipped that day with no Xcode 27.1 release beside it.¹³)

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, and, from the September 17 update, Enhanced Security.²⁹ The @State macro change is in the iOS and iPadOS 27 release notes instead, under SwiftUI.⁶

Sources