I agree on the code signing. I wrote an app in LispWorks Common Lisp, and other people use the same for apps for the Apple Store, I ended up just rewriting it in Swift and SwiftUI because that made dealing with the Apple Store so much easier.

I implemented the codesigning and notarization process for Slippi, which is a Dolphin Emulator fork... based on CMake.

I would not call it esoteric and/or opaque. It's one or two shell scripts and an API key through App Connect for the notarization pass.

It's certainly esoteric if you're trying to diagnose entitlement issues. It's all poorly documented. Some of the documentation on the Apple website is flat out wrong, for example recommendations on signing multiple separate binaries, each requiring an entitlement (spoiler: there's exactly one app id per package (EDIT: per bundle), and exactly one executable that can use that app id for entitlements, so the documentation was recommending a method of accomplishing something that is simply impossible, which explains why it never worked).

Once you figure things out, it's not nearly as bad. The tools can work well. And that's hugely valuable. But documentation and consistency are significantly worse than common open source projects. And at least with open source you can also resort to looking at the code to figure things out. I find myself constantly doing that for Keychain, actually. Fortunately older versions of Apple's Security.framework are open source, which helps me diagnose and analyze API usage problems. Want to figure out how to retrieve the usage constraints (i.e. SecAccessControlCreateFlags) used to generate a T2 Secure Enclave private key? Or even simpler, want to figure out if its even possible to derive those constraints? Only the code is going to tell you.

Have you, or do you intend to write a blog post about your process? Could help other devs working on Macs.