Thank you so much for the elaborate and helpful reply. I will try to address each point, to try and see how to "close in" on my problem. I will also attach a sample crash-report. My "rule engine" is very fast, based on NSPredicates over ObjC custom classes (No core-data etc.). Rule evaluation is completely internal to my daemon, no API calls and no external calls. There IS , however a stage prior to rule evaluation, where I Parse ES messages into my custom ObjC class, and in that stage there are few API calls one of which has given me grief in the past. I need to decide whether a file-system object (from the ES message) is a "Document", in my own semantics. A document is any "normal file", or -- "package" directories. If the file-system object exists and is a directory, and it has a file-name extension, I use something like: _isDocument = [[NSWorkspace sharedWorkspace] isFilePackageAtPath:_filePath ]; If it is non-existing (to be created etc.) Then I use this heuristics and API: { // non-existing directory object about to be created... NSArray<UTType *> *types = [UTType typesWithTag:_filenameExtension tagClass:UTTagClassFilenameExtension conformingToType:UTTypePackage]; switch (types.count) { case 0: _isDocument = NO; break; // no package type with this filename extension known to LaunchServices. case 1: _isDocument = ! [[types firstObject].identifier hasPrefix:@"dyn."]; break; default:_isDocument = YES; break; } Both APIs boil down to LaunchServices calls, that MAY be extenal, and which notoriously "hang" for long periods sometimes. However - these things almost NEVER happen to my ES daemon in normal use (no such crash-reports from 100K+ deployments) but around Mac sleep cycles, this DOES happen. I DO NOT currently employ an active mechanism to "short-circuit" my evaluation of events. What I have instead is: Lots of "white-listing" (large list of "muted" binaries and processes for ES. Events I never receive. If I receive an event with <50 milliseconds deadline, I "give up" and authorize immediately. I subscribe to small set (8) of file-system events, that usually come with 30-60 sec deadlines. mostly open/create. Never read/write. Of course I see much smaller deadlines, but I NEVER saw in my logs a "give up" because of tight deadline. My rules-engine has been tested with at least million events per sec, and it is indeed very fast. ITProtector-2026-02-18-172637.ips.txt ITProtector-2026-02-18-093300.ips.txt ITProtector-2026-02-21-055538.ips.txt I will be happy to share with you parts of my code, but I cannot post publicly - this is corporate proprietary. Please let me know any private e-mail or other method I can send you relevant parts. Thank you so much!

That should be it. Thank you. But I urge you to re-read the "canonical" documentation in the headers. The difference you point here (between PATH_TYPE_TARGET_LITERAL and PATH_TYPE_LITERAL is not written there. The very simple distinction between "the path of the executable creating the event" and "the path of the file which is the target of the event" -- is simply not there. I understand now that these paths can sometimes coincide, but I think the documentation lacks proper explanation for the "use case" of these 4 different path "styles". Thank you - I will test with the newer API with the (hopefully correct) path style, and see that indeed events are muted.

The edge cases and qualifiers you provide here are very far from my needs. Most executables I want to mute are well protected by SIP, and will never move (MacOS private frameworks, daemons etc. plus few third-party that are also very well defined). My issue is very blunt. I mute a simple and perfect executable path. Here are some - my list is much longer, but you'll get the idea: +(NSSet<NSString *> *) baseBinaryPathWhitelist { static NSSet *_baseBinaryPath = nil; // any executable in these specific paths will be ignored static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _baseBinaryPath = [NSSet setWithArray: @[ NSProcessInfo.processInfo.arguments[0], // don't inspect our own ITProtector process. @"/sbin/launchd", @"/bin/launchctl", @"/bin/ps", @"/bin/sleep", @"/usr/bin/dscl", @"/usr/bin/log", @"/usr/bin/vmmap", @"/usr/sbin/syslogd", @"/usr/sbin/spindump", @"/usr/sbin/usernoted", @"/usr/sbin/securityd", @"/usr/sbin/ipconfig", @"/usr/libexec/biomesyncd", @"/usr/libexec/logd"]; But when I use the newer API (that you say is identical to the old, or rather that the 'old' API translates to the newer) Then I get lots of ES events from, for example @"/usr/sbin/ipconfig" Although I know for a fact that it was muted upfront, and that calling the muting API returned successfully. The strangest thing is, if I revert to the deprecated API - and that is ALL that I do, just change a single line of code -- then these events are NOT received anymore. Same array, same executables, no other change. I don't know how to extract a simple C project to demonstrate the issue, because my code is big and quite complicated, but I will make an attempt to provide such sample.

For one thing, though, I need clarification. the "path literal" that I mute. Is it, or is it not, the path of the EXECUTABLE. My need is simple: I do not want to receive any event for specific executables (OS processes I know to be benign and whose events I do not want to evaluate and authorize). Isn't there an API to do that? must I receive some event from them and then dynamically mute the process?

Personally, I never dared breaking the ES AUTH event's deadline, because people scared me that Apple counts your failures and will revoke your ES "capability" certificate if you exceed certain limit. My two cents -- Whenever my ES client was terminated for "not answering in time" -- it ALWAYS happened after 5-7 seconds, I think - regardless of the actual deadlines of the many events I receive and handle. This stretch of time reminds me of something different with similar behavior -- When you install a daemon publishing an XPC service (place a .plist definition file in /Library/LaunchDaemons/com.mycompany.mydaemon.plist), then if your daemon fails to launch and initialize itself and be ready to receive XPC calls -- it's being kicked/terminated by launchd, after about the same 5-7 seconds. But maybe that's my imagination...

I'm struggling with the very same issue and I think this SHOULD be possible, because many MacOS APIs you use (e.g. Notification-Center notification requests) are dealt out to the notification-center daemon via XPC, so obviously it happens. In my case, my external "another" app outside the sandbox is publishing an XPC service in the user's domain, and my calls to establish the connection finally fail because default 15:21:24.427058 [0x14a846f00] activating connection: mach=true listener=false peer=false name=com.mycompany.myapp.browser.monitor default 15:21:24.427459 [0x14a846f00] failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] Have you been able to overcome this obstacle?

