Mine is an Obj-C MacOS X project with several targets, Running latest Xcode 12.5.1. Failing target is a normal Cocoa App. It started failing with this exact error after I dragged an image file to the project (into Resources group/directory), added to the target and tried to build. I use this image resource programmatically. Failed again and again. Removing the image removed the problem. I found the image file WAS NOT copied to the project repo, and the reference pointed to somewhere outside the repo. I deleted the reference from the project, copied the actual file into the project repository, re-added it to my project/group and target. Verified the reference was now inside the project repo (relative to group, with just the file name as a 'path'). Now it built OK. I then dragged another image (this time I first copied it into my Resources group/directory) and sad to say - the problem resurfaced. Reading other answers here, I saw the proposed build script: xattr -cr ~/Library/Developer/Xcode/DerivedData || echo Clear So I started to suspect the actual image files had something about them that was not to Xcode's liking. so... a Quick Terminal shell: mini-mac7:Resources $ ls -la@    total 392 drwxr-xr-x   5 mshneor  staff     160 Jun 28 13:57 . drwxr-xr-x  12 mshneor  staff     384 Jun 28 13:44 .. -rw-r--r--@  1 mshneor  staff   19688 Jun 28 13:44 MyPtShield.png com.apple.lastuseddate#PS     16  -rw-r--r--@  1 mshneor  staff  172435 Mar 16  2017 My-logo-reg-K.png com.apple.FinderInfo     32  com.apple.lastuseddate#PS     16  com.apple.quarantine     57  -rw-r--r--@  1 mshneor  staff     258 Jun 28 13:44 factoryDefaults.plist com.apple.lastuseddate#PS     16  And sure enough - both image files DO HAVE extra information and extended attributes. So this time, I ran that script once, directly at my Resources directory, thus removing all Extended attributes from the resource files, like this mini-mac7:Resources $ xattr -cr . || echo Clear mini-mac7:Resources $ ls -la@                   total 392 drwxr-xr-x   5 mshneor  staff     160 Jun 28 13:57 . drwxr-xr-x  12 mshneor  staff     384 Jun 28 13:44 .. -rw-r--r--   1 mshneor  staff   19688 Jun 28 13:44 PfPtShield.png -rw-r--r--   1 mshneor  staff  172435 Mar 16  2017 Proofpoint-logo-reg-K.png -rw-r--r--   1 mshneor  staff     258 Jun 28 13:44 factoryDefaults.plist mini-mac7:Resources $  And sure enough - next build worked like a charm. I really hope git is smart enough to push the removal of extended attributes to the repo too.

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

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" ???

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.