Thanks Alex,
Thanks for your reply.
If you're talking about the com.apple.security.inherit entitlement, that only
works for helper apps which are launched via fork/exec from the main
application. When the helper app is launched by LaunchServices (via
SMLoginItemSetEnabled) it crashes immediately as it can't inherit a sandbox
from anywhere.
In a last-ditch attempt, I was trying to get around that by:
Have my helper app launch the main app at startup.
The main app could then launch a second helper (with
com.apple.security.inherit entitlement) to do the scheduling.
Main app then terminates immediately.
The two problems with that approach are firstly, the sandbox wouldn't let the
helper launch my primary app because it's in a different sandbox, and secondly,
my understanding of forking is that even if I could do that, when the main app
terminates, any process it forked also gets terminated doesn't it?
Mark
On 1 Jun 2012, at 02:30, 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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
