I am disappointed that there is no actual answer to the question in the title. I need an answer to this and this is the first hit on Google. Yet, all that I see here is suggestions for solving the specific issue but not the question in the title. To answer Quinn's question: In my case, I need to keep my code compatible with various SDK versions (for various reasons that are valid but shouldn't need to be justified here), so I need to add conditional code depending on the SDK version. And since it's a compile time issue, I cannot use @available() here, either. So I really need to know which SDK I'm compiling under.

nevermind

I just got this as well from a user of my app (Find Any File). Attached. This happened when a user wanted to copy an unknown number of file references to the pasteboard. Note that the app memory is around 18 GB. I wonder if the number of copied items is so large that the Mac simply ran out of memory. faf.crash

Just to double check: Your helpers are signed with the same cert as the main app is, right?

Just to add some clarification: Apps that run their helper tools via NSTask seem not be affected. At least my app Find Any File remains able to launch its "searchfs" helper this way, which in turn searches entire volumes, once the main app has gotten FDA, even in 11.4. I suspect that the issue is only with helpers that get run outside of the main app's runtime, e.g. as launchd service, Login Item etc. This change was apparently implemented to deal with CVE-2021-30713: (see https://mjtsai.com/blog/2021/06/01/macos-11-4-breaks-full-disk-access-for-helper-tools/#comment-3465367). But in a wrong way: Instead of making sure that embedded helpers are tested to belong to the main app, i.e. have the same codesign Team ID, it simply denies them FDA altogether if they're launched not directly by the main app, it seems. Looks like a hasty fix that was not well thought through. And bug reports about it then being ignored as well. Scary.

One thing I found that is not right: I am setting the doubleClick action handler in code, but I forgot to also set the control's target property. Still, when I run the code in the debugger, the action handler gets called even without having assigned the target. So I wonder if that might be the cause of the issue. But if the responder chain was temporarily changed so that the action handler would get called on an object that doesn't implement the action, then I should get an exception about the missing selector (which is pathCellDoubleClicked: in my case), right? But that's not the case as far as I can tell, so I guess the unset target is not the cause here. Or am I wrong?