We have the same problem, with slight variation in our workflow:Xcode signs the app for us, then dmg creation and notarization/stapling is run via scripts/commandline. We do not sign the dmg, only the app inside it is signed - which should be fine; we can still notarize and staple the dmg with success ("accepted", "Notarized Developer ID", "Ready for distribution", etc). Upload to a website and download via browser (Safari/Firefox), install from dmg, spctl then still says "accepted" and "Notarized Developer ID" for the app, but Gatekeeper apparently rejects it with dialog on app startup:<app> cannot be opened because the developer cannot be verified.Still no solution, reported to Apple.

We're running it all on macOS 10.15.2.

I should also clarify that the notarization result is success without any warnings/issues.

Thank you for the linked tips! This is really useful info, and I think hints of this dimension should be much more visible in the official pages, like maybe one of these:https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distributionhttps://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issuesOur problem turned out to be Xprotect service that logged "Error" about useless/misleading embedded LC_RPATH settings in a couple of our .dylibs bundled in the app. This never showed as a problem in any other way, since the correct search paths are there too, so our app could execute fine anyway (in developer build).The bundled dylib is 3rd party, so we ended up having to fix it before bundling withinstall_name_tool -delete_rpath ...(That makes me wonder, is it ever a good idea to have LC_RPATH settins at all on dylibs? Shouldn't that always be set on executables only?)Also, the error message in the GUI dialog from Gatekeeper is really, really bad - misleading.BR,Martin