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.

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

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

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

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

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.

Thanks for the confirmation, Quinn. Bug filed, FB8892495. For now I will just increment a number at the end of my login item's bundle ID whenever I update it, which isn't that often.

I tried using SMLoginItemSetEnabled, but found that it didn't actually launch the copy of my helper inside the running copy of my app, but rather launched an older copy inside some archived copy of the main app. So unless I change my helper's bundle ID every time I update the helper, this doesn't seem like a reliable solution.