Thanks again. Indeed I missed the sentence "A method can have only one reply block." in the old archived documentation - but that same sentence also says: A method can have only one reply block. However, because connections are bidirectional, the XPC service helper can also reply by calling methods in the interface provided by the main application, if desired. Which brings me to the original question -- HOW do I do that? My "players" aren't an App and its helper-service, but rather independent, resilient system daemons and global agents that need communicate, in all directions. The dual XPC connection I'm maintaining now, is just cumbersome. Each "product shutdown" flow is an ugly nightmare, and recovering from one-side-crash looks different on either sides - which is ugly too. Bidirectional XPC connections look like the right thing to me. I found and downloaded the recommended 2012 WWDC session from here: https://archive.org/download/wwdc-2012-sessions and watched it carefully twice - but there too - it is only HINTED for a split second, that the connection is bidirectional and both sides can send messages - and immediately the hint is removed from screen, and replaced by that single reply-block technique. There is a tiny gap here I need to bridge. I already have a live NSXPCConnection, both sides agree on the same protocol, the "client side" obtains a "remote proxy" and the "server side" exports an object and assigns them to accepted incoming connection. Then client sends messages to the service. How can the client-side create an "exported object"? can it also assign an NSXPCInterface and exported-object to its NSXPCConnection when it connects to the service? and how would the service get the proxy if it wants to call-back to the client? If the docs say NSXPCConnection is bi-directional, SOMETHING must be said somewhere regarding the use of this feature. As in your hinted novel - I think I'll just go on and open the "disused lavatory" carrying that "Beware of the Leopard" sign, to find the demolition order for my house :( One things keeps me uneasy. In the full decade of NSXPCConnection, hasn't anyone need bi-directional IPC? Why is it only I'm looking for ways to do it? Design-wise, Is it something wrong with my ideas?

