There’s a couple of things I’m to do with my app, but the sandbox is getting in my way (again!).
Firstly I have enabled the use of the media keys within my app (play, fast forward, rewind) using the code from the MBS examples. This works perfectly when not sandboxed, however when sandboxed I receive the following error in the console:
MYAPPNAME(38592) deny hid-control
Reading around the web it looks like the sandbox doesn’t allow intercepting these keys. Am I just going to have to remove this function from the App Store version of my app or does anyone know a way around this?
Secondly I need to access a command line utility via shell. Obviously this is a complete no-no on the App Store, so I’m not even bothering trying. However, I notice some apps (like Boom or data rescue apps for example) offer the ability to download extra software for free from their site that performs the functions disallowed on the App Store.
So I have created a small app that interfaces with the CLI utility via shell. The idea being that people can download the app from my website and install it and manually run it once to set it up. This should satisfy the Apple requirement for launching external apps that “The helper has been (manually) run at least once by the user”. I have a toolbar button in my sandboxed app that launches the helper app.
This all appears to work fine. The helper app launches fine and does the job it’s meant to do. However, I have the following error in the console when launching:
MYAPPNAME(38592) deny file-issue-extension /Applications/MYHELPERAPP.app
So everything works, but the above log message worries me. Researching around the web, all mentions of the message are in connection with something not working, which is odd as everything works fine for me. Anyone have any ideas what it means? I guess what really worries me is if it doesn’t work properly when downloaded by customers from the App Store. I don’t want to release the product with the promise of this feature only to find that I can’t get it to work for App Store customers.
Any insight is greatly appreciated.
If it is part of the standard set of utilities in OS X, it works fine. I have a program based on Textutil shell in the App Store.
Using the shell is fine, and if you’re using a system cli app, you’ve got nothing to worry about.
However if you’re bundling a CLI with your application package, you need to Sandbox that CLI also, and use must use NSTask to launch the Sandboxed CLI tool (a regular shell won’t cut it).
Thanks for the replies.
For the non-app store app I am using a CLI app that I am bundling in the Resources folder of my app and using a shell to start it. Last time I tried to use NSTask with a different app in the sandbox I had the following error:
04/06/2014 18:00:25.371 sandboxd: () MYAPPNAME H(68552) deny forbidden-sandbox-reinit
I’ll try again with this app and see if I have any more success.
I’m using App Wrapper to sign the app. So providing I ensure I have NOT ticked the ‘Don’t sandbox unix applications’, it should sandbox the CLI app I have bundled in the Resources folder. Is that correct?
Also, on a side note, the CLI is LGPL. As I’m not actually making any changes to the code and am only using it as a CLI, I come under the ‘Application that uses the library’ clause of the LGPL. This means I just have to provide a download of the source of the CLI for the version I am using so someone can re-compile the CLI from my source if they wish. I don’t however have to supply the source to my app as I’m not integrating the LGPL code into my code base.
Does anyone know if sandboxing the CLI will have any impact on the LGPL?
Having read the LGPL about 100 times I think differently every time I do! Using LGPL on iOS is out as you don’t have the freedom to recompile and install on your own device, however on Mac you can, so it seems it’s OK to do so on the Mac App Store and I have seen several apps using LGPL libraries in the Mac App Store.
However, I don’t know how this is effected by Sandboxing as this would effectively break the app if you recompiled the CLI and replaced it in the bundle (which you are meant to be able to do under LGPL).
I was thinking, if the CLI was installed to /usr/local/bin then it would be accessible to any shell or terminal on the system. I assume this would also be available to NSTask.
So I was thinking I could create an installer that could be downloaded from my website separately from the App Store which would install the necessary CLI. Then the App Store app could just call the CLI with no problems using NSTask.