User Profile

Same issue as Jakub, I would add ScreenSaver settings to that list too if possible. @RudoBaker did you report the feedback yet ?

This may be unrelated but I had some users report very high CPU usage starting with late 10.15 versions when I draw text using CALayer on retina. The bug doesn't happen on every single machine, I can't reproduce it on my Late 2015 iMac for example. I ended up adding a switch in my screensaver (Aerial) for high resolution text because of that. To directly answer your question, the way I fixed it is by rasterizing the layer I'm drawing, using this : nLayer.shouldRasterize = true https://developer.apple.com/documentation/quartzcore/calayer/1410905-shouldrasterize Do you see the high CPU usage in app mode too ? You may be able to file a feedback so they can track this down, as it's a huge regression and I still to this day have no idea exactly why it doesn't affect everyone.

So those graphics errors, in general, tend to pop up with other screensavers, so I don't think they are your issue. But I did try Mosaic here and it also hangs, after some digging I found this : erreur 14:30:03.837445+0100 accountsd "Cannot check access to a private account type: com.apple.account.AppleAccount" erreur 14:30:03.838207+0100 accountsd "Client (<private>) attempted to access restricted account type: com.apple.account.AppleAccount" erreur 14:30:03.838244+0100 accountsd Unentitled access by client 'iLifeSlideshows' (selector: <private>) erreur 14:30:03.838387+0100 iLifeSlideshows "Error returned from daemon: Error Domain=com.apple.accounts Code=7" Looks like they may have forgotten to set some permissions. This is on 11.2 (20D5042d) here. iLife-Slideshow is the wrapper for some of the old Apple screensavers with special permissions, but they may have missed some I guess. I'd suggest you file a feedback.

I can confirm that @Tempers solution worked for me ! I opened another project and my crashing project afterwards, and that works... I guess that's a good workaround in the meantime, thanks a lot.

Just to add some feedback, I've also hit that issue with macOS 11 Beta 10 and Xcode 12.2 beta 2 (I hadn't updated to beta3 yet). So It may not be just an Xcode 12.2 beta 3 thing.

FYI, reverting to Xcode beta2 lets you compile again (as the SDK is bundled with the xcode build), I filed a radar, guess we'll see.

Can confirm, same issue here on my project that worked fine with previous Xcode builds : /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/usr/lib/swift/AVFoundation.swiftmodule/arm64e-apple-macos.swiftinterface:1:1: Failed to build module 'AVFoundation' from its module interface; the compiler that produced it, 'Apple Swift version 5.3 (swiftlang-1200.2.22.2 clang-1200.0.25.1)', may have used features that aren't supported by this compiler, 'Apple Swift version 5.3 (swiftlang-1200.0.22.4 clang-1200.0.25.1)' Looks like a problem with the SDK, hopefully we'll get a fix soon.

@jbwils short answser, as of right now, not possible on Catalina and Big Sur, this may change soon though. Longer answer, Apple introduced in Catalina a new Sandboxing mechanism for the old fashioned plugin architecture. Screen savers (which are still plugins) are limited by the entitlements of legacyScreenSaver.appex, which doesn't include raw access to keyboard and mouse. Apple started moving its screen savers to an app extension format, but as of right now there's no extension target in Xcode 12 beta 1 to make screen savers. Hopefully this will come in a later seed and then, you'd be able (in theory) to do what you want by giving your own entitlements.

