I'm not sure if this is the problem, but the location of the dylib in your bundle is peculiar. For one thing, the Resources folder is not one of the standard locations for nested code, according to the macOS Code Signing in Depth technote. Also, that document says The code signing machinery interprets directories with periods in their names as code bundles and will reject them if they don't conform to the expected code bundle layout. so that ".dylibs" folder could be a problem.

Does the name Dragan Milic appear in your Info.plist file (the one for the main app, not the one for the helper)? I bet it's coming from there, not from the code signing information.

What's the numerical error code?

There actually is a hacky way to close other apps from a sandboxed app: Given accessibility permissions, you can send command-Q keystroke events to another app. I think there should be a cleaner way for a sandboxed app to close other apps, with some permissions and/or entitlements. I've sent FB11876087 about it.

You did export it after notarizing, right? It might help to see what you get when you check your app with the free utility What’s Your Sign?. I was going to link to it, but for some reason they don’t allow links to Objective-See on this forum.

I just look through a dozen or so 3rd-party apps, and they all contained Contents/Info.plist. Can you give any examples where it's not there? (As for "several in different subfolders", an app may contain bundles or frameworks, each of which contains its own Info.plist.)

I always download Xcode from https://developer.apple.com/download/applications/ rather than the App Store, and then I change the name, for instance Xcode14.2 instead of just Xcode. So I can have several different versions of Xcode, and I’ve never had one of them disappear.

The documentation says Key-related events may only be monitored if accessibility is enabled or if your application is trusted for accessibility access (see AXIsProcessTrusted). See also AXIsProcessTrustedWithOptions and the newer APIs CGPreflightListenEventAccess and CGRequestListenEventAccess. For instance, when you program is starting up, you might call CGPreflightListenEventAccess, and if that returns false, call CGRequestListenEventAccess.

I can't really answer your specific questions, but I would remark that macOS has multiple layers coming from different eras, somewhat like an archeological dig. Some of the newest APIs can only be used with Apple's new favorite language, Swift. Dig a little deeper and you find lots of APIs designed for use with Objective-C (though they can be used with Swift too.) Below that, there are POSIX APIs coming from the FreeBSD heritage of Mac OS X. And there are still a few working APIs that date back to the pre-Mac OS X days. As a result, there are often multiple ways of accomplishing a given task, such as networking.

If I do defaults domains, then the resulting domain list does include what I was expecting, of the form <team ID>.<suite ID>, but when I say defaults read <team ID>.<suite ID>, it replies Domain <team ID>.<suite ID> does not exist. (I copied and pasted from the defaults domains output, to make sure I wasn't making a typo.)

macOS apps definitely still have Info.plist files, but you may not be directly editing it. Rather, it may be generated based on settings under the Info tab in your target settings, and values in the Info.plist Values section under Build Settings. I would agree with that other thread that you should look for a plist setting that allows "sudden termination".

The docs on NSApplicationWillTerminateNotification say it is "Posted only if the delegate method applicationShouldTerminate: returns YES". Do you implement that method?

I see now that there is a partial workaround. So long as the mouse is actually dragging data, as opposed to, say, dragging out a selection rectangle, one can register for dragged types and override draggingEntered: and draggingExited:

It turns out that the Carbon function SetFrontProcessWithOptions, deprecated since 10.9, does bring all the windows forward. The documentation says "Passing 0 for the options is equivalent to calling SetFrontProcess", but that's not true, SetFrontProcess does not bring all the windows forward.

When you click an app in the Dock, all the windows come forward. Looks like it's using some private equivalent of SetFrontProcessWithOptions.