(Blushing) what does 'DO' stand for? And what architectural recommendation would you give for making XPC client / service implementation be a bit more "flexible" and not fail with exceptions and crashes just because a client did not implement the whole @protocol ? I found out the hard way - (and not without your kind help) along the last 3 years that NSXPC is implemented in quite limited way, and not everything you expect from Obj-C messaging works as expected -- only one "reply block" "reply block" must be last argument. "reply block can only be called once not any class can participate in the @protocol supported by an NSXPCInterface, and you must manually add classes you need. Now this... "respondsToSelector:" drops the XPC connection when something isn't implemented etc. I wish at the very least the NSXPCConnection documentation would cover these limitations as requirements, so I wouldn't have to apply "normal MacOS thinking" again and again, just to reach the end of implementation and stumble on the limitations like this. It is both frustrating, and pushes into bad design. I would design very differently had I known these things BEFORE I started implementing.

I'm trying, I'm trying, but it's really hard to do in my case. I'll explain.. This tiny menu-bar status-item app serves only as a "mouth" for a product comprised of about a dozen system-level daemons (sigh, a security tool) including EndpointSecurity client, many daemons that can't inform the user because they're not connected to any user-session or UI session etc. I found the hard way that Notification-Center is hardly usable from a "Global-Agent" or even "User Agent" which is not a "Bundle" but a unix-style binary -- so everyone speaks to the user via this tiny app via XPC - and the app converts stuff to "UI" (both in a small normal AppKit window, and via Notification-Center user-notifications. Because of this - its "function" is hardly controllable from within - it just reacts to XPC calls, and turning off stuff or digging for the "timing" of the issue is very hard to do. Our other daemons look for this app to launch - and then start chirping along on the XPC, sending it "progress" reports, summary of action reports messages the user and so on, so the timing between launch (and XPC Listener resume) to the time the dialog pops -- is clattered with many unsequenced XPC calls from different processes.

I also created and submitted an enhancement request: FB16070313 to be able to reset the TCC entry for "Local Network Access". I now see that all my submissions from the last 5 years have been completely neglected, so I don't have high hope here - nevertheless. The Eskimo recommends? I submit.

I have created and submitted a new request: FB16069295 with mostly the same definitions of my question here. Since I haven't been able to resolve the issue since then, it became even more important. Actual users (tens of thousands of them currently need to Allow/deny the Local-Network access for my App.

Once I remember there was some tool that you would run your binary through, and it would tell you which MacOS APIs you have used... This was decades ago, maybe on the move from Carbon to Cocoa, or from 32 to 64 bit, or maybe even from MacOS to iOS... can't recall now. Does such tool exist ? In my case, anything beyond very basic "Foundation" should be really minimal - so just looking at the list may be useful, This app does almost nothing when launched (merely makes XPC connections to other components of the product, and receives some "configuration" data via these connections. Then - when required by other components, it emits Notifications (via Notification Center) and updates a small popover window "data model". That's all. What could be this thing?

Playing hide and seek with my code to catch the API that indirectly needs "Local Network" permission is not only tedious - it's almost impossible Once the Dialog is up - a TCC entry is created in the TCC database records - no matter if the user answers yes or no, or doesn't even answer at all. It is created even if you cut the electricity to the Mac. From then on, no dialog will ever pop. The app gets a "NO" for Local network access, and works with that. I have NOT found a reasonable way to reset this TCC entry, and as far as I understand - there isn't any. The best I could till now - is to erase the user account and recreate it. But then --- reinstalling all the stuff there, and debugging with another subset of the code - this becomes insanely cumbersome. This is really annoying!!! how can any API require permission, without having at least a name, or some footprint in the OS logs? This is Mac and not IOS, and the available APIs are quite extensive. I'd like to know at least WHY my app wants this? I can't think of anything "network" in my app to start with! isn't this something that should be mentioned in the documentation somewhere?

Thank you very much. I'll try your suggested approach as well. Seems interesting. I think the inefficiency comes from the basic functionality of the APIs I found so far ( in MacOS Cocoa). They all assume that I'm interested in the actual items, and they fetch/pre-fetch meta-data for each file/item whereas all I need to do is COUNT. Furthermore - all existing APIs that support recursive scan of directory hierarchies - are AGGREGATING the results along the scan, and won't return until they have the full list of items. This of course both burdens CPU work and Memory consumption. I never thought to go to Posix APIs until now, because I dislike them (A True Mac programmer since 1987) because they're all synchronous and plain dumb - they do NOT cover the rich and strange behaviors and attributes of modern file-system. At least in the past, apple had its low-level FileSystem APIs exposed, and I could work magic with them. Since then the FileSystem has changed, but I don't know which APIs exist today. By example, I wrote the following naive code: static NSUInteger totalCount = 0; NSDirectoryEnumerator *dirPathEnumenumerator = [fm enumeratorAtPath:@"/Users/me/Documents"]; NSString *currRelativePath = nil; // local path while ( (currRelativePath = [dirPathEnumenumerator nextObject]) != nil) { NSDictionary *fileAttributes = [dirPathEnumenumerator fileAttributes]; if (![fileAttributes[NSFileType] isEqualToString:NSFileTypeDirectory]) totalCount++; And for my ~100,000 files Documents folder, it took about 6 seconds to run. I then wrote it differently - using SHALLOW directory enumeration, and instead of recursing, I dispatched "need to scan" code-blocks onto concurrent NSOperationQueue, thus removing recursion (and stacks) and also spreading the task over several cores -- like this: static NSUInteger totalCount = 0; static NSFileManager *fmm = nil; static NSArray *requiredProperties = nil; -(void)countFilesInDocumentsFolder { NSOperationQueue *q = [[NSOperationQueue alloc] init]; q.maxConcurrentOperationCount = 5; q.qualityOfService = NSQualityOfServiceUtility; q.name = @"file counting queue"; dirFullPath = @"/Users/me/Documents"; NSURL *topURL = [NSURL fileURLWithPath:dirFullPath]; if (fmm == nil) fmm = [NSFileManager defaultManager]; if (requiredProperties == nil) requiredProperties = @[NSURLNameKey, NSURLIsRegularFileKey ,NSURLIsDirectoryKey, NSURLIsSymbolicLinkKey, NSURLIsVolumeKey, NSURLIsPackageKey]; [self countFilesInDirectory:topURL usingQueue:q]; [q waitUntilAllOperationsAreFinished]; NSLog (@"Total File count in directory: %@ is: %lu", dirFullPath, totalCount); } -(void)countFilesInDirectory:(NSURL *)directoryURL usingQueue:(NSOperationQueue *)queue { [queue addOperationWithBlock:^{ NSError *error = nil; NSArray<NSURL *> *itemURLs = [fmm contentsOfDirectoryAtURL:directoryURL includingPropertiesForKeys:requiredProperties options:NSDirectoryEnumerationSkipsHiddenFiles error:&error]; if (error) { NSLog(@"Failed to get contents of: %@, Error:%@", directoryURL, error); return; }; for (NSURL *url in itemURLs) { NSDictionary<NSURLResourceKey, id> *fileAttributes = [url resourceValuesForKeys:requiredProperties error:&error]; if (error!=nil || fileAttributes == nil) { NSLog(@"Failed to retrieve attributes for:%@ Error:%@",url, error); continue; } if ([fileAttributes[NSURLIsDirectoryKey] boolValue]) { [queue addOperationWithBlock:^{ [self countFilesInDirectory:url usingQueue:queue]; }]; } else { if ( [fileAttributes[NSURLIsRegularFileKey] boolValue]) totalCount++; } } } }]; } And this one - although lengthy - took about 0.45 sec to do the same job (even a little better). So... with my ***** of a Mac and a fast-as-hell SSD, I am still very far from satisfied. I'll go down the POSIX rabbit hole and see what goes. Thanks! If I find the POSIX faster than my current thing, I'll accept your answer as the best :)

[quote='796747022, endecotp, /thread/760256?answerId=796747022#796747022, /profile/endecotp'] one [/quote]

Thanks for the info so far -- it is really valuable. However - few questions remained un-answered for me (in similar but not identical scenario) Should the set of allowed classes be applied to the "exported interface" on both Client and Server side of the XPC connection? only Server side? only Client side? Your question involves your own custom class. But what Cocoa classes are acceptable by default (without calling the "exportedInterface.setClasses", and what should be manually added ? Where is the list documented? B.T.W an ObjC version of the same snippet would be nice. 3, In my experience both server and client are Obj-C and I don't have any custom classes - only Cocoa classes), the behavior of XPC is very unclear. I experienced exceptions that claim exactly that - "unsupported classes" but only sometimes it fails, and sometimes it passes OK, and I can't understand when and what and why. For example, I removed NSError NSAttributedString classes from my XPC protocol, and that removed the intermittent exceptions. Why? Last, you asked about logs have you found relevant log messages related to this? Where to look for them? In my case, the only "logs" were .ips crash-logs...