Apple runs on magic and thrives on surprise. Even when it has to provide details of forthcoming products like Apple silicon and Vision Pro, it still likes to pull them from a hat like an entertainer. What it’s not always so good at is saying its goodbyes to what it terms deprecated features, like kernel extensions and AFP.

Use of the word deprecation here is itself odd. Most dictionaries consider that it refers to an expression of disapproval rather than being a warning that a feature is going to removed in the foreseeable future, as seems to be the case in macOS. Nowhere does Apple appear to explain what it means by the term, nor does it provide any idea of the timescale between deprecation of a feature and its removal.

Although not normally used in user-facing documentation, deprecation is widely quoted to the public. Many are well aware that AFP and kernel extensions are both deprecated, even though they still remain usable to some degree. Users are far from clear when deprecated features are likely to be removed: it has become one of the standard questions put to those testing the betas of the next major release of macOS. Does it still support kernel extensions and AFP? This nervousness has been reinforced by warnings displayed by recent versions of macOS about forthcoming removal of support for kernel extensions, encouraging users to contact developers and put pressure on them to switch.

Many parts of the macOS API remain deprecated for years before they’re finally removed. This article lists those parts of the Carbon Core framework within Core Services that were deprecated as of OS X 10.8, back in 2012, yet several of those are still present and deprecated in macOS 13 a decade later. At that same time support for AFP was deprecated, as it remains to this day, although being able to run an AFP server wasn’t removed until macOS 11, eight years later.

One of the delays inherent in this process is the provision of substitutes. Kernel extensions had been sort of deprecated for longer, but it wasn’t until macOS 10.15 that Apple spelt out that support for many would be withdrawn in macOS 11. System extensions and their siblings aren’t able to match some the features of kernel extensions, and it’s only more recently that some major software products have been able to switch to substitutes. The only solution for some like SoftRAID has been to become incorporated into Apple’s official macOS distribution,* and the widely used SAT SMART driver still doesn’t seem to have been converted into a system extension.

For developers, the vagueness of deprecation makes preparation difficult. I’ve recently spent many days revising my apps that access extended attributes because they relied on deprecated code. While I now feel that’s been worthwhile, my fear that they would stop working in macOS 14 seems to have been completely unfounded, and in retrospect I could have spent that time better. For those using NAS with their Macs, switching from AFP to SMB has brought many problems that those who hung back longer haven’t had to deal with. Was all that time and effort well spent, or will those latecomers profit?

What we all need most is a clear statement of the target date for a feature’s removal, not Apple’s expression of disapproval and vague hand-waving for the future.

Apple has recently done just this with its old Apple Type Services (ATS) for Unicode Imaging (ATSUI), introduced back in Classic Mac OS 8.5 to render Unicode text. This was replaced by Core Text in Mac OS X 10.5 (2007), and officially deprecated at the end of 2012. Unusually, Apple clarified its timetable in the release notes to macOS Ventura 13, where it stated:
“ATS and ATSUI APIs are fully deprecated. Code using these APIs will fail to compile and link when the deployment target is set to 13. Code targeting earlier versions of macOS will continue to compile, link, and run. macOS 13 is the last release where code depending on ATS or ATSUI will run. All runtime functionality will be removed in next major release of macOS.”

This coincidentally spells out the meaning of full deprecation as a euphemism for removal of support. It also explains why macOS Sonoma is even clearer. Release notes for developer beta release 2 state:
“Starting macOS 14 Sonoma, whenever the OS detects the usage of ATS or ATSUI APIs, the user will be presented a dialog stating that the application needs to be updated. Once the dialog is dismissed by the user, the application will exit.”

Unfortunately, ATSUI doesn’t seem to be the only deprecation that’s pursuing this policy. Other unrelated API calls seem to result in similar dialogs and forced exit, which one beta-tester has even experienced with the Finder. While ATS/ATSUI has surely done this right, it looks like others have jumped on the bandwagon. This is concerning, as Apple needs to be very careful about information that’s displayed to users. It must be specific, and not anticipate removal. Deprecation should normally be a matter between Apple and the developer, not a way of applying pressure to the developer.

When Sonoma is released, watch out for these dialogs. If they start upsetting you or become in the least bit irksome or inappropriate, please don’t hesitate to complain to Apple, not the developer.

* I’m very grateful to Ron Gomes for pointing out that SoftRAID still hasn’t been able to use a system extension, and finally in macOS 13.3 Apple has started including its kernel extension as part of the official macOS distribution, so that Apple silicon Macs no longer have to run in reduced security to be able to use SoftRAID – something that Apple could have done over two years ago in macOS 11.