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.
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.
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.
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 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.
Since this isn't true, no acknowledgement required, it doesn't need to be a "major" profit center to magically become a benevolent feature
For your personal needs, you do not need to pay anything for building and using apps locally.
The cost is far far higher than the price.
I develop and distribute few free apps for macOS, and building / notarising is never a problem.
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.
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.
It is ugly: https://hearsum.ca/posts/history-of-code-signing-at-mozilla/
I do this professionally, I maintain macOS CI workers for my employer. Apple doesn't make it easy.
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.
And yes, it's also on principle.
Permission that can be revoked for any reason, including being compelled by someone with more power than Apple.
Once signed, binary will work forever, you only need active subscription when you need to re-sign / re-notarise.
Do you have any evidence that it happened in any different circumstances at least once?