As of Xcode 12.2 beta and Big Sur beta 8, the 11.0 test is working again.

On Big Sur beta 11.0.1, attempting to print on my HP OfficeJet L7580 gave me error messages indicating that the macOS thought that the printer driver was malware. So I attempted to uninstall and reinstall the driver. But the driver installer won't run on Big Sur. Luckily I had a different partition that I could use to boot into Catalina. So I reinstalled the HP driver on Catalina, then went back to Big Sur and used Migration Assistant to copy over the printer driver. Now I'm back in business.

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.

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.

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.