No I did not find a way, and last I created a little "menu-bar app" with that tiny icon, that my launch-agent launches when it needs to communicate with user, and via XPC I direct the information to that app, which in turn creates the local notifications using UNNotificationCenter. I could not use the older NSNotificationCenter, because I need many of the newer features of UNNotificationCenter (coalescing and grouping user notifications, customizing their UI, adding user-options etc.) The important thing is, when you "click" a notification in the user-notification-center, MacOS launches the App that created and sent that notification - and sends it a delegate call with lots of information, to continue the dialog with the User. A LaunchAgent like mine, has very dull UI and most of the time it doesn't "remember" a user's state. Anyway, one thing I did test with - and didn't work as well - was to apply a "bundleId" directly to the binary - something I didn't know existed before, but Xcode knows to do that. So a single binary agent/daemon CAN have a "signature" of the "com.mycompany.myagent" type. UNNotificationCenter doesn't respect that signature though.

Thanks, but NSNotificationCenter is both deprecated, and does not provide some of the features I need. I resorted to the cumbersome combination of LaunchAgent and a menu-bar-app, negotiating via XPC. So when my LaunchAgent wants to notify user, it sends an XPC call to the menu-bar app, which in turn creates and dispatches a UNNotification. It IS cumbersome and ugly and requires maintenance and a whole mechanism of launching/updating/quitting the menu-bar-app, not to mention the mach-service XPC listener in my LaunchAgent and so on. Please be kind and notify here if Apple takes it to improve UNNotificationCenter to use "signature" of a binary, in cases where a code-bundle isn't available. After all the reason to have LaunchAgents - is to have UI for a background daemon.

