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:
6 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.
