The plugin issue described in the article is probably related to the hardened runtime, so it's unrelated to the actual notarisation process.
./notary.sh notarize app.dmg
./notary.sh staple app.dmg
And for what? There is no way Apple can make it impossible to get malware notarized.
Some people (are they the minority? probably?) cut release builds frequently enough for it to be a big pain point.
> and so you have to sign in and accept an agreement - [which isn't] a big deal
It probably is though. Have _any_ agreements you've accepted in the last, say, 5yrs not had blatantly overbearing or malicious terms?
Signing the agreement is also not just clicking “Agree”, you have to hunt for the contract online first. Last time I did this, their 2FA was down, so just logging in took me about a minute.
It feels like a lot of friction that serves absolutely no purpose, which makes it so extremely infuriating.
This is from the same company whose former CEO pressured a developer to reduce the boot time of the Macintosh (and got a 28 second speedup).
Yes, this stuff really matters to a lot of us!
The trouble I ran into was this: Apple wants the process to be a little mystifying as a barrier to people trying to find exploits within it, I think. I disagree: for instance, using a shell script and the Apple terminal tools is very much the Apple-intended approach, but integrating the third party tool got me sending code to Apple's servers quicker, and it's those servers that matter. I wasn't considered a significant developer to Apple, nor will I ever be, but I code open source software that's being adopted by other projects and used as an on-ramp for would-be DSP coders: my choices and attitudes matter.
Apple in the form of a key Gatekeeper dev had very specific intentions for me: I was strongly advised to use automatic code signing in XCode and use Terminal and a separate workflow to remove the incorrect cert that Xcode assigns, and put in the correct one (Developer ID Application, in this case).
Apple's defaults for an XCode application (written in Swift, because of course it is) and automatic signing, work perfectly first time for something like their example 'hello world' app. For any Audio Unit, this fails every time. You can set it correctly inside XCode from the start, using manual settings. I chose to do this.
Near as I can tell, I am expected to have a manager to whom I will turn over code, and who is the only one with a code signing ID, because as a lowly DSP coder I'm not expected to be allowed to put code out into the wild without supervision. There's a clear expectation that if I mattered, I'd either be the boss of (not necessarily trustworthy) coders, or I'd have a boss whose job it is to be more trustworthy and oversee my code in case I have a wild hair some day and code a bomb into things. I feel there's a resistance at Apple to putting the keys to distribution into the hands of untrustworthy people. Perhaps a belt and suspenders approach? I'm not convinced this is in any way a good thing, though.
Doing the code signing correctly, which is not the same thing as having an Apple-specified process, means every bit of code I generate gets checked for malware by an Apple process. This could save my butt if I got owned by some extremely clever second-level malware that tried to commandeer my XCode and build malware into everything I make. I get that there are also possible risks with having every executable sent to the mothership to be studied: if I competed with them, that's wildly anticompetitive and lets them decompile and pirate anything I do (given sufficient effort). I'm literally sending them all my work before anybody else ever runs it.
I feel that this type of risk (which I'm not convinced is a currently active threat) is better handled by government, regulation, and the law, than by forcing the software ecosystem to normalize running any old code from anywhere.
Doing Apple notarization the way Apple wants it done, should be a nontrivial factor in keeping Apple products from being a giant pile of malware, spyware, and user-manipulation in future. If you're able to do it properly (as in, get the code AUDITED, not 'do it only the way Apple says') the result is distributed plugins and applications that 'just work' the way they used to, but without the same level of risk to the end user.
I think it's worth the trouble to do this. The benefit is clear, and possible dangers of the approach belong to the legal sphere rather than being a technical reason to avoid code signing, or normalize having everybody avoid code signing on your behalf.