This helped me thanks! Unfortunately I wasn't try to launch my helper app via launchd so it was a bit different. But had to say thanks! :-)
rc On Jun 1, 2012, at 9:30 AM, Alex Zavatone wrote: > If you haven't watched the video for Session 204 - "App Sandbox and the Mac > App Store" from the WWDC 2011 videos, there might be some info in there that > will help you around the 9 minute mark. > > Search for the 2011 WWDC videos on developer.apple.com > > GL, > - Alex Zavatone > > On May 31, 2012, at 6:35 AM, Mark Allan wrote: > >> On 29 May 2012, at 15:42, Mark Allan wrote: >> >>> For anyone following, using temporary entitlements only gets rid of two of >>> the four errors, so I still can't make scheduling via launchd work. >>> >>> sandboxd still spits out: >>> launchctl(14634) deny job-creation >>> >>> and Xcode/run log still gives: >>> launch_msg(): Socket is not connected >>> >>> Other than rolling my own scheduling and writing a helper app which runs >>> constantly in the background, can anyone think of a way around this? >>> >>> Thanks >>> Mark >> >> OK. After nearly a week of head-banging, I'm just about ready to throw in >> the towel, dump sandboxing and potentially the Mac App Store altogether. >> >> I spent the best part of yesterday reinventing the wheel and implementing my >> own scheduling mechanism to put into a helper app which would run in the >> background constantly as a login item... the timing/scheduling bit works >> fine, but the helper app can't actually DO anything because it runs in a >> different sandbox from the main app!! This means I can't access the user's >> preferences without a temporary entitlement, and can't access the resources >> within my main app at all. >> >> My helper app sits in Main.app/Contents/Library/LoginItems/MainHelper.app >> and is launched (based on user prefs) by calling >> SMLoginItemSetEnabled((CFStringRef)[NSString stringWithString:@"<my app >> identifier>.helpername"], true) >> >> I've tried giving the helper the same bundle identifier as the main app, but >> that doesn't work (as expected, but I wanted to try anyway!). >> >> I've even tried getting the path of the helper app ([[NSBundle mainBundle] >> bundlePath]) and removing the last 4 path components to get the path to the >> main application and launching it via NSWorkspace, so that I could then >> launch my helper that way and inherit the sandbox, but sandboxd gives more >> permission violations when attempting to launch the main application. I >> suspect that would have been cause for appstore rejection anyway! >> >> I feel like I've missed something obvious, but I just can't see it. Is >> there a way to make the helper app run in the same sandbox as the main app? >> >> Many thanks for your help. >> >> Mark >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com >> >> This email sent to z...@mac.com > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/rickcorteza%40gmail.com > > This email sent to rickcort...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
