I understand that you're doing it on principle, but for a software development team, 99$/year is a really minuscule price to pay to be able to build / notarise / distribute software.
Developers pay exorbitant amount of money for much lesser value, and the idea of putting your teammates at risk to stick it to apple is kind of sad bordering with negligence from a business POV.
The principle is what matters. The amount is not the issue. The issue is that there is a cost at all. "It's so cheap" is never an excuse for charging for something that should be free. In this case, running software you have no intent to charge for, on your computer. It's as if someone started charging $0.01/month for breathable air. "But $0.01 is trivial," would not excuse it.
It costs money, and isn't free, for a reason you're not acknowledging. I don't think it's a major profit center for Apple.
It's about setting a higher floor for malicious actors than "random botnet residential IP + a captcha solving service". It's about proving some semblance of identity through a card number and a transaction that goes through without a chargeback.
As the case upthread shows, there's plenty to dislike about a system that inhibits running code built for personal use. And it's obviously neither foolproof nor without collateral damage. Reasonable people can debate if it's worth it. But it still ought be acknowledged that the motivations are closer to the reason you have to identify yourself and pay a nominal fee to drive a vehicle on public roads.
I don't buy it. Or rather, I am willing to believe that some team at Apple has convinced itself that this makes sense, but they're wrong.
In particular, the security boundaries are nonsensical. The whole model of "notarization" is that the developer of some software has convinced Apple that the software as a whole (not a specific running instance) is worthy of doing a specific thing to the system as a whole.
But this is almost useless. Should Facebook be allowed to do various things that can violate privacy and steal data? What if the app has a valid reason to sometimes do those things?
Or, more egregiously, consider something like VSCode. I run it, and the fancy Apple sandbox helpfully asks me if I want to grant access to "Documents." The answer is really "no! -- I want to grant access to the specific folders that I want this workspace to access", but MacOS isn't even close to being able to understand that. So instead, one needs to grant permission, at which point, the user is completely pwned, as VSCode is wildly insecure.
So no, I really don't believe that MacOS's security model makes its users meaningfully more secure. At best, the code signing scheme has some value for attribution after an attack occurs, but most attacks seem to involve stolen credentials, and I bet a bunch just hijack validly-notarized-but-insecure software a la the VSCode example.
Notarization is not a trusted system on macOS - or rather, notarized binaries still have a "this was downloaded from the internet" prompt, and the user is meant to make a decision on whether it is trustworthy.
Notarization does some minimal checks, but is mostly about attaching a real identity so that maliciousness has at least some real-world consequences. The most obvious being that you lose the ability to get more apps notarized.
Actually the cost is not the issue (you are paying for it one way or the other), the issue is the authorization to do such an action on your (supposedly) own hardware.
Adding signing as a requirement can easily make what was once a very simple distribution mechanism into something much more complex - now you need manage signing certificates and keys to be able to build your thing.
In contrast to this point, as long as I use Xcode and do the same thing I've always done allowing it to manage provisioning and everything else, I don't have a problem. However, I want to use CI/CD. Have you seen what kind of access you have to give fastlane? It's pretty wild. And even after giving it the keys to the kingdom, it still didn't work. Integrating apple code signing with CI/CD is really hard, full of very strange error messages and incantations to make it "work".
I don't know about fastlane, since my CI/CD is just a shell script, and signing and notarising is as hard as (checking the script) running `codesign ...` followed by `notarytool submit ... --wait`
Yes, you need to put keys on the build server for the "Developer ID Application" (which is what you need to distribute apps outside of AppStore) signature to work.
You do not need to give any special access to anything else beyond that.
Anyway, it is indeed more difficult than cross-build for Darwin from linux and call it a day.
You seem to be comparing a single dev sending apps to the world vs a corporate team pushing to employees (if I get parent's case right).
In most cases, just involving account management makes the corporate case 10x more of a PITA. Doing things in a corporate environment is a different game altogether.
Do you distribute OSS software which requires notarizing? If so, have you found a way to let the community build the software without a paid developer account? I would be very interested in a solution which allows OSS development, relying on protected APIs without requiring that anyone who builds the app to have a paid developer account.
Code signing is absolutely disgusting practically and philosophically. It has very reasonable and good intent behind it, but the practical implementations cause great suffering and sadness both for developers (cert management, cost, tools) and end-users (freedom of computing).
The tool is built deep in our CI/CD chain. The whole thing is a house of cards built on a massive pile of tinder next to an open drum of kerosene. You want me to integrate XCode into that?
Last time I tried setting up an Apple developer license inside a large corporation, one that they paid for and not tied to me or my credit card, it was also a nightmare.
Who said anything about Xcode? The codesign tool is part of macOS, not Xcode. The CLI tool for notarization is bundled with Xcode, but you don't have to use it; they have an official REST API that you can use directly.
Sure it's trivial, but it is tacit acceptance that you need permission to make a program on their platform. Permission that needs to be renewed year over year. Permission to earn a living on this platform.
Permission that can be revoked for any reason, including being compelled by someone with more power than Apple.
Developers pay exorbitant amount of money for much lesser value, and the idea of putting your teammates at risk to stick it to apple is kind of sad bordering with negligence from a business POV.