When I log in to App Store Connect, I see a notice about "Review the updated Paid Applications Schedule." I wouldn't have thought that something about paid applications should affect notarization, but I bet this is the problem.

Once the account owner agreed to the Paid Applications Schedule, notarization worked again. Notarization could certainly be made more user-friendly.

I found a workaround, though it's not ideal: Add an NSAppTransportSecurity exception in my Info.plist, allowing insecure loads for the domain I'm downloading from.

I found the page Identifying the Source of Blocked Connections about checking ATS problems with nscurl, and that shows the same errors in Sierra, without allowing insecure loads. So I guess that means it's not an error in my code. And on Big Sur, all the nscurl --ats-diagnostics tests pass, so it seems like it's not a server problem either, leaving the conclusion that it must be a Sierra bug.

I don't have an answer, but I can tell you that the word is "deprecated", not "depreciated". Those are two different words.

It looks like this may be fixed, I couldn't replicate it with Xcode 13 beta 4.

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

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.

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

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.

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.

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.

Thanks! I filed a documentation bug, FB11786569.

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.

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".