It may not be obvious, but Apple still supports OS X 10.9 Mavericks. While it hasn’t provided any general updates to it since September 2014, and its last Security Update was back in July 2016, third-party developers can and do build their products for Mavericks using Apple’s Xcode SDK. With the release of Ventura, Apple looks set to withdraw that support from four versions, Mavericks, Yosemite, El Capitan and Sierra, leaving third-party developers to take the blame.
Of course, when coding for macOS, developers don’t have to use Xcode, but it’s the benchmark, the only complete environment which gives full access to the features of macOS, from its primary languages Objective-C and Swift, to the App Store and notarization for independent distribution.
Xcode version 13.4.1, its current release, supports all versions of macOS from 10.9 Mavericks to 12.4 Monterey. Of my little utilities, for example, over 20 presently rely on Xcode’s support so they run as far back as 10.11 El Capitan. However, Apple’s current beta-release of the successor, Xcode 14, only supports macOS from 10.13 High Sierra to 13 Ventura.
This wouldn’t be so restrictive if Xcode 13.x were to run in Ventura, but that isn’t the case, at least as far as 13.4.1 is concerned. Neither, according to Apple’s release notes, will the current beta of Xcode 14 run in Monterey [Note: either my eyes were deceiving me when I checked this, or Apple has now changed this, and beta 2 will now run in macOS 13.4]. This forces developers to choose between remaining with Xcode 13, and its support back to 10.9, running in macOS Monterey, or upgrading to Ventura to run Xcode 14, but drop support for 10.9-10.12.
Caught in the middle are Mac users, who won’t see Apple forcing third-party developers to drop support for those older versions of OS X, but will inevitably blame the developers instead. It’s thus a perfect management solution, as it reduces the cost of customer support but shifts blame for the consequences away from Apple onto third-parties.
There are two ways forward which Apple could choose to avoid this problem: either add support to Xcode 14 for 10.9-10.12, which I suspect is now all but impossible, or to release Xcode 13.4.2 with Ventura compatibility to retain support for those older versions of macOS. The latter would still prevent developers building apps with support for the new features of macOS 13, but at least it would let them reduce the impact on users of 10.9-10.12.
As usual, Apple remains silent. Nowhere in its presentations at WWDC, nor in the list of Ventura’s new features, does Apple state that it’s pulling support for four versions of OS X/macOS up to Sierra, inclusive. Instead we’re left to guess what’s about to happen from browsing Xcode’s release notes. At least Apple’s equally implicit and undocumented support with Security Updates is reasonably consistent and public knowledge.
Apple’s numerous developers who still support old versions of macOS won’t be allowed the same privilege, though. I now have to inform you that, when I switch to building my software using Xcode 14, the last build with version 13 will also be the last to support either El Capitan or Sierra. That grieves me. I have plenty of conditional code and other workarounds in apps like SilentKnight and LockRattler to ensure that they should still do their job as far back as in El Capitan. But I’m afraid it’s simply not feasible for small developers to maintain two versions of their source code, building in two different versions of Xcode, on two different versions of macOS, especially when many of us are trying to migrate to Apple silicon for development.
It also raises the question of Apple’s previous commitment to supporting older and long-unsupported OS X/macOS with security data updates, another subject that Apple refuses to inform users about. A few of you have already remarked that El Capitan doesn’t appear to be offered some of these any more, and the future of MRT remains in question with the release of XProtect Remediator, only available for Catalina and later.
We can all appreciate Apple’s enthusiasm for the ARM future, but what many of us need is a clearer picture of its plans to support Macs of the past. Without that, some users will prefer to remain with Intel and switch to a supported operating system, rather than gamble with an uncertain future, or be left to blame third-party developers for ending their support.