Xcode 27 Drops Intel: What Stops and What Still Ships

Apple filed the Intel change most likely to alter a binary you already ship under New Features rather than Deprecations. The Xcode 27 release notes carry a section titled Intel Deprecation holding exactly two entries, and the one that stops a macOS app from building Universal by default sits on the New Features side.¹²

TL;DR

• Three separate changes hide behind the headline, and Apple’s own sentences keep them apart. Xcode 27 installs and runs only on Apple silicon Macs.² The macOS 27 SDK still back-deploys Universal apps to macOS 12 and later.² And ARCHS_STANDARD stops including x86_64 once a target’s macOS or DriverKit deployment target reaches 27.0.¹
• Only the third one changes what you ship, and it changes it without a diagnostic. Apple states the remedy in the same entry: “The x86_64 architecture can be added to the ARCHS build setting if this is needed.”¹
• Xcode 26.6 cannot preview the new behavior. I forced MACOSX_DEPLOYMENT_TARGET=27.0 onto a macOS-only project and ARCHS_STANDARD still resolved to arm64 x86_64.¹³
• Two audit habits manufacture wrong answers. Passing -sdk macosx made an iOS-only project report SUPPORTED_PLATFORMS = macosx and ARCHS_STANDARD = arm64 x86_64, and resolving settings at project level hid two macOS targets inside a project whose default target is iOS.¹⁴
• Across 11 of my Xcode projects holding 44 targets: 21 build for macOS, the highest macOS deployment target among them is 26.5, and not one sets ARCHS or EXCLUDED_ARCHS.¹⁴ All 51 macOS archives on disk are x86_64 arm64.¹⁴
• The end of Intel software lands in macOS 28 rather than in Xcode 27, and Apple’s sentence carries a carve-out worth reading: “All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.”¹⁰

Apple ships all of the above as beta text, in the Xcode 27 beta 4 and macOS 27 Golden Gate beta 4 release notes.³⁶

Three sentences, three different changes

Apple’s Intel Deprecation section holds two entries. Reading them as a single claim produces the wrong decision in both directions.

The deprecation entry covers the machine on your desk, and it carries no hedge: “Xcode 27 will only install and run on Apple silicon Macs.”² No build setting adjusts that. An Intel Mac stops being a machine that runs the current Xcode, and Apple’s compatibility table adds a software floor on top of the hardware one, listing macOS Tahoe 26.4 or later as the requirement for Xcode 27 beta 4.⁴

The same entry then protects the output: “The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.”² Apple’s compatibility table agrees, showing a macOS deployment range of 12 through 27 for Xcode 27 beta 4 against 11 through 26.5 for Xcode 26.6.⁴ The floor moved up exactly one release. Universal binaries survive.

And the entry closes by preserving the workflow itself: “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”²

Then the New Features entry, which is the one capable of changing a product you already ship:

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

Four details there deserve separating. Apple names two settings and no others, so IPHONEOS_DEPLOYMENT_TARGET and its siblings sit outside the rule. Apple names a threshold rather than a toolchain version, so the trigger is your own deployment target crossing 27.0. Apple says “will not build Universal by default,” which describes a default, not a prohibition. And Apple supplies the escape in the same breath, naming ARCHS as the place to put x86_64 back.

The default that changes without an error

The mechanism is ordinary, which is exactly what makes it quiet. Apple’s build settings reference describes ARCHS as “A list of the architectures for which the product will be built. This is usually set to a predefined build setting provided by the platform. If more than one architecture is specified, a universal binary will be produced.”⁵ The predefined setting is ARCHS_STANDARD, and Apple confirms the dependency elsewhere in the same reference, noting that pointer authentication “Has no effect if ARCHS has been overridden to not be based on ARCHS_STANDARD.”⁵

So a target that never mentions ARCHS inherits whatever the platform hands it. Change what the platform hands it and the product changes shape with no edit to any file under version control.

