Hello,
unfortunately this fix seems to be causing other issues. We need urgent clarification.

The computer is an M1 max. We are using Unity 2020.3.24f1, the same issue occurs on 2020.3.25.

We need to deploy directly to macOs platform but our builds fail as such:

UnauthorizedAccessException: Access to the path projName/Temp/StagingArea/25.main.app/Contents/PlugIns/FirebaseCppAnalytics.bundle is denied.

Switching the plugin to force intel 64 or the build itself to intel 64 does not resolve this issue.

A slightly different example is
UnauthorizedAccessException: Access to the path projName/Temp/StagingArea/mainline.app/Contents/PlugIns/agoraSdkCWrapper.bundle/Contents/Frameworks/AgoraAIDenoiseExtension.framework/Versions/A/AgoraAIDenoiseExtension" is denied.

Note that this one sits within a framework within a bundle. The bundles fails to be copied to folder "plugins" because the existent folder is named "PlugIns"

There are bespoke solutions on the web from users mentioning to unset and re-set the bundle import settings, some say it should be forced to intel64 with the project at intel64.
Unfortunately none of these solve our issue and I am failing to find suitable instructions to use SDK bundles

Deploying to an Xcode project works but then running the build fails as soon as the relevant SDKs are initialised, just like the incomplete .app which found in temp/StagingArea.

Thank for any advice, links, suggestions

After typing my previous comment, I searched for the FBX exporter issue, and apparently someone else reported it, and it seems to have been fixed, though I haven't tested this.
https://issuetracker.unity3d.com/issues/building-osx-standalone-with-fbx-exporter-package-installed-includes-extra-bundle-in-the-app-package

Interesting... I always wondered why deep signing didn't seem to work. Maybe it was the lower-case i. I got around it by manually signing each library, which may be a little more code, but in the long run I think it's better to know exactly what libraries are in your build.

For example, I found the hard way that the Unity FBX exporter asset ends up including a library in the build, which isn't needed or wanted. If it wasn't for the failed notarization telling me that the library wasn't signed, I wouldn't have noticed it was included in the build.

Note: I submitted a bug report to Unity about the FBX library being included in builds when it shouldn't, but I think it was largely ignored. Now I have code in my build script that checks for the existence of the FBX exporter package, and throws a warning and stops the build process if it's found.

On 2019.4.9f1 and lower, we were doing this:

1. Manually codesign everything inside "Contents/Plugins" and inside any subdirectory/framework within "Contents/Frameworks" (for example, "Chromium Embedded Framework")
2. codesign --deep at the top level (i.e. codesign --deep XXXX.app)
3. Bundle that app into another app generated by an Xcode project (Unity app sits inside "Data" within the parent app). XCode handles signing the parent app using normal xcodebuild behaviour.
4. pkgbuild and productbuild to make a .pkg, and then that is sent for Notarization.

This all worked fine.

Since we upgraded to 2020.1.6f1 however, "Contents/Plugins" has changed to "Contents/PlugIns" as-per this ticket.

Now, whether you manually codesign Contents/PlugIns or not (we assume that we must still manually sign all libs inside it because Unity doesn't do our signing as part of the build process), Notarization now fails due to "The signature of the binary is invalid.".

The only way to make Notarization pass is to rename the directory back to Plugins with a lower-case "i".

codesign -vvvv at any of the XCode-generated parent app, or the Unity-generated app passes and shows a valid certificate (and the same Developer ID certificate is used across the entire signing process and hasn't changed between 2019.4 and 2020.1), as does spctl --assess when run locally.

I expect the problem may be that Apple's documentation says this directory must be PlugIns, but in reality they've changed it.

This fix seems to break Notarization for us (2020.1.6), we've had to rename the folder back to Plugins (lowercase i).