Mac App Store app running programs in /usr/bin or /sbin

Question

Hello,
The Mac Developer Program License Agreement says:
3.3.4          All files necessary for the Application to execute must be in the Application bundle submitted to Apple and must be installed by the Mac App Store.
This precludes using NSTask to run a program in /usr/bin or /sbin to obtain some output. Seems pretty restrictive since there is a lot of good functionality there and most of it without copyright. There is a fine line between running /sbin/md5 on a file to get a hash, and calling md5() in libssl.dylib, making me wonder what is the purpose of the restriction.
The question, dumb as it may sound given section 3.3.4 of the agreement, is, should I eliminate all code that runs other programs?
If the Mac App Store app runs without running other programs, but includes other features by running those programs, does it still violate section 3.3.4?
Has anyone submitted a program that calls others and, if so, was it accepted?
Thanks

Answer 1

CTSdev wrote:
I've never had a problem with NSTask. In what way is it clunky?
You have to set it up, launch it, possibly send it data, collect the output, parse it. I have an app circulating around here called EtreCheck that does lots and lots of NSTask. It isn't sandboxed though. The problem is that your NSTask inherits your app sandbox and it may expect to read or write to places that it can't. You can use it, but if there is an alternative in a framework or library, that would be better. I think the biggest problem with NSTask is that they are procedural. You have to start it, run it, wait for it, and then handle the output. You will have to do that in a thread or block.
I used /sbin/md5 as an example since it has an analog library routine. /usr/bin/cksum is the more direct way to verify file integrity. I would also like to run /usr/bin/compress. Certainly easier than writing & testing LZW or Huffman code.
I think you could probably run both of those. There may be easier versions around. iOS people can't do any of that so there may be some handy Cocoa libraries that will do just what you need. If you just want to compress data, libz is in the OS and not too terribly difficult to use.
I will probably just have my app run those programs and describe this in my submission to Apple, If they say no, then I'll code those pieces too.
I don't think you really have to describe anything other than some of your entitlements. As long as it works on your machine and you aren't calling any private APIs then you should be fine. I was only half-joking before. If you really aren't a fraudster, then you really have nothing to worry about at all.
I don't know what kind of checks they do for that kind of thing. Pretty much everything I have done so far has some feature that looks like it should be forbidden by the sandbox, but really isn't. I display copyrighted Apple art in ways that aren't normally possible. I launch Terminal. I just released an app that has serious amounts of integration with the Finder. No problems.