Helper Apps and the Sandbox

Is there an approved way to launch a helper app from within a sandboxed Xojo app?

I have an objective-C app (not written by me) bundled up and sandboxed in Xcode 5. I am placing it in the MacOS subfolder of the app bundle that my Xojo program creates. from there i can launch it using monkeybread’s LaunchServicesOpenMBS plug-in. Then i put it through AppWrapper and… nothing. AppWrapper says it is good to go, but the helper app no longer seems to start up, and there is nothing in the console log to indicate that it was blocked.

There are, of course, many, many steps in getting through to a successfully-sandboxed app. I can easily imagine that I missed one or more steps in building this up. For that reason, it would be very useful to see a Xojo app, even a trivial one, that does successfully launch a helper app after it is sandboxed.

I’d like to know the answer on this one too. I don’t sandbox but ultimately I’ll need to.

The helper app shouldn’t be in MacOS, it should be in Resources.
Did you hire out the objc app? If not, I would not codesign it - it should be signed by it’s creator.

I’m not sure if AppWrapper handles bundles within Apps for it’s procedures, that’s something @Sam Rowlands might have to answer.

I just tried to place a sandboxed app “Epub to Text.app” within the Resources folder of another app sandboxed with App Wrapper Mini , and it does not work. The same app launches when the app is not sandboxed.

Here is the error from the Console :

5/30/14 7:28:58.573 PM lsboxd[302]: Not allowing process 651 to launch "/Users/Mitch/Documents/MatchFonts/1-Development/scratch/Builds - strings.xojo_binary_project/Mac OS X (Cocoa Intel)/strings.app/Contents/Resources/Epub to Text.app/Contents/MacOS/Epub to Text" because the security assessment verdict was denied.

From the console message, looks like something special should be set to permit the launch.

I also tried a Unix command line program and got an error message as well :

5/30/14 7:41:10.505 PM sandboxd[124]: ([730]) click(730) deny hid-control

I regularly use shell scripts this way and it works perfectly.

Was Epub(etc) signed before it went in to Resources?
Did AppWrapper change the signature?
What happens if you place it into Resources after signing/sandboxing with AppWrapper?

Yes, Epub to Text was sandboxed before I copied it.

I do not know how to verify the signature change if any.

I tried to copy Epub to Text inside Resources after sandboxing, same error message.

[quote]What happens if you place it into Resources after signing/sandboxing with AppWrapper?
[/quote]
It is my understanding that if you make any change to a signed app after signing, it will break the signature

Oh, hm :confused:
My understanding was that it was a Code Signature and that you could mess with the Resources folder if you wanted to.

Morning,
App Wrapper is capable of signing bundled apps and other executable code, whereas App Wrapper Mini can only sign the frameworks and the main bundle. This is due to Sandboxing and that App Wrapper Mini generates Xojo scripts, which Xojo then executes. Whereas App Wrapper actually walks through the files in your Bundle at sign time, and pokes 'em and what not.

I’ve had success in getting a bundled helper application to be able to launch the main application (this is required for login items). The function I used was NSWorkspace launchAppWithBundleIdentifier and passed in the bundle id of the application. As you already have the MBS plugin, I’m sure that the function is already there.

The other thing to try is NSTask, I need to get onto this for a WIP project. Again the MBS has NSTask functions.

Sadly, not. The Code Signature is like a seal on your application, to confirm the contents within it. Modify it in anyway and the code signature becomes invalid.

That’s good to know, thanks Sam :slight_smile:
I also like your technical terminology: “pokes 'em and what not.”

I have to admit, App Wrapper is my baby, but it’s quite rude and intrusive!

Try to change helper identifier. it should be the same as the main app. eg (com.company.app). and put it in Contents/Library
Also, App Wrapper does not sign helper apps in “Mavericks Code sign Engine” mode. change that to App Wrapper Engine.

The App and the Helper need to have the same bundle identifier. If don’t, it doesn’t work in sandbox App and you Helper need to be placed in a folder ‘yourappname/Contents/Library/LoginItems/’ . Dont’ forget to sign as Mojtaba said.
If I have time this week, I’ll made a tutorial.

