Changing Settings not Remaining in Place

[gank41]

Unsure if this is an issue with the Screensaver or macOS, so I also filed FB21679630. But when making any changes to the Screensaver's settings, no changes are remaining in place. I've tried rebooting and reinstalling the Screensaver for just me and for all users and am seeing no change. Unsure if its an issue with the Screensaver itself or with macOS.

[xlordz]

Same here, from Intel's Maverick to M4 Tahoe, always the same problem.

Why don't @monroewilliams free the chains and open the source ?

[gank41]

FWIW, I'm having no issues adjusting the settings for this on my 2018 Intel Mac mini, just my 2020 M1 MBP, and I continue to have these issues on macOS 26.4.1, too. I'm sure this is no fault from @monroewilliams here and more the fault of something wonky in macOS. If there was an issue with the app, it would also most likely fail on my Mac mini, too.

[mberding]

Chiming in - I'm having the same issue. M1 Pro (2021) running MacOS 26.5.1

[mberding]

I dug into this on my machine (M1 Pro, macOS 26.5.2) with some AI-assisted debugging/disassembly, and I believe I found the root cause. TL;DR: the saver's save code is fine — macOS 26 hands it stale control values, so this needs an Apple fix (or a workaround in the saver). Details below in case they're useful.

What I observed

1. The saver's prefs live here (and the "read" side works perfectly — if I edit this file by hand, the Options sheet and the saver itself pick the values up):

   ~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Preferences/ByHost/org.indirect.screensaver.Matrix.<hardware-UUID>.plist

2. Watching that file plus a debug-level log stream while using the Options sheet: clicking OK does invoke the save path, and it does write every key + synchronize. No sandbox denials, no cfprefsd errors anywhere.

3. Here's the smoking gun. I pre-seeded the plist with MinorInstability=false and Rotate=false, opened Options (both showed unchecked, correct), visibly checked both boxes, and clicked OK. At that exact moment CFPreferences logged:

   CFPrefsPlistSource<...> (Domain: org.indirect.screensaver.Matrix, ...) skipping setting already-present value for key Rotate
   CFPrefsPlistSource<...> (Domain: org.indirect.screensaver.Matrix, ...) skipping setting already-present value for key MinorInstability
   

   "Already-present" means the OK handler submitted false for both — the values from before my clicks. The checkboxes I toggled on screen are not the NSButton instances the save code reads at OK time. My guess is the new ScreenSaver settings extension causes the config sheet nib to be loaded more than once, rebinding the outlets to a fresh (pristine) copy while the user interacts with the original. Net effect: every save writes back the unchanged values, so nothing ever persists.

Possible workaround in the saver

Since reading the outlets at OK-time is what's broken, capturing values as they change would sidestep it — e.g. have each control's action (the same one that live-updates the preview) stash the new value, and have the OK handler write the stashed values instead of re-reading the outlets. Alternatively, caching the configure sheet and returning the same instance on repeated configureSheet calls might prevent the outlet rebinding in the first place.

Workaround for users meanwhile

You can set preferences by writing the plist directly, then restarting the prefs daemon and saver:

P=~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Preferences/ByHost/org.indirect.screensaver.Matrix.*.plist
plutil -replace CellSize -integer 8 $P        # 8/16/32 = Small/Medium/Large
plutil -replace Rotate -bool true $P          # also: 3DFade, MinorInstability, Workaround
plutil -replace Renderer -string Metal $P     # or OpenGL
plutil -replace color2 -json '[0,1,0]' $P     # color0/1/2 as [r,g,b] 0–1
killall cfprefsd legacyScreenSaver

These stick permanently (nothing ever successfully writes over them).

@gank41 — this should be useful detail for FB21679630: legacy screensaver config sheets on macOS 26 return stale control state to the plugin's save action, so third-party saver settings silently never save.

[gank41]

Thanks for this! I did add it to the Feedback I filed.. I guess only time will tell.

[solvedesigncreate]

"The Options sheet opens successfully on the first launch after legacyScreenSaver initializes, but subsequent clicks fail after closing the panel with 'OK'. This happens because the modal sheet dismissal isn't properly tearing down the XPC window context under macOS 26 / Tahoe, leaving the host view controller in a deadlocked state until killall legacyScreenSaver is executed."

[solvedesigncreate]

The Bug in the Source Code
In legacy macOS screensaver code, the options panel is typically opened and closed using standard Cocoa modal methods like this:
// The old, broken way in modern macOS XPC extensions:

• (IBAction)closeSheet:(id)sender {
  [[NSApplication sharedApplication] endSheet:self.optionsPanel];
  [self.optionsPanel orderOut:nil];
  }

