What's the numerical error code?

Does the name Dragan Milic appear in your Info.plist file (the one for the main app, not the one for the helper)? I bet it's coming from there, not from the code signing information.

I'm not sure if this is the problem, but the location of the dylib in your bundle is peculiar. For one thing, the Resources folder is not one of the standard locations for nested code, according to the macOS Code Signing in Depth technote. Also, that document says The code signing machinery interprets directories with periods in their names as code bundles and will reject them if they don't conform to the expected code bundle layout. so that ".dylibs" folder could be a problem.

Experimentally, CGRequestPostEventAccess is not synchronous. Even if it has opened an alert offering to take the user to System Settings to grant access, it returns NO in a millisecond or so. I was also confused by the fact that the related function CGPreflightPostEventAccess just seems to report the access that the process had when it launched, even if the access shown in System Settings changed while the process was running. That was beginning to make me believe that changes in trust while a process is running don't affect the process at all, but that seems not to be the case: If an agent is initially trusted to post events, and installs an event tap, but trust is revoked while it's running, then the Mac becomes mostly unresponsive to keyboard events. I've submitted FB11832484 requesting documentation on these APIs. Note that the framework prevents you from requesting multiple times. I'm guessing you mean that repeated calls to CGRequestPostEventAccess will silently fail, but please let me know if there is some other form of "prevention".

I have the same question, but on macOS, does that change the answer? At the moment I’m sending a distributed notification that basically just says “hey, check the shared user defaults, they may have changed”, but maybe there’s a cleaner way.

Thanks! I filed a documentation bug, FB11786569.

Thanks. For posterity I'll note that in the release version of Ventura, this section (if present) is apparently titled "Allow in Background", which is not any clearer IMHO. But the WWDC session seems to indicate that this list is for launch agents and daemons, whereas plain old apps that run at login, background-only or not, are in the upper list.

OK, now I see that if I add the script file as an "input file", the error goes away. I guess that makes a certain amount of sense.

It looks like the error only happens if I make the script build phase run a script file, as opposed to entering the script directly in the build phase. I've reported this as FB10339650.

Experimentally, using 32-bit floating-point samples works, so I have filed a bug report on the documentation: FB9972520

When you're testing, do your test items like /Users/username/.Trash/foo actually exist? Maybe you're assuming that this test should be entirely path-based so it shouldn't matter, but in fact this getRelationship method returns an error if the URL does not point to an actual file/folder. Not sure why you didn't get the "Unable to get relationship..." log message; I'm an old-fashioned objective-C programmer.

Clarification, it looks like what is not being respected is FRAMEWORK_SEARCH_PATHS, not HEADER_SEARCH_PATHS. The wrong framework headers are being used.