Nothing about the change produces a failure. The compiler runs, the linker runs, and the archive validates. Nothing in the toolchain treats a single-slice arm64 macOS build as an error, because it is not one. The result is a correct, signed macOS app carrying one architecture slice where it carried two. On an Apple silicon Mac, the machine every Xcode 27 developer now uses by requirement, the arm64-only build launches and behaves identically. The regression surfaces on hardware no longer in the building.

Reading the failure mode as silent is my characterization rather than Apple’s; Apple describes the default and stops. What Apple does say is that the fix is additive, and the phrasing matters for planning: x86_64 “can be added to the ARCHS build setting if this is needed.”¹ Apple leaves the judgment about need to you.

What Xcode 26.6 will and will not tell you

My machine runs Xcode 26.6 (build 17F113) on macOS 26.5.2, so no Xcode 27 behavior appears anywhere in this article.¹³ The useful question a previous toolchain can answer is whether it already behaves the new way. It does not.

Pointing xcodebuild at a macOS-only project and overriding the deployment target past the threshold Apple names leaves the architecture list untouched:¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

The first line is xcodebuild echoing the override back; the rest are resolved. The same command at 26.0 returns the identical architecture lines.¹³ Xcode 26.6 does not implement the threshold, so nobody can rehearse the change on the current toolchain; any before-and-after comparison waits for Xcode 27 on an Apple silicon Mac.

The platform scoping does reproduce today. The same project resolved against the iOS SDK returns ARCHS_STANDARD = arm64 with no x86_64 to lose, while the macOS SDK returns arm64 x86_64.¹³ Apple’s entry names macOS and DriverKit deployment targets only, and the iOS side of a multiplatform project has nothing at stake.

Auditing your own exposure without inventing it

Two habits produce confident wrong answers. I hit both.

The first is passing -sdk macosx to find out whether a project builds for macOS. The flag overrides the project’s own SDK, so Xcode answers a question about the flag rather than about the project. Asked with no override, an iOS-only browser project of mine reports its real platform; asked with -sdk macosx, the same project reports SUPPORTED_PLATFORMS = macosx and ARCHS_STANDARD = arm64 x86_64, which is pure artifact.¹⁴ Start with no -sdk at all:

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

Against my one macOS-only app, two lines come back:¹⁴

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

Read both lines, never one. That project declares SDKROOT = macosx and no SUPPORTED_PLATFORMS line at all, so a text search of project files for SUPPORTED_PLATFORMS scores it zero and skips the only macOS-only app I own.¹⁴ Resolved settings fill the gap from the SDK; grep cannot. Ignore MACOSX_DEPLOYMENT_TARGET at this stage, because Xcode supplies one regardless: three of my iOS-only projects still report a macOS deployment target, two at 26.5 and one at 26.2.¹⁴

The second habit is resolving settings at project level. xcodebuild -showBuildSettings without -target answers for one target, and a mixed project buries the rest. My Safari extension project resolved to SUPPORTED_PLATFORMS = iphoneos iphonesimulator and ARCHS_STANDARD = arm64, which reads as an iOS-only project with no Intel exposure. Enumerating its targets found four, two of them macOS, both resolving arm64 x86_64:¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

One quirk to expect: a target carrying SDKROOT = auto resolves no ARCHS_STANDARD until you name an SDK, so 15 of my 21 macOS targets print nothing on that line until the command adds -sdk macosx, at which point their projects resolve arm64 x86_64.¹⁴ Blank means unresolved, not empty.

Then stop trusting settings and read a binary. Build settings describe intent; lipo describes the artifact you actually shipped:

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

x86_64 arm64

Prefer lipo over the archive’s own metadata. Two of my archives carry no ApplicationProperties architecture list in their Info.plist whatsoever, so a plutil query against the archive returns nothing while lipo against the binary inside it returns x86_64 arm64.¹⁴ Absence in the metadata means the archive was written differently, not that the app lost a slice.

What 11 projects actually contain

I ran the audit across 11 Xcode projects holding 44 targets. Eight projects contain at least one macOS target, 21 targets build for macOS, and the exposure to the new default is zero today.¹⁴

