cwizou

Some of the restrictions have already been implemented in macOS 27 by restricting access to (at least some ?) containers even with Full Disk Access on.

One niche issue resulting from this : it broke the ability to access my own screensaver settings and files from it's settings app, because those settings live inside a container for a system extension that belongs to Apple (because Apple still hasn't publicly released it's "modern" screensaver api, it's still old style plugins run by a legacy extension).

Several screensaver developers I know got bitten by this and there's no proper workaround, you just have to use "/Users/Shared" and hope that doesn't go away any time soon.

In my case it silently broke migration for Aerial from 3.X to 4.X in Golden Gate (where I moved away from the legacyScreenSaver extension to the new undocumented wallpaperextension format). I did move to "/Users/Shared" earlier this year but some people will inevitably get caught by this if they didn't update, and there's no recourse, FDA doesn't work, you can't even ask for access, nothing works. And since it's a silent fail, I didn't even notice before this week.

I missed that part, and since it's a newly delivered plane (this January), it's safe to assume the mitigation was in place. Preliminary report will be interesting here.

As far as I can tell this is for WallpaperAgent, an extension to `com.apple.wallpaper` that are ran by WallpaperAgent on the desktop. For screensavers check my other post, I posted a sample the private screensaver api to bypass that.

Apple's uses both for their own "Aerials" and they have a sync system to share the position between the screensaver player and the desktop player.

Maybe there was an edit but it's the opposite, 66% disobeyed.

According to an AMD engineer I asked at the time, when they evaluated Ryzen/K12, it was "maybe" a 15% advantage for ARM depending on scenarios.

The efficiency came solely from the frontend which is a lot heavier on x86, and stay up longer because decoding is way more complex. The execution units were the same (at least mostly, I think, might be misremembering) so once you are past the frontend there's barely any difference in power efficiency.

Ha, you do the exit trick too then, I just missed it.

FYI that works 99% of the time, but for some people it sometimes crashes (because we exit our host container - legacyScreenSaver.appex - and sometimes if you do it at a wrong time things just hang).

That's super cool, congrats on releasing it ! It's a feature that some people periodically ask me to add in Aerial, but I never got to it. Piping from yt-dlp to AVFoundation is definitely the way to go.

I was gonna warn you about a bug in macOS 15+ where your screensaver stays around after you go back to the desktop, but for some reason your code seems to avoid that issue. I'm not quite sure how, as you don't hook stopAnimation or any event apart from the deinit. But it works, so, massive kudos, I'll have to try and understand why !

Interestingly in french we use "condamné" for sentenced, and for any kind of sentence (even a fine).

We don't ever use "sentence" in a legal context (it still exists but is old fashioned), things diverged quite a bit it seems between those languages.