Many thanks. I can safely deploy the framework not fearing It leaks. I will follow the "Availability of Low-level API's" link to educate myself. Please note the documentation line you bring (from header?) doesn't ring any bell with me... I do not know what a "validity reader" is. I was hoping for what Apple used to publish as "Programming Guide" - something that helps establish some high-level understanding of the subsystem.

But wouldn't "Persistent, system wide" permission of "Full Disk Access" cover this - to the point the "transient, process lifetime" permission won't be needed (and won't trigger the dialog) ??

Thank you so much. Could you please reveal what fts is, in which MacOS Framework it resides, and where are the headers/documentation for it? First time I hear the acronym...

I now found out that this restriction (single reply-block that must be the last argument) also rule out any XPC protocol method that has variadic argument list... like (instancetype)stringWithFormat:(NSString *)format, ... NS_FORMAT_FUNCTION(1,2); because such args must also reside at the end of the definition... Yikes. Now choose between reply-block (must have one!) and variadic method (without it, my method will be SO ugly, with NSArray of optional args and so on).

Hi, sorry to interrupt, but for me - this doesn't run even on a Mac (Ventura 13.6.6 + Xcode 14.0 (14A309)) It runs - but yields no log entries (empty 'entries'). I also tried an Obj-C form of this - with same results. I choose to "run as root" in the debug scheme of Xcode. It's a "command line tool" simple project, signed "Mac Development".

Sad to say I didn't. I found a workaround though. I added a concurrent operation-queue on which I perform the calls to [NSWorkspac isFilePackageAtPath:] I also Implemented an "Asynchronous NSOperation" for my main ES evaluation, that supports a timeout (based on the ES deadlines). My AUTH event handler asynchronously dispatches [NSWorkspac isFilePackageAtPath:] and blocks awaiting result - up to my timeout. Now my ES client is never kicked.

Supporting: BOOL accessibilityPermissionsGranted = AXIsProcessTrusted(); checks app can use Accessibility APIs on other apps, while [[UNUserNotificationCenter currentNotificationCenter] getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings * _Nonnull settings) { BOOL TCCGranted = (settings.authorizationStatus == UNAuthorizationStatusAuthorized); }]; tells app can send user notifications. APIs exist for Camera, Microphone etc. WHY NOT FDA?

I bow to DTS god. Thank you so much. As a person who bought and read the full original "Inside Macintosh" series, I got spoiled early on, believing in Apple Documentation, and its completeness of description. Each subsystem, from "conceptual" to "programming tasks" to "reference". Nowadays I simply can't find the information anymore, and much of the remaining information is deemed "deprecated", "retired", "archives" and other words describing neglect. Thank god YOU still remember.

Wow, THANK YOU! Could you please add few more details ? In what doc/TechNote - can I find these facts (what's supported and what isn't)? dev. on the basis of guess-work is slow and inefficient. Your suggested 2-point design allows POLLING on status, which is what I try to eliminate via two-way connection. Currently I maintain "named" service one-way + unnamed back-connection, but keeping the pair alive is tricky and error-prone. NSProgress? bi-directional? How!?

Also, in the second resource (StackOverflow question+answer) the guy who answered - referred to the above "customizing_the_appearance_of_notifications" as "iOS only, not available on MacOS" - but he didn't say why he thought that.

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?

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)...

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?

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.

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?