The end result is that users are left being unable to use their computers in ways that Apple doesn't like.
> The Notary service will also perform some additional checks on the application. These include security checks that verify the application is doing what it indicates as well as the check for private API usage, similar to Mac App Store apps.
[1] https://www.waynedixon.com/2019/05/16/new-notarization-requi...
https://developer.apple.com/documentation/xcode/notarizing_m...
> For example, if a plug-in employs deep integration with the host executable via C function pointer overrides, or uses a JavaScript engine for custom workflows, the host executable must declare the Allow Unsigned Executable Memory Entitlement or Allow Execution of JIT-compiled Code Entitlement, respectively. In some cases, a plug-in fails to even load if the host executable lacks the proper entitlement.
This is the best documentation I could find with a quick Google search. But basically, if you can use C function pointers, you can call anything you want and there is no way that an automated scan can detect it with the right level of indirection.
I also couldn’t find anything from the official documentation about not being able to code sign anything that uses private APIs.
But even simpler for apps that don’t actually get manually reviewed, it’s really easy to bypass.
https://medium.com/swlh/calling-ios-and-macos-hidden-api-in-...
Even if they did do something like scan for text strings in PerformSelector, that’s also easy to obfuscate.
(Or you let specific apps through Gatekeeper, or you go even further and turn off SIP... there are a lot of in-between states, but they fall somewhere on the spectrum between "trust Apple" and "don't verify trust". There's no "trust Mozilla" option.)
Seems like it is easy to trick the public into confusing one goal for another.
There seems to be an implicit rule in the Apple software scheme: Apple itself is "pre-certified" as trustworthy. Not only at the time point of hardware purchase, but endlessly into the future.
The user of course cannot revoke that "certification". The way these systems are structured today, the user effectively cannot decide after purchase "Thanks Apple, I got this. I'll take it from here." This is sort of implicit trustworthiness of hardware vendor as software vendor also underlies the contemporary concept of "updates". There is no genuine (viable) option for the user to say "no, thank you". Saying no would be deemed as ill-advised for a variety of reasons.
The one-time hardware purchase is transformed into an ongoing dependent relationship that can be, and in fact is, exploitive. Its primary reason for existence is as you suggest not to "protect" or otherwise benefit the user, but it can be contrued that way.