I had a similar error in my project (using Xcode 13.2.1 on an M1 mini), but only in the unit test target associated with my program (a command line tool rather than an application). Oddly, the error pointed to the @testable import <program_name> line in one of my unit test source files, and only when the selected scheme was the one for the unit test target. My project does include a number of Swift packages. Searching the Internet for the text of the error message led me here; I tried the approved answer (explicitly setting the architecture to "x86_64 arm64", and it seemed to work for me. However, in subsequent experimentation I found that it appeared to be sufficient (in my case, anyway) to ensure that the Architecture was set to "$(ARCHS_STANDARD)" directly on the project, instead of inheriting the value from the "macOS Default".

On my M1 Mac mini running Ventura 13.5, when I go to System Settings > General > Software Update, I see an item called “Beta updates” with an “info” icon (circled letter i). Clicking that icon opens a dialog containing a popup menu labeled “Beta Updates”; the default item is “Off”, but when I click it I see choices for public and developer betas for both Ventura and Sonoma. Below that popup menu, the dialog displays the Apple ID that I am currently logged into, and a link labeled “Use a different Apple ID for beta updates...”. You may have to log in to an Apple ID associated with a developer account in order to see the developer betas.

Thanks for your reply. I've submitted FB13715123 in response.

I've filed a bug report as FB13798038. Thank you for tracking down that previous discussion. I think I was searching for the error message rather than the text "Library Validation". It's very on-brand that your top ten list now goes to 14. ;-) The article I mentioned is here: https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/ As always, your assistance is invaluable. Thanks again.

Did you try it? NSTextView has supported many Emacs-style commands since the NextStep days, and Xcode does too — go to Xcode > Settings > Key Bindings > Text and check it out.

To close the loop: The Apple engineer responded to my bug report by politely suggesting that according to the sysdiagnose logs I had sent, the sudo plugin was loaded and sending an XPC message to our policy engine in every instance. To my embarrassment, they were correct — the sudo plugin was not responding to an internal error in our policy engine in a way that was readily distinguishable from failing to run at all, and unfortunately I bit on what turned out to be a red herring. Now I have a new (and hopefully more productive) area to investigate. Thanks for your attention.

Update: It looks like Apple developer support was able to "turn on" the notarization ability for the legacy account, as I have just successfully notarized a local build. So we seem to be OK as long as the old account remains active.