Oh sounds great, thanks I will try to contant D&B

DTS case number 752514766

ps Just to set expectations, I’m not 100% sure that this will help. If it doesn’t, I may ask you to open a DTS tech support incident so I can dedicate time researching your issue. I think to open a DTS because I really don't understand, I'm trying to create a test case project to reproduce the problem Thanks for your great feedback

That’s not a supported location of nested code. See the Nested Code section of Technote 2206 macOS Code Signing In Depth for our advice on this front. So I suppose the correct destination is (or should be) Contents/Helpers You may want to package your command-line tool in an app-like structure to ensure that the sandbox gets set up coherently. I'm not sure to understand (please apologize me) do you mean creating a separated "bundle" containing only the command-line tool? I've tried to add a 'Copy File' to XCode Build Phases but the combo box doesn't contain Helpers so I chosen Destination: Absolute Path Path: $(CONTENTS_FOLDER_PATH)/Helpers but the application doesn't compile Then I tried Destination: Wrapper Path: Contents/Helpers the application compiles, the tool is copied inside the correct path but if the application is launched from XCode the command line tools fails to "call it" as described in first scenario

Where your command-line tool placed within your main app’s bundle? the CLT is inside the Contents/Resources's App directory

Right. A sandboxed app (well, in this case, a sandboxed tool) needs this entitlement in order to send arbitrary Apple events. The Apple events destination is only the app contained in the same tool bundle, the temporary entitlement sounds a bit extreme in this case There is an alternative here, namely com.apple.security.scripting-targets. See Enabling Scripting of Other Apps in the Entitlement Key Reference. I already found this info but this sounds like another level of complexity with its scriptable app’s scripting access groups. If your app needs to control another scriptable app, your app can use the scripting targets entitlement to request access to one or more of the scriptable app’s scripting access groups. Thanks again to point me out to the right direction

IMO it’s best to use Apple events for this. It’s hard for a sandboxed app to publish an XPC service that can be accessed from outside of that app [1]. Ok thank you very much. I must rewrite the code in any case so if Apple Events is MAS friendly I will study them

Hi Quinn, The app is distributed via the Mac App Store Actually I'm working inside the AppSandboxLoginItemXPCDemo, so yes the helper tool is embedded withing the app (and also the command line tool) The answer to your last question is a bit complicated, so I prefer to describe the current scenario (with NSConnection). The command line tool is used to make only one specific task: start the application from the terminal and "wait" until the application window associated to (or the whole app) is closed. The command line tool passes (using NSConnection) some parameters to the application and the "wait" flag is one of them. The command line tool is pretty much identical to the BBEdit command line bbedit and bbdiff helpers but sandboxed for the Mac App Store