Under modern macOS releases (like Tahoe), third-party screensavers don't run as standard applications—they are hosted inside an XPC extension process (com.apple.ScreenSaver.Engine.legacyScreenSaver). When endSheet: is called inside an XPC host, it fails to tear down the window context, leaving the window controller deadlocked the second time you click "Options...".
The Code Patch
To fix this, the screensaver needs to explicitly dismiss the sheet using the modern [NSWindow sheetParent] API and invalidate its window controller reference so the XPC framework frees the memory.
If you have the source code downloaded, open the main Objective-C file (usually MatrixView.m or MatrixScreenSaverView.m) and update the sheet dismissal method:
replace the old sheet closure code with this:

• (IBAction)closeSheet:(id)sender {
  NSWindow *sheet = [sender window];
  NSWindow *parentWindow = [sheet sheetParent];

  if (parentWindow) {
  [parentWindow endSheet:sheet returnCode:NSModalResponseOK];
  } else {
  // Fallback for older macOS environments
  [NSApp endSheet:sheet];
  }

  [sheet orderOut:nil];

  // Crucial for macOS Tahoe XPC sandboxing:
  // Explicitly release the nib/controller reference so it can re-initialize on subsequent clicks.
  self.optionsController = nil;
  }

How to Apply the Patch and Build
If you want to build your own fixed .saver file locally on your Mac:
1. Clone your repository:
git clone https://github.com/monroewilliams/MatrixDownload.git
cd MatrixDownload

2.	Open the project in Xcode.
3.	Locate the closeSheet: or configureSheet: action method in the .m files and apply the snippet above.
4.	Go to Product ‭$\rightarrow$‬ Build (or Cmd + B).
5.	Copy the newly compiled Matrix.saver file out of your Xcode DerivedData folder into ~/Library/Screen Savers/.

Alternatively, you can post this exact code snippet directly as a comment on the GitHub issue! The author (@monroewilliams) can copy-paste this fix into the codebase and push a updated release tag.

[solvedesigncreate]

I dug into this on my machine (M1 Pro, macOS 26.5.2) with some AI-assisted debugging/disassembly, and I believe I found the root cause. TL;DR: the saver's save code is fine — macOS 26 hands it stale control values, so this needs an Apple fix (or a workaround in the saver). Details below in case they're useful.

What I observed

1. The saver's prefs live here (and the "read" side works perfectly — if I edit this file by hand, the Options sheet and the saver itself pick the values up):
   ~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Preferences/ByHost/org.indirect.screensaver.Matrix.<hardware-UUID>.plist

2. Watching that file plus a debug-level log stream while using the Options sheet: clicking OK does invoke the save path, and it does write every key + synchronize. No sandbox denials, no cfprefsd errors anywhere.

3. Here's the smoking gun. I pre-seeded the plist with MinorInstability=false and Rotate=false, opened Options (both showed unchecked, correct), visibly checked both boxes, and clicked OK. At that exact moment CFPreferences logged:

   CFPrefsPlistSource<...> (Domain: org.indirect.screensaver.Matrix, ...) skipping setting already-present value for key Rotate
   CFPrefsPlistSource<...> (Domain: org.indirect.screensaver.Matrix, ...) skipping setting already-present value for key MinorInstability
   

   "Already-present" means the OK handler submitted false for both — the values from before my clicks. The checkboxes I toggled on screen are not the NSButton instances the save code reads at OK time. My guess is the new ScreenSaver settings extension causes the config sheet nib to be loaded more than once, rebinding the outlets to a fresh (pristine) copy while the user interacts with the original. Net effect: every save writes back the unchanged values, so nothing ever persists.

Possible workaround in the saver

Since reading the outlets at OK-time is what's broken, capturing values as they change would sidestep it — e.g. have each control's action (the same one that live-updates the preview) stash the new value, and have the OK handler write the stashed values instead of re-reading the outlets. Alternatively, caching the configure sheet and returning the same instance on repeated configureSheet calls might prevent the outlet rebinding in the first place.

Workaround for users meanwhile

You can set preferences by writing the plist directly, then restarting the prefs daemon and saver:

P=~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Preferences/ByHost/org.indirect.screensaver.Matrix.*.plist
plutil -replace CellSize -integer 8 $P # 8/16/32 = Small/Medium/Large
plutil -replace Rotate -bool true $P # also: 3DFade, MinorInstability, Workaround
plutil -replace Renderer -string Metal $P # or OpenGL
plutil -replace color2 -json '[0,1,0]' $P # color0/1/2 as [r,g,b] 0–1
killall cfprefsd legacyScreenSaver
These stick permanently (nothing ever successfully writes over them).

@gank41 — this should be useful detail for FB21679630: legacy screensaver config sheets on macOS 26 return stale control state to the plugin's save action, so third-party saver settings silently never save.

You nailed it, your fix worked perfectly THANK YOU

[gank41]

Thanks! I've added this to FB21679630, although we're still at the mercy of someone at Apple looking at it...