Here Developer ID + Notarization qualifies as "identified developer", not "App Store" (as in the Security & Privacy preference pane). There are tools to simulate an App Store install, but I don't think they change the Gatekeeper designation.

You might want to post the exact command you're using to load, whether you're running it as root, and whether a command like kextutil -tn <kext> complains about anything

There are a few ways to handle per-daemon credentials, one is: Make a directory dedicated to your service (e.g. /var/<name>) with 0700 permissions Put a new keychain and text file containing its password in the directory At launch, your daemon unlocks the keychain using the file, and sets any settings (e.g. disable lock on sleep, etc) Continue to use ACLs on keychain items so only your daemon process has access Another thing I've done with various unprivileged services is to have a special "root" mode where the process checks the euid at launch, and if running as root it performs setup actions (like creating the directory and contents) and/or fixups (fixing permissions, checking for other issues, etc), then immediately exit (refuse to run as root). It's easy to run from a PKG's postinstall script, keeps the configuration information out of other files like scripts, and could do the kind of maintenance that daemons sometimes require. It should ignore command-line arguments in that mode for safety's sake though.

You mentioned using Chrome, a notorious memory hog. Have you thought about splitting your work across browsers for the sites that might be compatible? The compression algorithm is documented in WKdm_new.h - https://opensource.apple.com/source/xnu/xnu-6153.141.1/osfmk/vm/WKdm_new.h.auto.html (implementations are per-architecture assembly), and you may also be interested in vm_compressor_backing_store.h - https://opensource.apple.com/source/xnu/xnu-6153.141.1/osfmk/vm/vm_compressor_backing_store.h.auto.html

It's controlled by the SMC, now in the T1/T2 chips. If you want to investigate on Intel/ACPI machines, extracting one of the SSDTs should essential reveal the fan response curve, but it's not meant to be configurable. Having said that, Macs tend to favor silent operation where possible. From what you describe, it sounds like an app may be misbehaving by either spinning where it shouldn't, or failing to respond to the thermal notifications.

Depending how careful you are, it's possible to accomplish the whole thing in a category on NSTableHeaderView (for standard TableViews). It wouldn't allow multiselection, but would immediately apply to all TableViews. Override -[NSTableHeaderView menu] to generate one if not already set, store it, then set the delegate to self Implement the NSMenuDelegate methods to populate the menu when opened (really just before) Implement an action to handle the NSMenuItem click and setHidden: on the NSTableColumn

I'll break down my last comment into parts: The custom resource rule isn't used for executable code The custom resource rule applies in Resources/ The custom resource rule might apply to something which has a different customization mechanism The custom resource rule might apply to something which has a different customization mechanism, which also doesn't affect the signature For example, icons have customization mechanisms which don't affect the signature The effective icon (reference to the getter in NSURL, custom icon is unimplemented, must be set with NSWorkspace) does not affect the signature (tested using codesign -v -vv and Finder Get Info) The effective icon has no effect on the signature, unlike Info.plist and Resources/*.icns, which some might use without realizing another method is available

If the exception isn't for executable code, have you thought about a different mechanism? For example setting the effective icon (rather than Info.plist + Resources/AppIcon.icns) doesn't affect the signature. Depending how the app uses the file, the custom resource rule would open a vulnerability to attacks anyway.

A standard installation should have e.g. /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/CDAudioVolumeIcon.icns. Is it missing from your copy?

The report is pretty clear about thread 19, and frame 13 com.avaya.Avaya-Equinox&#9;&#9;&#9; 0x000000010d26a64a 0x10ce40000 + 4367946 is unsymbolicated. That should indicate which part of the app is causing the issue

Depends what you're looking for. Most icon files are ICNS (a few are TIFF or PNG), then there are the art files, and also SF Symbols (which is distributed as an app).

It looks like you're trying to find the dynamic library file in the framework using the filesystem (instead of dlopen(3)), this behavior has now changed in Big Sur, see the Release Notes - https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)

So long as you're ok with the restriction that receivers of these shared droplets must also be users of your app, I don't see an issue. The idea behind com.apple.application-instance is you're uniquely identifying the particular instance of a script or other automation without relying on naming/path/etc. Your app stub looks up its UUID in the local, though shared, database of droplets and executes the particular action stored there. When one user shares an "app" with another, your solution merely packages the database record in a file, which is then reconstituted into an app stub by the recipient. If on the other hand your solution was a generic app creator/maintainer, that is fundamentally incompatible with code signing/notarization/sandboxing/etc unless you also require your users to have development toolchains available (which you might automate for them).

For practically every entry in Privacy there's a specific API you'd use, either to check (newer) or just to access the resource you want (system will automatically prompt). Some, like Automation (AppleEvents) require this new check (AEDeterminePermissionToAutomateTarget), and for Accessibility I believe it's AXIsProcessTrustedWithOptions, and to request a prompt.

You may not have much of a choice to use the UUID because there is no other mechanism which doesn't disturb the signature. Do your users actually have to share the .app directly? Seems unnecessary so long as the user on the other end can create an app from whatever the sharing mechanism is. The indirection part doesn't really apply in your case because you don't have optional content which is also signed. The idea is you would bundle the optional/replaceable part, sign it, and put it in the app (or other bundle), instead of directly modifying files in e.g. Resources/. Then it says these bundles don't actually need an executable, they could just contain other resources.