To whoever collects evidence - I admit to have met Quinn face-to-face SEVERAL times, in 4 or 5 different WWDC occasions, from about 1995 to (I'm not sure here) 2010. I also know his name from header files of the late OpenTransport technology and even the larger-scale "Power" set of communications/networking technologies that Apple brewed in the last 5 years of MacOS classic (7,8,9). This means, I can remember his face, with no direct connection to any developer support incident. Rather a beer (or was it white-wine?) in one of the WWDC receptions in San Jose, CA. I even owe him my life and happiness - as one of his indispensable comments in one of Apple's old header files, said "Don't do XXXXX or you will never have a happy life". Fortunately I read this note in time to see my code contained exactly XXXXX - so I found another way of doing what I needed, and my life was saved.

Have you managed to follow on Quinns recommendation and access your "background" XPC-service from your Client.framework ? I'm in a similar position and any hints can save me lots of time and suffering.

Hi, I read the code - not thoroughly, and I think this can be done much simpler. First, I agree with Eskimo that messing with NSOperationQueue isn't the right thing. Your task is better achieved by constructing a proper NSOperation instead. Second, and this is "high level" remark" you almost re-implemented NSOperation in your subclass, instead of modifying its behavior, and I think there's a much much simpler way to do this. As you're already aware, the isCancelled and isFinished properties of an NSOperation are observable - and are also observed by the NSOperationQueue. But you forgot the one property that BY DESIGN gives you what you want -- @property (readonly, getter=isReady) BOOL ready; Now when you want to delay the execution of an NSOperation, all you need to do is to keep its ready property at NO until such time you want it to execute, and then - change it to YES. NSOperationQueue observes the ready property, and will schedule pulling it from the queue when it becomes ready. You'll need to wisely override the ready property, so that you don't break other behavior of it, and you will need to have a timer somewhere that will trigger its change to YES. I don't have time to implement a sample now... maybe I'll do it and add to this answer. Hope this helps.

I fail to fully understand this code. Why attempt to retrieve records for ALL users? (kODMatchAny for kODRecordTypeUsers without limitations?) This WILL fail in large environments (most corporates) after few thousands of users. Why do this on the first place, if you want to "see whether a specific AD user is admin" ?? This code only receives records from the LOCAL search-scope, not AD at all. Have you tested? Why the textual manipulation of group results? use OD objects..

@eskimo OK... got a huge (~380MB) archive of sysdiagnose, taken about 1 minute after my ES client was killed by OS. What now? what should I be looking after - How to even open/understand this huge archive?

I found the problem to be this: My NSMutableDictionary (actionInfo) sometimes contained values that were of the class NSSet. Sadly, the Cocoa/ObjC implementation of NSXPCConnection does not allow passing just any type of object "on the wire" to the remote process. I DO NOT completely understand the issue - because SOMETIMES it does work, and sometimes it crashes, but the moment I restrict the objects passed on the wire to those basic Foundation classes one finds in Plists (The sacred NSArray, NSDicationary, NSString, NSDate, NSNumber and (maybe - haven't verified - NSData) The sporadic crashes disappeared completely. I verified also that all the objects in the NSSet I was passing were from this list of "standard" objects - so - the cause is definitely the NSSet. What I do now, is pass [mySet allObjects] (yielding an NSArray) to the other side, where I convert it back to [NSSet setWithArray:] and live like that. Maybe I missed it in the documentation - but I think the only "no no" I have seen in the docs is about classes that can't be securely encoded - and as far as I know NSSet is a honorable and securely-encodable object... So... I don't understand, but at least I resolved my crash. Hope this helps anyone.

You're the only reply... and I did not find any information whatsoever. If you find anything - please also remember me and paste here

Thanks for the reply. Maybe I wasn't clear. In my attempt to resolve the crash, I changed my code so that ALL modifications to the actionInfo mutable dictionary are enclosed in operations added to the serial monitorUpdateQueue queue. You can look at the example - I just have about a dozen "snippets" like that, adding/modifying some info on the actionInfo, then calling the XPC. All on the serial queue. The other concurrent queues and threads, are now ALL dispatching anything related to the actionInfo onto the serial queue. The whole code related to this mutable dictionary is placed in 2 methods (actionInfo is a heap object, not an object member, allocated in the beginning of one method, and deleted as it exits. I is never passed to other objects -- except, of course, the failing XPC call which "reports" this data to another process.

No one? really?... it's sad.

I did not find a way to manage UNNotifications from a LaunchAgent. My work-around solution is: I created a little "menu-bar app" with that tiny icon, that my launch-agent launches when it needs to communicate with user. I also made my LaunchAgent a mach-xpc-service with an NSXPCListener and created a proprietary protocol between the two. via XPC I convey information from the LaunchAgent 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 (my menu-bar app) - 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" the user's state, so in my case it is cumbersome, but acceptable solution.

Thank you very much for this clear and useful answer. Making it an "XPC service" - launchd daemon "Advertising" a public XPC service is probably the right way for me. I'm trying to make it work this way (still doesn't work and clients don't seem to "find" me) ... still struggling. However... for theoretical completeness, if I wanted to pack this monster as an XPC Service (capital S) inside an App's bundle, what then? Is there a way to overcome the inability to call xpc_main(my_event_handler) ? I'm asking purely for understanding the mechanism, and maybe... some day... I'll be able to persuade managers to make the whole product a real Mac App - and so gain a zillion and one benefits.

Although I never experienced such behavior and the same expression works perfect for me - one thing you write which (I think) is NOT TRUE - you say that NSUUID is "based on CFUUID" and it isn't. Not only NSUUID* is not "toll-free-bridged" to CFUUIDRef (try to cast and bridge then send a message - you'll crash immediately) - the only way to construct one from the other, is either via "exporting" one as a string and initializing the other from that string, or - extracting the "raw uuid 128bit value" and creating the other from it. Not even a special initializer to bridge the worlds. Just for your info.

I see this as a shortcoming of Apple engineering, trying to patch the OS in order to let buggy old software that assumed MacOS will remain X (10) forever continue running. This is more MS-Windows than MacOS, and I wish versions were the only aspect of this. What I'm concerned with, however, is the opposite - out software is deployed on both older and newer systems, and needs to report to server the MacOS version it runs on - and we're having Big Sur appear sometimes as 10.16 sometimes 11.0 --- calling the same API! No, we can't align all our build-tools to MacOS SDK 11 - since on older systems we use APIs that are now deprecated on new OS versions, so we maintain older build machines for deployment on older Macs. What I seek - is a way to CONSISTENTLY get 11.x from MacOS Big-Sur, for ALL our versions running on ALL Macs and MacOSs With all that wonderful and so-elaborate Info.plist thing - why can't we have 10.16 .x for SDK version and 11.x for "Marketing version string" ???

Sad to say, these issues persist even now with Xcode 12.5.1 and MacOS 11.4 It sure looks like a bug, because alternative APIs to achieve more-or-less the same, are still supported and seem to work. In my current code I use the combination of:     ProcessSerialNumber psn = { 0, kCurrentProcess };     TransformProcessType(&psn, kProcessTransformToForegroundApplication);     [[NSRunningApplication currentApplication] unhide]; [NSApp activateIgnoringOtherApps:YES]; As alternative to the always failing     if ( [NSApp setActivationPolicy: NSApplicationActivationPolicyRegular] == NO)         os_log_error(preventionUILog, "Failed to change ActivationPolicy to Regular"); Hope this helps somehow...