I like your suggestion, but I just tried it and it seems that ~/Library/Application Support/ is re-routed inside the container, e.g. let rawPath = "~/Application Support/com.example/\(self.bundleID).plist" let path = (rawPath as NSString).expandingTildeInPath let url = URL(fileURLWithPath: path) guard let dict = NSDictionary(contentsOf: url) as? [String: Any] else { print("Error: Failed to read or parse plist at: \(path)") When run in context of a .saver running inside LegacyScreenSaver, this happens: Failed to read or parse plist at: /Users/username/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver.x86-64/Data/Application Support/com.example/com.example.foobar.plist I did another test where, instead of using ~/Library/Application Support/ I used /Users/Shared/com.example and that one seemed to work. Using /Users/Shared/ is not very elegant, but seems to be a location of last resort that some other apps use in some cases. Am I missing something? Is there a way from inside a sandbox, to get to the real ~/Library/Application Support/ folder, not the containerized one?

Thanks, @DTS Engineer for your (as always) thoughtful comments. I agree that using Appex format would be ideal. I submitted FB24013514 (under macOS / ExtensionKit / Suggestion) which I hope was the right category choice. As for workarounds using legacyScreenSaver, I believe I have found one. While it is true that a .saver running in the legacyScreenSaver sandbox can not read or write data from ~/Library/Preferences/com.foobar.plist ...it appears that it can read data from /Library/Preferences/com.foobar.plist (the shared Preferences location) with this code: let val = CFPreferencesCopyValue(key as CFString, self.bundleID as CFString, kCFPreferencesAnyUser, kCFPreferencesAnyHost) So a possible workaround is for the installer to write data to this location, which the screen saver can then read. I'm not sure if this is a clever and legitimate workaround or a bad idea. It seems unlikely to me that Apple would decide to restrict read-only access to /Library/Preferences in the future, but I don't have a great track record making these sorts of predictions.

To update an old issue - without any project changes on my end, but with several Xcode upgrades, this stopped happening. I don't know the exact Xcode version when it stopped.

FYI, we just tested beta 5 (25A5327h) and aren't seeing any improvements or changes.

I have also submitted a case regarding the regressions in UI/UX for screensavers: Tahoe has redesigned the UI for System Settings to remove the Screen Saver pane altogether. Instead, you access Screen Savers from within the Wallpaper settings. This has the following issues: Confusion - macOS has emphasized the importance of Screen Saves in recent years, and users expect to have a Screen Saver pane Usability - although you can access the Screen Savers settings, it’s now hidden behind a button within the Wallpaper settings, and the resulting window runs as a very small modal non-resizable dialog. Since macOS ships with dozens of screensavers by default, forcing the user to navigate these in a tiny window is just silly. Backwards compatibility is broken. For example, the command open x-apple.systempreferences:com.apple.ScreenSaver-Settings.extension No longer works in Tahoe. FB18698083

Testing using Beta 3, I've figured out one of the issues: In macOS Tahoe, when you are viewing the Screen Savers dialog (from inside Wallpaper), using legacyScreenSaver, the system is incorrectly launching 2 copies - one at fullscreen on the main screen, and then a second (correct) instance which is in Preview mode. Reported as FB18697726

Another issue: WKWebView-based screensaver doesn't display on 2nd monitor (legacyScreenSaver) in Tahoe Submitted as # FB17938870

Yes, the CSS has :hover classes, for example: .PlayPauseButton:hover { color: #FF0; text-decoration: none; cursor: pointer; } When i run this HTML/CSS in Safari, or in a normal WKWebView in a test app, it all works normally.

It's not related to NSAppleEventsUsageDescription - that's for something else. Specifically, I'm trying to set up a CGEventTap with the defaultTap option: https://developer.apple.com/documentation/coregraphics/cgeventtapoptions/defaulttap This triggers the OS dialog that looks like this: My question is: can this dialog be customized in any way?

There are many bugs with third-party screensavers under Sonoma. Here's a long thread that discusses a number of fixes: https://github.com/JohnCoates/Aerial/issues/1305 In particular, if your screensaver detects when it needs to exit, it can call exit(0) which seems to do the trick. Direct link: https://github.com/JohnCoates/Aerial/issues/1305#issuecomment-1680853387

Please take a look at https://forum.iscreensaver.com/t/understanding-the-macos-sonoma-screensaver-plist/718

I'm digging into this in more depth, don't have specific answers to all the issue yet, but am discovering some workarounds, and will post back when I have things sorted out. Feel free to contact me directly if you want info sooner - I'm active in a few places, including https://github.com/JohnCoates/Aerial/issues

@eskimo We are also getting reports of failures in first-party Apple screensavers using 13.4 on multi-monitor systems - in particular the Shifting Tiles screensaver has random blank screens when starting on 2 or 3 monitor systems. Shifting Tiles: when using the "Options / Source: Colors" (which doesn't use photos, just blocks of color) it seems to work fine on 2 or 3 monitor systems. However, if I choose "Options / Choose Folder" or "Options / Photos Library" then I can see some sort of malfunction: With 2 monitors: after the screensaver starts, I get 2 blank screens for about 20 seconds. After 20+ seconds, then both screens start working. With 3 monitors: after the screensaver starts, I get 5 seconds of blank screen, then monitor 1 starts, then another 5 seconds, monitor 2 starts, then another 5 seconds and monitor 3 starts. With repeated testing, the pattern is somewhat random: sometimes 1 and 2 start right away, followed by 3 about 5 seconds later.

Unfortunately this bug has been improved, but not fixed. In 13.4 RC, a system with 2 monitors works about 95% of the time. On a system with 3+ screens, the failure rate is 100%. Submitted a new FB case FB12179420 Discussion continues here: https://github.com/JohnCoates/Aerial/issues/1286

Thanks @eskimo the FB cases we know about are FB12023530 and FB12007471 - the thread which has the most technical details is this one: https://github.com/JohnCoates/Aerial/issues/1286 Note that the bug appears to be random and intermittent, so one successful test doesn't mean it's not happening. Test multiple times.