The highest macOS deployment target in the fleet is 26.5, the lowest 13.0 on a Safari extension nobody has revisited in a while. Not one target crosses 27.0, so not one target enters the changed-default regime until somebody raises a number by hand. Zero targets set ARCHS, zero set EXCLUDED_ARCHS, and the fleet contains no .xcconfig file at all, so every architecture decision in all 44 targets comes from ARCHS_STANDARD.¹⁴

The archive evidence is stronger than the settings evidence, because archives record what actually shipped. My machine holds 79 archives built between April and July 2026. All 51 macOS archives, spanning seven distinct products, report x86_64 arm64. All 28 iOS-family archives report arm64.¹⁴ Nobody on any of those projects ever chose Universal; the default produced it, every time. That is the population Apple’s change acts on, and precisely why nobody will notice.

One honest gap: raising a deployment target to 27.0 is a deliberate act, and none of my projects has a reason to do it yet. The fleet’s clean result measures a moment, not a policy.

Where Intel software actually ends

The Xcode change concerns architectures in a build. The end of Intel software as a category sits in macOS 28, and Apple wrote it down across its Rosetta documentation and the macOS 27 release notes, which agree with each other.

Apple’s Rosetta documentation sets the timeframe directly. Rosetta “was designed to make the transition to Apple silicon easier, and will be available through macOS 27” as a general-purpose tool for Intel apps, and “Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”⁷ The macOS 27 release notes state the consequence with the same carve-out: “All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.”¹⁰ A beta-only command elsewhere in the same notes gives that carve-out a shape: sudo game-test-tool enable turns on legacy Intel game support, and Apple warns that “enabling legacy game support disables Rosetta.”¹⁵

macOS 27 spends the interval naming what will not survive. Apple’s Deprecation Information section reports that “Intel-based applications that will no longer run in macOS 28.0 now display a treatment in Get Info,” and a separate entry adds that “Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0,” including “unused Intel-based software discovered on the system.”⁸⁹

Three quieter entries matter more to anyone shipping a Mac product.

Rosetta itself stops being sticky: “If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0.”¹¹ Apple’s documentation supplies the context, noting that macOS 27 “directly integrates support for Intel binary translation, without needing to install Rosetta,” in service of Intel Linux binaries in ARM virtual machines and Intel Linux containers.⁷ Apps a user had pinned change too: applications previously set to “Open using Rosetta” now “have the application launch natively,” and Apple advises that “Any compatibility issues requiring Rosetta from the past should be re-assessed on macOS 27.”¹²

Installers change defaults: “Installer packages which specify no hostArchitecture will now default to arm64,” and Apple asks you to “Ensure any pre and post install scripts behave as intended under arm64.”¹¹ Any Mac product distributed outside the App Store inherits that one whether or not its app is Universal.

Plugin hosts carry the sharpest edge. Apple warns that “Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility,” and names the directories to check by hand, including ~/Library/Audio/Plug-Ins/, ~/Library/Printers/, and ~/Library/ColorPickers/.¹⁰ The reason a plugin can strand an otherwise native app appears in Apple’s Rosetta documentation: “The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically.”⁷ An Intel plugin therefore forces its host to run translated, converting one unmaintained component into a whole-app dependency on a facility Apple has scheduled for reduction.

Universal exists to reach Intel Macs running macOS 12 through 27, the range Apple’s compatibility table publishes for Xcode 27.⁴ Apple has dated the end of Intel software at macOS 28 and left the deployment range untouched, so a macOS team’s real question is how many of its users still run a Mac that needs the slice.

Two things I checked and did not find: neither the Xcode 27 nor the macOS 27 release notes says anything about Mac App Store Universal Purchase requirements changing, and neither one sets a calendar date for macOS 28.³⁶ Treat any date you read as inference.

FAQ

Does Xcode 27 stop me from shipping Intel apps?

