The bigger difference is that Apple isn't just checking for malware, it's checking for conformance with various APIs, manifest requirements and so on. Not as strict as the iOS App Store, maybe, but it will refuse to notarize if it detects use of unsanctioned API calls.
You don't even need signing for Microsoft's system to do what it does - it can operate on unsigned code, it's all hash based.
> it will refuse to notarize if it detects use of unsanctioned API calls.
Or really any reason. They're not supposed to exert editorial control but that's how it has been happening in practice.
> detects use of unsanctioned API calls
Is there a concrete example of this? We know this isn't blanket policy, because of a recent story (https://news.ycombinator.com/item?id=45376977) that contradicts it. I can't find a reference to any macOS app failing notarization due to API calls.
Notarization doesn't blanket block all access to private APIs; but the notarization process may look for and block certain known accesses in certain cases. This is because notarization is not intended to be an Apple policy enforcement mechanism. It's intended to block malicious software.
So in other words, using private APIs in and of itself isn't an issue. Neither is it an issue if your application is one that serves up adult content, or is an alternate App Store, or anything else that Apple might reject from its own App Store for policy reasons. It's basically doing what you might expect a virus scanner to do.
Yeah, don't disagree with any of that, but I'm looking for explicit evidence that that is true (right now it sounds like it's just an assumption)? E.g., either examples of apps failing notarization due to API calls, or Apple explicitly saying that they analyze API calls. Without that it sounds like we're just guessing?
I have experienced it myself but this was some years ago, may not be current. Think it was things they were trying to deprecate, which are now fully gone - was around the time they introduced Hardened Runtime, 2018-19 ish.