Ok here's my follow-up...I confirmed that everything I told you was true and
finally said to myself I will just communicate with this executable inside my
bundle. This works until I submit it to the Mac App Store and I get invalid
binary because this executable (3rd party) is not sandboxed.
On Jun 24, 2012, at 2:47 AM, Rick C. wrote:
Ok here's my follow-up...I confirmed that everything I told you was true and
finally said to myself I will just communicate with this executable inside my
bundle. This works until I submit it to the Mac App Store and I get invalid
binary
Yes that is right I was doing it wrong thank you very much! Now the only other
issue I had was am I not allowed to write my helper app to my application
support folder and send NSTask to it there? It seems this only works if I keep
it inside of my bundle?
rc
On Jun 25, 2012, at 5:08 AM,
That does make sense I was just looking for a definitive answer... :-) Now I
am writing my helper to the app support folder inside of my sandbox that's why
I thought it might work, but it might not based on how you described it. And
I'm guessing it might also be possible that with the inherit
Hi,
In the non-sandboxed version of my app upon first launch I copied a helper
executable from my bundle to my application support folder (standard location)
and communicated with it via nstask. Now I'm trying to sandbox my app and I
found that when I do this it fails with a read-write deny
On Jun 22, 2012, at 4:51 AM, Rick C. wrote:
Hi,
In the non-sandboxed version of my app upon first launch I copied a helper
executable from my bundle to my application support folder (standard
location) and communicated with it via nstask. Now I'm trying to sandbox my
app and I found