No, and Apple says the opposite in the same entry that deprecates Intel Macs as development machines: “The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.”² Apple’s compatibility table confirms the range, listing macOS 12 through 27 as the deployment targets for Xcode 27 beta 4.⁴ What changes is the default. A target whose macOS deployment target reaches 27.0 stops getting x86_64 from ARCHS_STANDARD, and Apple’s stated fix is to add x86_64 to ARCHS yourself.¹ Shipping Intel becomes a choice you declare rather than one you inherit.

Will my build fail if ARCHS_STANDARD drops x86_64?

Nothing in Apple’s entry describes an error, a warning, or a diagnostic of any kind. Apple describes a default changing: targets at macOS or DriverKit 27.0 and above “will not build Universal by default.”¹ A build that compiles, links, and signs with one architecture slice instead of two is a valid build, and on the Apple silicon Mac that Xcode 27 requires you to use, the difference is invisible at runtime.² Apple states the default and leaves the consequence unwritten, so the word silent is mine rather than Apple’s. Check lipo -archs on the archived binary rather than waiting for a build log to raise the subject.

Can I test the new behavior on Xcode 26?

No. I ran the check directly on Xcode 26.6 (build 17F113): overriding MACOSX_DEPLOYMENT_TARGET to 27.0 on a macOS-only project still resolves ARCHS_STANDARD = arm64 x86_64, identical to the same command at 26.0.¹³ The previous toolchain does not implement the threshold, so no amount of build-setting experimentation on Xcode 26 previews the change. What Xcode 26.6 does reproduce is the scoping: the same project resolves ARCHS_STANDARD = arm64 against the iOS SDK and arm64 x86_64 against the macOS SDK, matching an entry that names macOS and DriverKit deployment targets and nothing else.¹¹³

Do I need an Apple silicon Mac now?

To run Xcode 27, yes, without qualification: “Xcode 27 will only install and run on Apple silicon Macs.”² Apple adds a software floor on top of the hardware one, requiring macOS Tahoe 26.4 or later for Xcode 27 beta 4.⁴ Intel development survives on older toolchains, which is how Apple frames it: “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”² Apple’s Rosetta documentation puts a boundary on that route, stating Rosetta “will be available through macOS 27” as a general-purpose tool, with a reduced subset afterward aimed at older unmaintained games.⁷

Key Takeaways

For macOS app developers: - Audit with no -sdk flag first, read SUPPORTED_PLATFORMS and SDKROOT together, and ignore MACOSX_DEPLOYMENT_TARGET when asking whether a target builds for macOS at all. Xcode writes a macOS deployment target into iOS-only projects: three of mine report one (26.5, 26.5, and 26.2) while building for no Mac.¹⁴ - Enumerate targets with xcodebuild -list before resolving settings. A project-level query on my Safari extension reported an iOS-only project and hid two macOS targets.¹⁴

For teams whose users include Intel Macs: - Decide x86_64 explicitly instead of inheriting it. Set ARCHS when you raise a macOS deployment target to 27.0, because Apple’s entry offers exactly that remedy and no warning if you skip it.¹ - Verify with lipo -archs against the archived binary, not against build settings and not against the archive’s Info.plist. Two of my archives carry no architecture metadata at all while their binaries are Universal.¹⁴

For release managers: - Separate the hardware deadline from the shipping deadline. Xcode 27 requires an Apple silicon Mac on day one; Universal output survives to macOS 12 and later, and Apple has published no calendar date for macOS 28.²⁴ - Inventory Intel plugins and installer packages, not only apps. Apple warns that Intel plugins “may not appear in Settings,” and an Intel plugin forces its entire host process to run translated.⁷¹⁰

The 27 cycle keeps hiding consequential changes in unremarkable places. The linker removal and the module-name rule break builds outright on toolchain upgrade, the @State macro breaks them at the source level, and the launch screen key blocks a submission. The Intel default breaks nothing and changes the product anyway, which makes it worth auditing before you upgrade rather than after. The full series hub is the Apple Ecosystem Series.

References