Disclosure up front: I make a Mac app called Mainspring, so I have a horse in this race. Mods, happy to have this pulled if it is not a fit.
The workflow I keep running into, and I suspect I am not alone:
A user asks for some macOS behaviour changed. It is not exposed in a Configuration Profile payload, so it comes down to a defaults key in a script or a custom plist. You find the key on a blog from 2015, push it to a test machine, and then spend twenty minutes working out whether it actually did anything, whether it needed a killall, and what the original value was if you want to back it out.
The part that gets me is the last one. defaults read tells you the current value, but only if the key already exists. Plenty of these keys are absent until something writes them, so there is no "before" value to capture, and your rollback script has to delete the key rather than restore it. Easy to get wrong at 5pm on a Friday.
Two questions for the group:
1. How do you validate a new key before it goes anywhere near production?
Snapshot the plist, diff it, something more structured?
2. How do you handle rollback for keys that did not exist beforehand? Do you
bother, or do you just document the default and move on?
For what it is worth, the way I ended up handling this on my own admin Mac is a GUI that flips the key, shows the effect immediately, and records the prior state so it can be put back. That is the app I mentioned above, and to be clear it is a per-user tool, not an MDM one. It does not scale to a fleet and I would not pretend otherwise. It is useful for the "what does this key actually do" stage before something becomes a profile or a script.
