Xcode 27 Turns Old Deployment Targets Into Build Errors. Here Is the Line.

Open a Mac app project that has built cleanly for years, switch to the Xcode 27 beta, press build, and stop:

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

In Xcode 26 that sentence was a yellow warning you could scroll past. In Xcode 27 it is a red error and the build does not proceed. That is the whole change, and it is smaller and larger than it sounds: smaller because Apple's documentation has claimed a floor of macOS 11 and iOS 15 for years, larger because Xcode never enforced it, and a great many shipping apps quietly depend on that.

This article lays out what Xcode 27 actually enforces (from Apple's own tables and release notes), what Xcode 26 actually permitted (from the SDK on our own disk), who is affected, the undocumented setting that turns the error back into a warning, and why the deadline that matters is not Xcode 27's release but the App Store's SDK requirement next spring.

Key Takeaways

• Xcode 27's supported deployment targets are macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27, per Apple's Xcode support page for beta 6. Below those, the build fails.
• Xcode 26 documented macOS 11 as its floor but actually accepted 10.13. We checked the macOS 26.0 SDK's settings file: 34 valid deployment targets, starting at 10.13. Xcode 27 closes that gap by making the documented range the enforced range.
• The macOS floor moved during the beta. In June, Apple's note said Universal back-deployment "up to and including macOS 27"; developers read that as Big Sur. Beta 6's note says "macOS 12 and later." Plan for Monterey, not Big Sur.
• There is an undocumented escape hatch, __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO, reported to turn the error back into a warning. It is unsupported, may vanish, and does not change the fact that Apple is not testing those targets.
• The real deadline is the App Store's SDK requirement. Xcode 26's SDK became mandatory for submissions on 28 April 2026. If Apple repeats the pattern, Xcode 27's SDK becomes mandatory around April 2027, and that is when supporting macOS 11 or iOS 14 in an App Store app stops being possible through the normal channel.

The Numbers, Officially

Apple's Xcode support page publishes a table of what each Xcode version can build for. This is the comparison that matters:

Platform	Xcode 26.6	Xcode 27 beta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

Read it carefully, because the headline "Xcode 27 raises the minimum" is only half true. For iOS, the documented floor has been 15 throughout Xcode 26 and stays at 15 in Xcode 27. For macOS it moves one version, from 11 to 12. For watchOS, from 8 to 9. On paper this is a modest tightening.

What is not on paper is that the Xcode 26 numbers were never enforced.

What Xcode 26 Actually Allowed

Every SDK inside Xcode carries a settings file that declares which deployment targets it considers valid. On our machine, with Xcode 26.0.1 (17A400) installed, that file is at:

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

Reading it takes one command:

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Output on Xcode 26.0.1:

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

So while Apple's table said "macOS 11," the SDK said "10.13," and Xcode let you type 10.13 into the deployment target field, warned you, and then built. Michael Tsai describes the practice plainly: developers "have been able to enter older targets manually," and a lot of independent Mac software did exactly that to keep High Sierra, Mojave and Catalina users on the current build.

If you have the Xcode 27 beta installed, run the same command against its SDK (substitute Xcode-beta.app) and you will see the new floor. We do not have the beta on this machine, so we are relying on Apple's table and developers' reports for the 12.0 figure rather than reading it from the file ourselves.

Warning to Error

The diagnostic itself is not new. Apple's build system has emitted "the range of supported deployment target versions is X to Y" for years, as a warning. The Xcode 27 change is its severity.

A write-up on bleepingswift.com quotes the iOS form of it as it appears in Xcode 27:

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

The macOS form is the same message with MACOSX_DEPLOYMENT_TARGET and a range of 12.0 to 27.0.99. It fires per target, so an app with an extension, a widget and a test bundle that all inherit an old target will show it four times, and fixing the main app alone does not clear the build.

The Vienna RSS maintainers hit it on 10 June, two days after the beta shipped: their target was 10.13, it built without warnings or errors on Xcode 26, and on Xcode 27 "it's a hard requirement (build error)." Their follow-up concern is the one every Mac developer in this position shares: Xcode 26 is not expected to be supported on macOS 27, so the fallback of "keep the old Xcode" has a shelf life.

What Changed Between June and Beta 6

The macOS floor was not stable across the beta period, and it is worth knowing which version of the story you read.

In June, the release note about Intel read, as quoted on the Apple Developer Forums:

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

That says nothing about a minimum. Tsai's day-one summary read the situation as "the minimum you can target is now Big Sur (or Monterey for Apple Silicon Macs)," and the ViennaRSS issue said macOS 12 outright. The current beta 6 release notes resolve it:

Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

Same issue number, reworded to name macOS 12. Tsai's September update notes the same thing: "Xcode 27 Beta 6 documents macOS 12.0 as the minimum deployment target now." If your migration plan was built on Big Sur, revise it to Monterey.

Who This Actually Hits

Three groups, in decreasing order of pain.

Mac apps that still support High Sierra through Big Sur

This is the group Tsai's post is about, and the group with the least sympathy from the platform. Matthias Gansrigler-Hrad of Eternal Storms put it directly on Mastodon:

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

For these developers, Xcode 27 is a forced choice: raise the floor and cut off users on 2017–2020 systems, or stay on Xcode 26 and give up the macOS 27 SDK and everything that depends on it.

iOS apps and, especially, iOS libraries below 15

Apple's floor for iOS has been 15 since Xcode 26, so an app already on 15 sees nothing. But the ecosystem was full of libraries declaring lower minimums, and each one now generates the diagnostic in every project that imports it. The GitHub issue trackers filled up in the first week of June with near-identical requests titled "Support Xcode 27: raise minimum iOS deployment target to 15" — against the Facebook iOS SDK, which declared .iOS(.v12) in its Package.swift, against Adjust, DataDog, SDWebImage and others. If you depend on a package whose maintainer has not responded, you are blocked until they do or until you fork.

Anyone with an old target buried in a dependency

The subtle case. Your app targets 15. A transitive Swift package targets 13. Xcode 27 builds that package with your toolchain, sees 13, and fails your build. There is no consumer-side override in Swift Package Manager: bleepingswift's conclusion, which matches ours, is that "packages declaring older minimums in their platforms declaration require either upgrading to a newer package version or forking and updating the requirement yourself."

The Hidden Escape Hatch

There is one, and you should know about it and be careful with it.

Ighor July, writing on 24 July in a piece Tsai quotes, reports that in the Xcode 27 beta "a hidden setting changed those errors back into warnings, and the compiler still produced the older targets I tested." He describes the setting as "undocumented, absent from the normal Xcode interface, and currently being tested only" in a beta toolchain. A reader on Tsai's post, Harald Striepe, names it:

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

That is a build setting, so it goes where build settings go: an .xcconfig file attached to the configuration, or a User-Defined setting added at the bottom of the target's Build Settings pane. Set it, and the deployment-target check reverts to the Xcode 26 behaviour.

Now the caveats, which are not small.

It is unsupported. Two leading underscores are Apple's convention for internal settings. It can be renamed or removed in any beta, including the one after you start relying on it.

It restores the warning, not the testing. Tsai's assessment of the whole change is worth quoting in full, because it is the honest frame:

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

Turning the error off returns you to building for a target Apple was not testing before and is now explicitly not supporting. Whatever broke on Catalina in Xcode 26 will still be broken.

It does not address the App Store. Which brings us to the deadline that actually matters.

The Real Deadline Is April 2027

Xcode 27 shipping does not force anyone to use it. The App Store's SDK requirement does.

Apple's upcoming requirements page records that since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 and the 26 SDKs. Apple has applied the same rule to each new SDK every spring for years: the current SDK becomes mandatory in April, roughly seven months after it ships.

If that pattern holds — and Apple has not announced the 2027 date, so this is a projection from the pattern, not a fact — then from around April 2027 every App Store submission must be built with the Xcode 27 SDK. At that point:

• A Mac App Store app cannot be updated with a deployment target below 12.0, because the only toolchain the store accepts refuses to build it.
• An iOS App Store app cannot be updated below 15.0, for the same reason.
• The escape-hatch setting may or may not survive App Store validation. Nobody has reported testing this, and we would not build a business on it.

Outside the App Store — direct distribution with Developer ID — none of this applies. You can keep building with Xcode 26 for as long as Xcode 26 runs on a Mac you own. Which is the next problem.

Keeping Xcode 26 Around, and Why That Stops Working

The obvious mitigation is to install both. Tools like xcodes make it easy to keep Xcode 26.6 alongside the 27 beta and switch with xcode-select. For a project on a 10.13 target that you still need to ship this year, that is the right call.

It has an expiry date. Apple's support table lists Xcode 26.6 as requiring "macOS Tahoe 26.2 – macOS Tahoe 26.x." Nothing says it runs on macOS 27, and Tsai's reading is that "using old versions of Xcode isn't a great solution because they aren't supported on Golden Gate." It may launch; Apple will not fix it if it does not. And he adds a subtler cost:

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

Staying on Xcode 26 means staying on the macOS 26 SDK, which means the macOS 27 APIs are reachable only through dynamic lookup or not at all. For a maintenance-mode app, fine. For anything you are actively developing, it is a slow strangulation.

Xcode 27 Itself Is Apple Silicon Only

This is a separate change that lands in the same release and gets tangled with the deployment-target story, so to be explicit about which is which.

The release notes are unambiguous: "Xcode 27 will only install and run on Apple silicon Macs." The binary is arm64-only, as an Intel MacBook Pro owner confirmed on the forums after the "requires macOS Tahoe 26.4 or later" line in the notes led him to expect otherwise — Tahoe runs on a handful of Intel Macs, Xcode 27 does not.

The SDK is still Universal. You can build x86_64 slices and Universal binaries from Xcode 27; you just have to do it on Apple silicon. This is a hardware requirement for the developer, not a distribution restriction on the app.

The Other Intel Change: Universal Is No Longer the Default at 27.0

One more Intel-related item in the beta 6 notes, filed under "Intel Deprecation," which most coverage skipped:

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed. (161837535)

This is logical — macOS 27 does not run on any Intel Mac, so a 27.0-only target has no Intel machines to run on — but it has a side effect. Rosetta is still present in macOS 27, and Apple's 1 September developer note reaffirmed that 27 is its final release. A 27.0-only app that drops x86_64 by default is no longer runnable under Rosetta on Apple silicon either, which only matters if you were shipping an Intel-only plug-in host or similar. Add x86_64 to ARCHS explicitly if you need it.

A Third Floor Nobody Mentions: libc++ at 11.0

Buried in the same Deprecations list: "The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0." That is a different, lower floor than the 12.0 build-system floor, and it applies to the C++ runtime you link against rather than the deployment target you declare. In practice it only surfaces if you have gone around the build-system check — with the hidden setting, say — and are still targeting 10.15 or earlier with C++ code. Then libc++ itself is the next thing that stops you.

Fixing It: Dependencies

For your own targets the fix is a number in a text field. For dependencies:

CocoaPods. Add a post_install hook that rewrites every pod target's deployment target to the floor, then pod install and clean the build folder. bleepingswift's version of the hook is the standard shape; the point is that it applies to all pod targets, not just the ones that complain today.

Swift Package Manager. No override exists. Your options are: update to a package version that has raised its platforms; open or upvote the issue; or fork, edit Package.swift, and point your project at the fork until upstream catches up. Check the issue tracker first — for the major SDKs, someone filed the request in the first week of June and a pull request is usually attached.

Vendored frameworks and XCFrameworks. These carry their own minimum in their Info.plist and Mach-O load commands. Xcode 27 does not refuse to link an old binary framework, but the linker will warn about the version mismatch, and behaviour on the old target is exactly as tested, which is to say not.

What "Honest" Means Here

It is worth sitting with Tsai's framing for a moment, because it changes what you should be angry about.

Xcode 26 did not support macOS 10.13. It permitted you to type 10.13, and it emitted code, and Apple did not test that the frameworks in the 26 SDK behaved correctly on a 2017 operating system. Developers who shipped those builds were doing their own QA against an OS Apple had left behind, and mostly it worked, because the frameworks are backward compatible by design. But "mostly" was doing real work in that sentence, and every year the gap between the SDK and the target widened.

Xcode 27 makes the documented range the real range. That is a loss for users of old Macs and for the developers who served them. It is not a loss of something Apple ever promised.

The Regulatory Wrinkle

One more thread. On 26 August Tsai collected commentary on the EU Cyber Resilience Act, whose main obligations take effect on 11 December 2027 and which requires security updates for at least five years. A reader identified as Frederik raised the App Store interaction:

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

That is exactly the mechanism this article describes. The App Store has one current version per app. If Xcode 27's SDK becomes mandatory and your floor rises to macOS 12, users on macOS 11 keep the last build they received, forever, with no security updates. Whether the CRA treats that as the developer's obligation, Apple's, or nobody's is a question for lawyers; the technical fact is that Apple's distribution model has no branch mechanism, and Xcode 27 is about to make that visible to a lot more developers.

Migration Checklist

For a Mac app with an old target, in order:

1. Inventory your real users. If your analytics say nobody is below macOS 12, this is a one-line change and a release note. Most apps are here.
2. Set the deployment target to 12.0 (macOS) or 15.0 (iOS) on every target, including extensions, helpers and tests. Build with Xcode 27 beta and clear every instance of the diagnostic.
3. Audit dependencies for platforms declarations and podspecs below the floor. Fork what you must.
4. Decide about the stragglers. If you genuinely need to keep shipping to 10.13–11.0 users, plan a final build on Xcode 26 before April 2027, distribute it outside the App Store or as a frozen legacy version, and say so publicly.
5. Do not ship the hidden setting to production unless you have tested the result on the old OS yourself and accept that the setting may disappear in the next beta.
6. If you target 27.0 only, check ARCHS. You may have just dropped x86_64 without noticing.

Troubleshooting Common Issues

The error persists after I raised the app's target

Another target in the project still has the old value. Select the project (not a target) in the navigator, check the project-level deployment target, then each target and each test bundle. Widgets and app extensions are the usual culprits.

The error names a package I do not directly depend on

A transitive dependency. Use swift package show-dependencies (or Xcode's package graph) to find who pulls it in, then either update that intermediate package or fork the leaf.

xcodebuild from the command line fails but the Xcode GUI builds

Check which toolchain the command line is using: xcode-select -p. You may have the GUI on 26 and the CLI on 27, or vice versa.

I set the hidden flag and it made no difference

The flag has to be visible to the build system at the level where the check runs — project-level xcconfig is the safest place. If it is set only on one target, the other targets still error. If it still does nothing, the beta you are on may have removed it.

My CI runners are Intel

Xcode 27 will not install on them. This is a hardware migration, not a configuration problem. Hosted providers moved to Apple silicon runners some time ago; self-hosted Intel Mac minis are now end-of-line for current-toolchain builds.

FAQ

Does Xcode 27 raise the iOS minimum?

Not on paper — Apple's table has said iOS 15 since Xcode 26. What changes is enforcement: targets below 15 that built with a warning in Xcode 26 fail in Xcode 27.

What is the macOS minimum in Xcode 27?

macOS 12 Monterey, per Apple's Xcode support page and the beta 6 release notes. Earlier in the beta cycle the note was read as Big Sur; that reading is out of date.

Can I still build Universal (Intel + Apple silicon) apps?

Yes, from an Apple silicon Mac. The macOS 27 SDK supports Universal back-deployment to macOS 12 and later. The only case where x86_64 drops out by default is a target set to 27.0 or newer.

When do I have to move to Xcode 27?

For direct distribution, never — as long as you have a Mac that runs Xcode 26. For the App Store, when Apple makes the 27 SDK mandatory, which by its established pattern would be around April 2027. Apple has not announced that date.

Is the hidden setting safe for App Store builds?

Unknown. Nobody has reported a submission built with it, and it is an undocumented internal flag. Treat it as a tool for local builds and legacy branches, not for your release pipeline.

Conclusion

Xcode 27's deployment-target change is a small edit with a long tail. Apple did not raise the floor much — one version on macOS, none on iOS — but it stopped pretending the floor was optional, and a decade of independent Mac software was built on that pretence. The build error you get today is easy to fix if your users are on modern systems, and impossible to fix properly if they are not.

Know which you are. If you still ship to macOS 11 or earlier, the remaining window is Xcode 26 on a Mac that still runs it, and it closes for App Store apps in about seven months. If you do not, raise the number, fix the dependencies, check ARCHS if you are 27-only, and move on — Apple has finally documented the thing it was always going to do.

Related reading: audit your Intel apps before Rosetta ends, the macOS 27 Intel compatibility cutoff, fixing a macOS Tahoe developer setup, and the best Mac developer tools this year.