Understood on the first point. Some form of communications about the changes that happened with no announcement nor documentation would have been appreciated, though. To this day the changes are still not documented anywhere (and new subtle bugs get reported to me often by users, and I'm not sure what to do about them, except filling radars with no feedback). I definitely understand screen savers are low priority but it's still a tiny bit frustrating 😉 I'll give it a shot on the second issue when I have a second.Thanks for your time.

Hi @eskimo !If I may jump in, you mentionned this :"The current screen saver architecture relies on an old plug-in model, one that Apple is working to eliminate across our systems because it has fundamental limitations."I definitely agree about those issues and will most definitely welcome the new API, but in the meantime we're in a weird space right now with screen savers on Catalina. Apple started moving some (most) of it's own screensavers behind a new .appex format that, to this day, is still unavailable to 3rd parties with no guidance on when (to be honest, I started wondering if it's not an "if" instead of a "when") it will be available. I have to say your message gives me hope that there will be a new API released at some point !In the meantime, the legacyScreenSaver.appex workaround has many bugs (I filled many radars) like always responding with the preview flag to true on init, or randomly resizing the main screen saver view to the size of the preview. After some time, I've managed to workaround those.And while many features are now understandably gated by the entitlements inherited from legacyScreenSaver (for example, in Aerial, I had an option allowing users to skip a video by pressing the right arrow key, this is no longer possible) and cause an inconvenience, my biggest concern is that I'm no longer able to provide an auto update mechanism because of the sandboxing restrictions (I used Sparkle, neither the 1.x nor the 2.x branch work, being denied either because of a quarantine issue when copying the auto updater, or an elevation privilege when trying to use xpc in the 2.x branch).Is there any chance we could get guidance on if we can expect the new api some day ?Second question if I may, you mention this in the post you refered to :"Old school plug-ins must use the system’s Swift runtime, meaning they must have a deployment target of macOS 10.14.4 or later."I currently still do it the old fashion way, as I still support older OSes with Aerial. There are two side effects I know of with Swift screensavers linked this way :- if you have two of them, you won't be able to switch from one to the other (as they will likely not use the same library) and get this error : "You cannot use the Aerial screen saver with this version of macOS."- if you try updating a swift screensaver without closing System Preferences first, the new version will get "partially loaded" (my limited understanding, either the code or the nib isn't reloaded, causing a crash).I would guess using system's Swift fix the first issue, do you happen to know if it would fix the second in a screensaver ?I want to thank you in general for your posts in this forum that, more than once, provided some great feedback that helped me figure some things out. And while I definitely understand that you may not able to provide any guidance here, any word would be greatly appreciated!

Hey @XMIReally sorry for not following up with you, I don't get notifications for this forum (despite "following", whatever that means), so you may not see this or it might be too late. If you do, here's what I know so far.Screen savers are now plugins that are ran by legacyScreenSaver. legacyScreenSaver is the one that is sandboxed, and *all* our 3rd party screen savers are living with it's constraints, within it's container.So to give you an example, if you want to create an Aerial folder in "Application Support", while you would expect it to be created in~/LibraryApplication Support/Aerialas it is in Mojave, in Catalina your folder using the same system commands go here :~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Application Support/AerialThe same goes for your preferences, your screensaver will read preferences, assuming you already use ScreenSaverDefaults in your screensaver and don't try something fancy (don't, you can't) in the container :~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Preferences/ByHost/your.thing.plistI would assume that your screensaver cannot load anything but this. As for your helper app, a 3rd party app can read/write inside the container usually (I edit my logs with sublime text for example inside the container). Your mention this which I don't understand though "my .saver bundle contains a helper app" My guess is you distribute both alongside eachother ? Where does the helper app go, in /Applications ? My guess is that app can read your preferences inside the container, the other way around won't work.As you may have found out, there's a ton of restrictions imposed upon us by legacyScreenSaver:- You no longer have access to the keyboard (for example, I used to allow user to press the right arrow key to skip a video, can't do that anymore).- You cannot write outside the container. This is a big one for me as we download large video files, you can only write to your container.- You can read (with limitations) outside the container, but on the local disk only, and maybe not all the files/folders. You cannot read from a network volume or any attached device. You cannot workaround this with symlinks.- I'm doubtful that you can launch a process as your code is trying to do here from screensaver, that's probably a big no-no now.You can workaround all this if you disable SIP, which you shouldn't do and your users shouldn't do either).It's really all clamped down, possibly for good reasons in terms of security. But with no ability to make the "new" format of screensavers (.appex, where you can ask for your own permissions), it's really a terrible setback for the very tiny world of 3rd party screensavers and my hopes aren't high for things improving in the final build.Hopefully you figured things out since then. Best of luck.

Yep must be it 😉 They were pretty clear about notarization being needed, but no idea how that interacts with an installer. I try to keep a list of changes/bugs on our github repo in any case if you are interested (just look up Aerial). One thing we saw was despite being sandboxed, we still have read only access to the disk in b1/b2. And that the non legacy mechanism seems to be XPC based.

I didn't see it on my system, but only on users system. I package Aerial as a zip, and the user installs by double clicking, yes. This way, the .saver appears with the quarantine xattr bit, and that triggers GateKeeper verification which requires signing and (my understanding of WWDC sessions) notarization. Our users who installed via homebrew had the same issue, and so were the ones copying the screensaver manually to the system folder.According to WWDC sessions I did assume notarization was 100% necessary when going through gatekeeper. It's less painful that it seems (and takes about a min per release to get the cert back). Maybe using a pkg lets you avoid the quarantine flag and thus gatekeeper doesn't kick in ?