If they're notarized there's around a hundred pages of terms and conditions you have to agree to. Although I'm not sure this gets in the way of any of them except on one of the blanket ones that Apple keeps intentionally vague.
I literally just went through them at work in preparation for Catalina. They're hidden behind the developer account stuff you need to get your certs registered.
And you are not forced to abide by the developer terms to release a program for the Mac just as I said. Despite all of the HN conspiracies, you can develop for and release code on the Mac without Apple’s permission. You don’t have to abide by those terms.
The Zoom and BlueJeans apps are both signed, which indicates they're part of Apple's Developer Program, and thus bound by its terms.
If you want to distribute an unsigned app and guide users into bypassing Gatekeeper for it, by all means, do so... but that's not what's happening in this case, nor is it particularly common due to the intentional hoops they make you (or more accurately, every single prospective user of your app) jump through.
Wait a while. Holding one's breath not recommended.
For those who don't want to (or cannot, due to the nature of their application) use the Mac App Store to distribute software, the requirements will only continue to get more specific until (to the extent possible) all executable code and resources are notarized and signed with an identity.
<Insert Perry the Cynic rant about unsigned code - "What the hell is wrong with you!?">
This same prediction has been going on since 10.6 - over 7 versions ago. How do you propose that Apple forces code signing on programs that run on top of a VM like the CLR or JVM? How do you propose they enforce it for programs run using a scripting language? The best they could do is force signing on the runtimes.
But my point still stands. Today on July 9th 2019 you are not forced to be part of the developer program to distribute apps on the Mac. Despite all of the pollyanish the sky is falling type that has been going on for over a decade.
Not to put too fine a point on it, but those examples don't pass muster.
- If you're not using .NET, the CLR doesn't affect you, and although Microsoft has done well with ,NET, I wouldn't necessarily expect Apple to make Redmond's job easier.
- Java is much the same boat, and is perhaps in even worse shape as it used to be included by default in macOS releases but now isn't.
Read: security nightmare.
- From 10.16 on, scripting languages also aren't included by default. This seems less adversarial than the situation with Java, but for things like Homebrew, it's a stumbling block they will need to overcome.
Apple introduced the Mac App Store over a decade ago. Since then, conspiracy theorists have been predicting that Apple will force all apps to be signed.
Are you predicting that Apple will disallow all scripting language runtimes and all VM based development environments? So if these same predictions have been wrong for over a decade - and still aren’t happening with 10.13, exactly when will this happen?
As far as Apple not including (outdated) versions of various scripting languages or Java - neither does Microsoft. That hasn’t been a major impediment to adoption.
My statement was very clear “developers are not forced to be part of the developer program.” Meaning that unlike ios, there are ways to distribute your app without signing it. “Notarization required by default” != “there is no method to distribute unsigned apps”.
Catalina still runs apps which haven’t been notarized or even signed, including those built after 1 June 2019. But you may find them more complex to run, and they don’t of course benefit from any of new security protection unless they’re signed and hardened.
I'm fairly certain you have to agree to some to join the Apple Developer Program, which is (sort-of) required if you want people to be able to run your app.
First, the dialog doesn't give any indication it can be bypassed in that fashion. Second, users should rightfully be suspicious of "just bypass the security!" install instructions - especially non-technical ones.