Thank you so much for answering! Contents/Resources is not the right place for a helper tool. Thanks, I'll try to move it. This is historically the place I've seen such tools to be placed (including Apple software in the past - but we're talking about 10-15 years ago) and I just kept putting the binaries there... But you are right, when I think about it, it is probably incorrect place. I suspect that the wrapper applied by the pp tool is actually unpacking code into the temporary directory and then running that. Huh! That did not occur to me! I suspected that this was due to App Translocation that the binary was launched from a temporary location as a result of the quarantine... So I did not even check the path! I've used FSMonitor (app for displaying fsevents in real time) and indeed, this is what happens. I fully understand this is not compatible with App Sandbox, so I will need to find another solution. Embedding Perl interpreter was on my list of possible workarounds, so I'll need to look into that, though it seemed like a less "clean" solution than one single standalone binary...

One more small question: Note While .pl files are code, you’d end up running in a way that doesn’t invoke Gatekeeper and thus the quarantine doesn’t matter. Where would you recommend placing such files? Along with the Perl interpreter into Contents/MacOS or, as these are generally just basic text files, they are fine in Contents/Resources?

Thank you for answering! In the meantime I tried another approach of creating the command line tools via SwiftPM and ran pretty much into the same issue here. The Package manifest defined two binaries with some dependencies and the build process again complained about multiple commands producing various frameworks. I fully agree that simplification is the way to go which is why the actual project has about 6 different frameworks into which the functionality is broken down. It is interesting to note that the error appears for frameworks that link external libraries - in one case it's swift-syntax and swift-system (as one of the libraries defines macros) and the other swift-subprocess. I wonder if this has any effect on this. When you have HelperTool and AdditionalHelperTool both linking MyFramework and both having an "Embed Frameworks" or "Copy Files" phase configured to copy MyFramework to Build/Products/Debug/Frameworks/, Xcode sees two distinct commands attempting to write to the identical location, leading to the conflict. I understand why this error occurring, but I do not set these commands up - Xcode does. Or to be more precise the Swift build system. When I remove complete references of the libraries from the command line targets (HelperTool and AdditionalHelperTool), I actually get another error about the module _SubprocessCShims (which is part of swift-subprocess library): "Unable to find module dependency". I've been playing with this for quite a few hours and it's just like playing whack-a-mole - I get rid of one error and get another one. :( If MyFramework is not a system framework (which it likely isn't if it's from a SwiftPM package), your helper tools will need to find it at runtime. Yes, this is why I've updated @rpath via the linker settings in Xcode.

OK, so I managed to create a minimal example: https://github.com/charlieMonroe/MultipleCommandsExample There is an Xcode project MultipleCommandsExampleApp which has multiple dependencies and mainly a package MyTools that defines to executables - HelperTool and AdditionalHelperTool which also have multiple dependencies.