Two things I’ll say:

1. these workarounds are great and I think it would be nice to encapsulate the logic in a community base class that has these fixes bootstrapped and ready to go. Basically a subclass of ScreenSaverView with these hooks in place.

2. I feel like it might be time to also consider abandoning ScreenSaverView entirely because a screen saver is nothing more than a background process that opens a full screen app after an idle timeout. Maybe that’s just the way going forward since Apple doesn’t seem interested in fixing anything.

And maybe just to clarify, savers are not apps. Historically, savers were plugins (as in, a bunch of code another app can load, think .dll for the Windows people) for ScreenSaverEngine. Apple however deprecated all plugins a while ago in favor of the (truly) safer app extension format. Except screensavers were left in the dust. So they came up with that magical solution of legacyScreenSaver.appex which tries to emulate the old API but as you’ve seen, fails progressively more and more at each major release of macOS.

So nowadays, a .saver is a plugin to an app extension (legacyScreenSaver.appex) to ScreenSaverEngine. Yay. Apple does have a private api for making appex screensaver, which it sometimes uses (or sometimes it bypasses the legacyScreenSaver requirement, because why not).

I’m pointing this out because of your title on handing resume. In practice, each screen, every time you launch the screensaver (or System Settings) creates an instance of the class in your bundle. As you pointed out, those will remain active (never get stopped or destroyed since Sonoma), and Tahoe makes this worse. System settings will (wrongfully) start 2 instances of your saver if you dare to open the ScreenSaver panel hidden inside Wallpapers. And it will not kill both (nor stop them, and here the stopAnimation trick is not sufficient).

There are tons of other issues regarding killing your own instance, depending on when you do it and various hardware, it will bring black screen issues. It may be safer to have stubs (what you call lameducks) laying around forever. And I didn’t even mention the multi monitor issues where legacyScreenSaver mixes up your screens.

Maintaining a third party macOS screensaver is needlessly impossible at this point, and it’s just a pain. I keep filing radars and try to raise the issue with DTS at every WWDC, and while they all acknowledge this is really bad, nothing ever changes. I try and maintain a minimal swift screensaver template (https://github.com/AerialScreensaver/ScreenSaverMinimal) with the various workarounds, but the not caring as you put it, is truly maddening.

Through several rounds of group effort, we managed to un-tangle the mess and come up with a ton of workarounds.

One particular fix we came up with is that it’s better to call exit(0) instead of NSApplication.shared.terminate.

Please read the thread here: https://github.com/JohnCoates/Aerial/issues/1396 for the gory details. There are links in that thread to Apple Developer forum posts which are also interesting – at least one Apple employee knows the situation is a mess.