Apple's codesigning "just works" as long as you stick to XCode. Outside XCode it's extremely esoteric and opaque.
But to Apple's credit, it can be done, and done using the native toolset. It took me awhile, but my relatively simple Makefile is building fat binaries (x86_64 + arm64), building and signing the application package, submitting the package for signing, and stapling certificates. Not monolithically--it's not a giant shell script posing as a Makefile. I have proper, correctly defined build dependencies for every real target up to `make submit`. So `make submit` will effectively build and submit a package both from a fresh checkout, as well as incrementally from an existing tree where only a few object files need rebuilding. But `make submit` and `make staple` themselves are .PHONY targets; they're not idempotent, but invoking them multiple times is still benign.
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.
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.
But to Apple's credit, it can be done, and done using the native toolset. It took me awhile, but my relatively simple Makefile is building fat binaries (x86_64 + arm64), building and signing the application package, submitting the package for signing, and stapling certificates. Not monolithically--it's not a giant shell script posing as a Makefile. I have proper, correctly defined build dependencies for every real target up to `make submit`. So `make submit` will effectively build and submit a package both from a fresh checkout, as well as incrementally from an existing tree where only a few object files need rebuilding. But `make submit` and `make staple` themselves are .PHONY targets; they're not idempotent, but invoking them multiple times is still benign.