So.... if that call isn't available to us mere NSXPCConnection users, what could we do instead? I'm verifyng caller at the - (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection; level, identifying the caller by PID, but every once in a while         NSDictionary *attributes = @{(__bridge NSString *)kSecGuestAttributePid : @(clientPID) };         OSStatus status = SecCodeCopyGuestWithAttributes(NULL, (__bridge CFDictionaryRef)attributes, kSecCSDefaultFlags, &dynamicCode); crashes my XPC Service, with nice stack somewhere deep in SecCodeCopyGuestWithAttributes: ` 0 libsystem_kernel.dylib 0x183dcd9b8 __pthread_kill + 8 1 libsystem_pthread.dylib 0x183e0115c pthread_kill + 288 2 libsystem_c.dylib 0x183d3e314 abort + 164 3 libsystem_malloc.dylib 0x183c23a1c malloc_vreport + 552 4 libsystem_malloc.dylib 0x183c38c8c malloc_zone_error + 104 5 libsystem_malloc.dylib 0x183c15db0 nanov2_allocate_from_block + 568 6 libsystem_malloc.dylib 0x183c153a4 nanov2_allocate + 128 7 libsystem_malloc.dylib 0x183c152c0 nanov2_malloc + 64 8 libsystem_malloc.dylib 0x183c32770 _malloc_zone_malloc + 156 9 CoreFoundation 0x183e5ab0c resolveAbsoluteURLStringBuffer + 1012 10 CoreFoundation 0x183e5a678 resolveAbsoluteURLString + 188 11 CoreFoundation 0x183e58744 CFURLCopyAbsoluteURL + 568 12 CoreFoundation 0x183f6f750 _CFURLCreateWithFileSystemPath + 2236 13 CoreFoundation 0x183eb874c _CFBundleCopyExecutableURLRaw + 320 14 CoreFoundation 0x183eb84e0 _CFBundleCopyExecutableURLInDirectory2 + 452 15 CoreFoundation 0x183f37ff0 _CFBundleCreateWithExecutableURLIfLooksLikeBundle + 128 16 CoreFoundation 0x183f37f24 _CFBundleCreateWithExecutableURLIfMightBeBundle + 20 17 Security 0x1860d3d18 Security::CodeSigning::KernelCode::identifyGuest(Security::CodeSigning::SecCode*, __CFData const**) + 544 18 Security 0x1860ab040 Security::CodeSigning::SecCode::identify() + 96 19 Security 0x1860ab8c0 Security::CodeSigning::SecCode::autoLocateGuest(__CFDictionary const*, unsigned int) + 188 20 Security 0x1860b2318 SecCodeCopyGuestWithAttributes + 144 21 xpcj 0x11706c3b0 -[OITContentScanningXPCService listener:shouldAcceptNewConnection:] + 556 (OITContentScanningXPCService.m:209) 22 Foundation 0x184e274c8 ` So... how to go about this, and is it better to use the kSecGuestAttributeAudit instead of the kSecGuestAttributePid when calling SecCodeCopyGuestWithAttributes ?

I already went so far as to not-find the libmagic (or its headers, or its similarly-named filemagic friend) and I think the reason is different - I think MacOS uses a different 'magic' format, probably more powerful, as it can identify quite complicated files, and also minor version differences in these file formats - it may be that the implementation is completely different. Also Apple states the '.mgc' file is "compiled" (it is by all means 'binary' file) which also makes me think it is something proprietary. That's why I'm asking for an API... I know it wouldn't be easy to mimic this myself, or even read that magic file.

Thanks a lot for your answer. I dreaded it will be like that... In my situation, I think linking in libmagic (I still need to understand how, and where to get its code from) could serve me best, since the magic database isn't really changing format so often, while our product is bound to regularly evolve and be released. I believe Apple database is much better than anything I could come up with. Is libmagic part of Darwin? Is it different than the several open source versions I can find in GitHub, SourceForge.net openhub etc.? Another question (regarding the 'file' command). Is there a way to "wrap" an instance of 'file' as a daemon, regularly receiving input via stdin, and emitting its result to stdout, sparing the need to spawn it again and again? That may be slower than directly using libmagic, but bound to be much faster than spawning NSTask for every file identified. I'm not a unix wiz, so I don't know what's available to me in that respect.

For the record, here is the feedback ID of my official request: FB10027841 It contains more or less the same description as in my question here - please review and let me know If something important is missing from my description

I think the C API allows for bi-directional messaging, whereas NSXPCConnection is (to my best understanding) one-way. Also NSXPCConnection implementation only supports very limited set of Foundation classes you can send as arguments in XPC messages, whereas the C API allows encoding almost anything. I think the control is also more fine-grained, but I may be wrong. BTW - the question is "can LaunchAgent publish XPC service" ? in which domain?

Thanks. I now spot a typo in my suggested code, where I used the wrong tv_sec twice - both for seconds since 1970 and for the nanosecond part. should be tv_nsec instead for nanoseconds. Also instead of dividing directly by 1e9 I could use the nicer NSEC_PER_SEC definition for clarity. Would fix that in the question, but I can't see a way to edit my old question now.

Is there anything in common for all the things installed in /Library/Apple/ ? I seem to see things related to malware detection and removal, and things like that... Is there a better description for what's in there? The directory structure of MacOS becomes more and more frustrating, and there is no coherent source for learning about it.

Pity it's not visible to anyone but the author (and Apple, hopefully) click on the Feature request link gets nowhere.

Thank you very much. Fortunately I have a very cooperative customer with someone eager to help resolve the issue. However - he sees the problem the next morning. It happens when he's home, and his office-Mac is asleep. Can sysdiagnose help if it's run hours after the issue happened?

I looked again into my code just to be sure. The first thing in my ES message-handling code-block is:     if (msg->process->is_es_client) return YES; // Immediately authorize this message - clear any other ES-client process So actual "deadlocking" by another ES client is not likely.

Wow... Thanks for this answer. It brings back memories :) for me at least - good memories. Anyway, a remotely-related question. If I register my ES Client to the ES_EVENT_TYPE_AUTH_COPYFILE (in documentation - only available on MacOS 12 and on) on older OS (10.15.x or 11.x) Will this be accepted, only I will never observe the event, or should I refrain from registering the event on older OS versions?

What I do in such scenarios, is create a local NSWorkspace class extension (category) overriding the failing method/property-getter, and introducing my own workaround/fix there. Since loading a Category in ObjC virtually "overrides" the original method - you're other code can continue use NSWorkspace API, and will use your workaround for as long as it is needed. When Apple fixes their bug - you just uncheck that source from your target in Xcode (cease to compile and link it into your binary)...

Thank you, I already found these two sources, and while the first (Apple documentation) seems to be the thing I'm trying to do - it is iOS only, and there is absolutely no hint on how to implement this on the Mac. The whole setup there is iOS-focused, and I don't know how to even create a template for this special "notification extension" target type in Xcode, and whether or not this is supported. Apple really leaves me in the dark here - Maybe the APIs are private?