Ending the Golden Era for Backward-Compatible Apps
I don’t appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It’s my decision which OSes I want to support, not Apple’s. Yes, I can keep Xcode 26 around until submissions require Xcode 27, but what then?
Originally, Xcode 27 was documented as supporting Big Sur on Intel Macs, but now the earliest is Monterey.
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. I filed bugs, and Apple kept responding that they’d fixed it, when they hadn’t.
Using old versions of Xcode isn’t a great solution because they aren’t supported on Golden Gate. Swift also makes it more difficult to call newer APIs when using an older SDK. You can’t just copy/paste a method prototype or constant value and conditionally use it when running on a newer OS.
I eventually found a hidden workaround that changes the errors back into warnings. That is good news, but it does not make the concern disappear. The setting is undocumented, absent from the normal Xcode interface, and currently being tested only in a beta toolchain. The larger question is what Apple intends to enforce when Xcode 27 is final and, later, when App Store submission requirements move to its SDKs.
[…]
Apple’s current Xcode system requirements list Xcode 26 with deployment targets beginning at iOS 15 and macOS 11. Yet developers have been able to enter older targets manually. In an Apple Developer Forums discussion about Xcode 26, an Apple product manager explained that the published deployment target range is aligned with simulator support and on-device debugging. The accepted answer confirms that an iOS 13 target can still build even though it falls below the range in Apple’s table.
My own tests went further. Xcode 26.5 compiled a project targeting iOS 9.0. It warned that the target was older than the supported range, but the build succeeded. On macOS, I have compiled current apps with deployment targets as old as macOS 10.9. Xcode warned me, but it still produced working applications.
[…]
For iOS and iPadOS, staying on Xcode 26 is not a lasting option. Apple has repeatedly made a current Xcode and SDK mandatory for new App Store submissions. […] If any one of those conditions fails, iOS and iPadOS developers will have no normal App Store path for publishing new updates that still support versions older than 15.
Previously:
Update (2026-09-07): Léo Natan:
Just want to remind you guys that if you move to Xcode 27, the only “officially” supported and sanction Xcode for GG, UIDesignRequiresCompatibility is no longer respected across the 27 OSes (apps built with older Xcodes still are). So you might suddenly find out you have a lot of work ahead of you, adding support for the dreaded Glass. And 27 Glass is not the same as 26 Glass. That can be an issue if you skipped 26 altogether but still want to support it.
Previously:
Update (2026-09-11): Nick Lockwood:
I mostly ignored the Xcode 27 betas (mainly due to the barely-usable Device Hub) so I didn’t realize the passive-aggressive prompts to drop support for iOS < 15 that you get when submitting apps is being backed up by Xcode 27 refusing to compile apps at all unless you bump the deployment target 😧
11 Comments RSS · Twitter · Mastodon
I wonder how much of a viable strategy it is, at least outside of the App Store, to build with different Xcodes for different targets. Xcode 16 for macOS 10.13-10.15, Xcode 26 for 11.0-14.0, and Xcode 27 for latest. With Objective C, this is very doable and relatively easy to maintain. But with Swift and its ever-changing silly syntax, that could turn into a big mess. It is still possible to `#if compiler(>=6.4)`, but due to how conditional compiling on Swift works, it's very annoying and leads to many duplicates.
@Léo I can’t see that being worth it. It’s a real mess with Swift, not only for newer APIs as I mentioned, but also for deprecated APIs. There’s no fine-grained control over warnings, and the conditional compilation stuff isn’t powerful enough.
"releases that claimed to support deployment on older macOS versions when Apple clearly hadn’t tested that it actually worked"
How is that not covered by automated testing?
@Plume Charitably, maybe they tested with toy/test apps? Real apps conditionally call newer APIs when running on newer OS versions, and that’s what would trigger the problems (crashes).
Does the inability to support older macOS versions also extend to Electron apps or other cross platform tool kits? Feels like something that could make the march of Electron worse if it is not impacted.
@mjtsai Regarding “Swift also makes it more difficult to call newer APIs when using an older SDK.”, I suppose you could write an Objective-C helper bound to Swift that does what you want.
Even now, it is necessary to have Objective-C waiting in the wings; e.g. with Core Data, there are weird scenarios like exceptions that are only thrown/catchable from Objective-C and you need that code to detect the issue. Swift is still too “hide the details” for my liking.
@gildarts I’ve not built Electron, but my guess is that you could use an older compiler. I guess the SDKs don’t matter so much in that situation.
@Kevin Yeah, I’ve wrapped Core Data’s save API with Objective-C so that unexpected exceptions get converted to errors instead of crashing my app. Also had to use Objective-C to work around an issue where lazy batch fetching arrays would get eagerly turned into Swift arrays. There’s some weirdness like not being able to override some methods in a context subclass because they’re actually defined in the Swift overlay. Currently fighting an issue where Swift’s autoreleasepool crashes when cleaning up some sort of private Core Data helper that’s created during a fetch. The AIs assure me that this is an undocumented special case and you are not supposed to fetch inside of a pool.
Speaking for myself, so far so good. But the next few weeks will say if my setup might last another cycle.
macOS 15.7.9, Xcode 26.3, latest "test" submission needed to target iOS 17.6 (up from 15.x). FYI - it was truly a test submission - added things to exclude in UIActivityViewController.excludedActivityTypes - and 2 of 5 apps were approved in ~6 hours. (MAP submission developers are clearly seeing something much different.)
Here's where I'm at. Xcode 26.4+ will not install on macOS 15.x, period. While (so far) macOS 27 (now in beta 8) continues to show much improvement, I *refuse* to try macOS 26. Tried it, don't like it. I have a "Plan B" that involves not beta platforms but I'm hoping Xcode 26.3 submissions will still be accepted.
Liquid Gl[ass] simply threw (yet) another complication from Apple regards to backward compatibility. And YES, macOS apps have even more complexity. Hey, at least you have VMs to help on your targets. :-)
Regarding incoherent docs, swift.org says it’s MacOS ≥ 13.0 for some reason: https://www.swift.org/platform-support/#minimum-deployment-version :)
Regarding cross-platform frameworks, the latest Qt and Electron already require MacOS ≥ 13; the trade-off to support MacOS 12 by using an older version surely doesn’t make sense.
@Alexandre That is really strange. I used Xcode 27 to compile my Swift apps for macOS 12 with no errors. So either that page is wrong or they’re going to unexpectedly blow up at runtime.
