So I want to expand upon why this is critically important, as notarization does far more than simply check for codesigning.It checks the SDK versionIt checks for secure time stampIt checks for malwareIt checks for runtime hardeningAnd yes, it checks for codesigningIt also walks every compressed file, such as jars, and jars within jars, and even jars within jars within jars, to search for any code files.It's not as simple as just signing/hardening my build and running tests, and if everything passed, I just notarize it.As indicated, complex apps use dozens of 3rd party libraries. I could sign/harden everything, run tests and pass, and absolutly fail notarization because of a 3rd party library that doesn't meet one of the requirements above.The simplest way to do that is of course to submit it for notariation. But do I actually want to create a notarization record for that 3rd party using my credentials? Uh, no. Do I want to wait until I'm ready to release before I discover that a 3rd party library I rely upon that I took a security fix is missing codesigning?Or that is has some identified malware?Or they had a regression in their pipeline and it isn't built against the correct SDK?No.As I said, it is really unreasonable if Apple expects every enterprise developer to build an internal system that attempts to do what notarization does.

Appreciate the tip regarding the undocumented support for xml output. I don't know how anyone discovered that; there is no mention of it that I can find at developer.apple.com. for those watching this thread, --output-format xml should be added to the command line. If you can find an official reference, that would be welcomed.Regarding your view on it being a release process; you are certainly welcome to your opinion. Hundreds of other develpers I've spoken to are in the same camp as me.I'm not sure the size and scope and complexity of the apps you build, but mine have dozens of 3rd party libraries, and 1000's of binaries, with multiple frameworks, such as React/Electron/Typescript/Java/Native code as within the same package. With 3rd parties being upgraded every week in our code base because of the constant identification of security issues, with 100's of developers actively working in the code base, baking these ship requirements into the 3rd party acceptance pipeline and then our build pipeline is a must.As an example, I have a jar file that has hundreds of jar files within it. Some of those jar files happen to have native binaries that require signing within them. Only through submitting for notarization did we discover that there are actually native binaries inside some jars, and that some of them are unsigned.It is completely unreasonable to expect every enterprise app company to attempt to do what notarization does in their build pipeline.