ATS and ATSUI Removal
macOS 13 Release Notes (2022):
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.
From the public Sonoma Beta 2 developer documentation👇
Whenever the OS detects the usage of deprecated APIs, the user will be presented a dialog stating that the app needs to be updated. When the dialog is dismissed the app will exit.
[…]
Many will say “oh this is beta” and we won’t see this in the public release
Take a look at AltTab’s dev response to this situation👇
I’m just trying to show how most 3rd party app devs may respond.
Apple has been clear that developers need to stop using ATS for a long time, but the alerts themselves are unclear, leaving some developers unsure of what they are referring to. The alert text also implies that the API has not actually been removed yet, which makes it seem like the app is being terminated unnecessarily.
Apparently not all Apple apps have migrated. Someone got that error dialog with Finder
Previously:
- Catalina Removes Malware Assurance
- Apps Lost With Catalina
- Removed in macOS 10.14 Mojave
- Apple Support Tells Customers to Ask Developer for Refund
Update (2023-06-30): Howard Oakley:
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.
[…]
This coincidentally spells out the meaning of full deprecation as a euphemism for removal of support.
[…]
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.
Update (2023-07-07): Craig Hockenberry:
Apple needs to go back to the drawing board with these alerts in Sonoma. They are scary, frequent, and not actionable.
It’s like an engine check light going on, taking the car to the mechanic, and having them say “I have no fucking idea what’s wrong”.
What’s worse, is that they only appear once with no apparent way to reset. That makes it impossible for a developer to verify that they fixed the deprecated API usage.
It’s also not a good look that these are happening in System frameworks.
Update (2023-07-10): Craig Hockenberry:
Supposedly, this alert should only appear with the use of ATS or ATSUI (per the release notes), but I find it hard to believe that modern system framework components shown above are using Apple Type Services that were replaced 13 years ago.
[…]
If Apple wants developers to repair these deprecations they need to make major changes:
- Document the behavior, including all of the APIs that trigger it.
- Tell developers if this is something that will only appear in the beta or if it will be a part of the final release.
- Give the customer something to work with when communicating with the developer. A diagnostic code at a minimum.
- Log information about what caused the issue: remember that it may not be the developer’s own code triggering the alert. Plugins, embedded libraries, and external frameworks should be a part of the log. These logs should be available to customers so they can provide them to developers.
- Give developers a way to reset the alerts. Make fixes testable.
Without these changes a Mac user’s future is one with a lot of crashes caused by deprecated code.
Update (2023-07-13): Quentin Carnicelli:
There is no improving this, short of its complete removal.
Since the very first computer platform was created, there has been a power struggle between platform owners and developers. As developers, we wish for a stable platform. It’s understood that it must evolve, but it should do so slowly and predictably. Platform owners, on the other hand, wish to cut out cruft and move forward rapidly. This tension is the normal state of affairs. When managed well, it keeps both parties in check.
This poorly-written alert, instructing users to contact developers for new software, is an unacceptable disturbing of that balance. The last thing users should ever have to worry about is “deprecated APIs”.
Apple already has a powerful method for dealing with deprecated APIs. First, they announce the pending removal of the API to developers. Then, some time later, they remove the APIs. That’s more than enough. It is our fervent hope that Apple simply drops this alert entirely before Sonoma officially ships in the fall.
I’m investigating the root cause of this alert. Haven’t gotten to the bottom of it yet, but found a way to reset the alert.
The daemon that’s showing this alert is replayd, it stores a boolean flag for each bundle ID that it’s displayed the alert for in its com.apple.replayd preferences domain, so running
defaults delete com.apple.replayd <app_bundle_id>will make the alert pop up again.
Update (2023-07-17): Craig Hockenberry:
And here’s the thing: a crash report from an API that has been removed has A LOT more information than the dumb alert box we’re seeing now.
This whole thing smells like an effort to chase reducing crash reports as an OKR metric. It can’t crash if you never let it launch!
With the removal of ATS/ATSUI in macOS 14, I believe all the QuickDraw GX-created things are gone from macOS?
Keeping up that system simultaneously and in sync with CoreText/<thing>, which uses a different model, was resource Intensive.
5 Comments RSS · Twitter · Mastodon
@Rawr Do you know which APIs? CGDisplayStream? I also got another reply stating that the alert does not relate to ATS. It’s wild that the alert is so unclear and that, even though ATS is documented as being removed, the apps that it affects apparently don’t get an alert.
@Avi Do you know the reasoning? As far as I can tell, those were not even deprecated in the macOS 13 SDK. In other words, the OS is showing that scary alert in the same version that first deprecated them.
