The CLI is located at ~/Applications/mycli/cli_executable.
That’s definitely going to be blocked by the App Sandbox. For testing purposes, try signing your app extension with a temporary exception entitlement that allows access to that directory. For the details, see App Sandbox Resources. Does that get things working?
IMPORTANT There are two reasons that might not work:
-
Every appex runs in a sandbox that’s similar to the App Sandbox, but not exactly the same. Some appex sandboxes prevent them from spawning a child process. I’ve never actually tried this in a CTK appex, so I’m not sure if its sandbox is set up to allow or block this.
-
Your command-line tool will inherit a standbox from your CTK appex, and it’s possible that your tool won’t work in that sandbox. If that’s the case, you’ll have to fix the code in your command-line tool to be sandbox compatible.
If your test shows that your CTK appex is allowed to spawn a child process, then the long-term fix is for you to embed this command-line tool into your appex. See Placing Content in a Bundle for information about where to put it.
If you plan to distribute this app via the Mac App Store, you’ll need to sign your command-line tool with the sandbox inheritance entitlements. Embedding a command-line tool in a sandboxed app explains how to do this with Xcode. You’ll have to apply its lessons to your third-party tooling.
If you’re planning to distribute your app directly, using Developer ID signing, then you don’t need to do this. The sandbox inheritance entitlements are only required by the App Store.
In that case you can add a symlink from ~/Applications/mycli/cli_executable to the executable within your CTK appex, so that Terminal users can continue to use it. That only works if your tool has no entitlements. If it has the sandbox inheritance entitlements then you can’t run it from Terminal.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
