Different behaviour running app from inside XCode or from /Applications

My sandboxed app contains a command line tool (CLT) sandoboxed, too.
App and CLT have the same Team and Bundle Identifier.

The CLT sends an apple script message to the app using SBApplication:applicationWithBundleIdentifier

First strange behaviour - Running app from XCode (Product -> Run)


If I launch the app from XCode (for debug purpose) and the CLT from terminal window I obtain the error

Code Block
failed to get scripting definition from .../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug/my.app; it may not be scriptable


If I run the app from Finder (double click it) and the CLT from terminal window everything works fine

Obviously both App and CLT launched are the same, the CLT is inside the Contents/Resources's App directory

Why launching from XCode doesn't work????


Second strange behaviour - Running app from another computer


The app must be distributed from Mac App Store but for test purpose I notarize and copy it to other computers.

If I launch the notarized app from /Applications everything works fine
If I launch the notarized app from another path (e.g. /Users/dave/My.app) the command line tool bundle identifier is nil

Is this the normal behaviour?

Where your command-line tool placed within your main app’s bundle?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Where your command-line tool placed within your main app’s bundle?

the CLT is inside the Contents/Resources's App directory

the CLT is inside the Contents/Resources App directory

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.

My best guess here is that the sandbox is misidentifying your tool. Remember that the App Sandbox was designed as an app sandbox. It’s not really set up for command-line tools. You may want to package your command-line tool in an app-like structure to ensure that the sandbox gets set up coherently.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

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

I'm not sure to understand … do you mean creating a separated "bundle"
containing only the command-line tool?

Yes. This sort of thing is necessary from time-to-time. For example, it’s necessary when you command-line tool needs to use entitlements that must be allowlisted by a provisioning profile. My Packaging a Daemon with a Provisioning Profile post explains the technique I use for setting this up.

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.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

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

DTS case number 752514766
Different behaviour running app from inside XCode or from /Applications
 
 
Q