How can I bundle a command line utility in os x application on Mac App Store (using sandbox entitlement)

Question

I have a c++ command line application that I have already compiled into an executable and have added it into my Xcode project. I have also added the "Copy Files" section to the Build Phases tab of the project properties and added my executable with the "Executables" destination. When I build my application I see it in the test.app/Contents/MacOS folder when I View package contents on the test.app that is built.

I also have App Sandbox enabled on the Capabilities tab of the project (so that I can distribute my application through the mac app store.

How can I expose this command line executable that is bundled with my application to the user so that they can run it from the command line (terminal)? I have not been able to find anything on search engines or on StackOverflow about how to get this file (or a symlink to this file) into the users PATH. I tried using an NSTask to create a symlink, but that only works if I disable the App Sandbox (which makes sense). Has anyone done this before? How did you get it to work? Or can these executables only be executed by code within your application?

Answer 1

I don't see a good way to do this. First, a clarification: the PATH is a list of directories that contain executables, not a list of executables; there's no way to add a single executable to the PATH. Instead, what you'd need to do is either put your executable into one of the directories in the user's PATH, or add the directory your executable is in into the PATH.

On OS X, the default PATH is /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin. The first 4 directories shouldn't be modified from the system default, so only /usr/local/bin is a possibility. But creating it (it doesn't exist by default) would require admin (actually root) rights, which isn't allowed by App Store policies. So that's out.

That leaves modifying the user's PATH. The "right" way to do that system-wide is by placing a file in /etc/paths.d, which requires admin (/root) rights, so that's out too. Technically modifying the /etc/paths file would work, but that has the same permissions problem plus it's the wrong way to do customization.

The next possibility is to modify (/create) the user's shell initialization script(s). This'll work, but doing it at all right is going to be messy, because there are several shells the user might use, each with several different possible initialization scripts that the user might or might not have created...

Let's take a very simple case: a user who only ever uses bash, and who doesn't already have any initialization scripts. When a "login" instance of bash starts, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile (in that order), and runs the first one it finds. But your app doesn't know which shell he uses, so you'd better create ~/.profile so zsh and ksh will use it as well. So, your app creates ~/.profile, and puts this in it:

PATH="$PATH:/Applications/MyApp.app/Contents/Helpers"

Great, right? Yup, great, until the user runs something else that wants to set their PATH, it creates ~/.bash_profile, and this overrides your setup. After that, your executable will be in the PATH of zsh and ksh, but not bash. Whee.

And then one day the user decides to use tcsh instead, and it (and csh) have a completely different but equally messy pile of possible init files...