[quote=93828:@Valdemar De SOUSA]<…>
If I have time this week, I’ll made a tutorial.[/quote]
Oh yes, pleeeeeze!! :slight_smile:

Could you explain the first part of this? I have used helper applications within my main application, but I hadn’t though of helper applications bundled in that are actually launchers (if I understand correctly). You say this is required for login items?

I have App Wrapper but I’ve been putting off finishing an app because I’m a bit overwhelmed by it. I can’t find a lot of documentation for the different options nor hints about stuff like this (location and options for helper applications, images or fonts, what permissions need to be set for some specific scenarios, etc.).

If there comprehensive documentation not on the app itself (which is a collection of front-ends and automations, and I’m deeply grateful for it) but on how to use it for specific specialized scenarios?

That’s not what I’m seeing here, the helper application has a different bundle identifier than my main application and it works, although I’ve only just submitted it to Apple, so I hope it doesn’t get rejected.

If they do have the same bundle identifier, it breaks Window Restoration, as the helper application wipes out the main application’s window restoration settings :frowning:

AFAIK, like Valdemar says, you create a simple application that does nothing but launch your main application, this application is then placed in the /Contents/Library/LoginItems subfolder of your main application bundle. The application must be in the Applications folder for this to work, then you call SMLoginItemSetEnabled and pass it the bundle identifier of your helper application.

In the helper application I built, I used NSWorkspace launchAppWithBundleIdentifier, and passed it the bundle identifier of the main application.

The basic technique is the OS launches your helper application (which must also be a agent, LSUIElement = YES in the info.plist), which then launches your main application.

This actually makes sense as Apple recommend any bundled executables be code signed, before you add them to your Xcode project. So the Mavericks built-in engine doesn’t need too…

[quote=94017:@Eduardo Gutierrez de Oliveira]I have App Wrapper but I’ve been putting off finishing an app because I’m a bit overwhelmed by it. I can’t find a lot of documentation for the different options nor hints about stuff like this (location and options for helper applications, images or fonts, what permissions need to be set for some specific scenarios, etc.).

If there comprehensive documentation not on the app itself (which is a collection of front-ends and automations, and I’m deeply grateful for it) but on how to use it for specific specialized scenarios?[/quote]
There is some rudimentary help within App Wrapper, sadly writing help is not my strong point.

Login Items are something that I’ve only just encountered myself recently, I used a build script to move them into the correct place.

It’s true, that over the years App Wrapper has grown and now includes a lot of functionality, which can seem overwhelming. I do my best to simplify the application. When I know about specific situations, often because I need them for our software, I do tend to write up how to do it.

Later on, I intend to write up how I got login items to work in Xojo, although I am thinking to re-write my launch helper application in Objective-C as it would save about 11mb of the application package.

If you have questions then please feel free to ask.

I haven’t been able to nail this with Xojo/App Wrapper, so I’d love some guidance on this. For Xcode apps that required helper apps/login items, I used this tutorial successfully http://blog.timschroeder.net/2012/07/03/the-launch-at-login-sandbox-project/

As the application is awaiting review (hoping to get in before the rumored 64-Bit only rule, if it comes into play), what I’d like to do is to confirm that the method I used is approved by Apple. It would be embarrassing if I explained how I did it, only to find that Apple rejects that method!

[quote=94025:@Sam Rowlands]That’s not what I’m seeing here, the helper application has a different bundle identifier than my main application and it works, although I’ve only just submitted it to Apple, so I hope it doesn’t get rejected.

If they do have the same bundle identifier, it breaks Window Restoration, as the helper application wipes out the main application’s window restoration settings :frowning:
[/quote]

I thought that if a helper had a different bundle identifier from its parent application, the helper could not access the parent application data fiolder because it had its own container.

You are correct. In the case of a login item; the helper application doesn’t need access to the parent application’s data, it only needs to launch the parent application.