Mac app helper (login element) unable to communicate with

Question

I did exactly the same as the Sandboxed Helper application example provided by Apple, and everything seems to be working fine. I can successfully create the NSXPCConnection object and also return my remote object (via remoteObjectProxyWithErrorHandler ).

However, when I call the method on the proxy object (defined in the protocol definition), I return this error:

 Failed to connect to launch agent: Error Domain=NSCocoaErrorDomain Code=4099 "Couldn't communicate with a helper application. 

In fact, no matter what I do, I can not communicate with my supporting application. I am not doing anything, just trying to make a simple call to a helper application in NSLog (). But that will not work. Strange I also do not see a way out from the inside:

 - (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection 

What can i do wrong?

UPDATE: Obviously, if I uncheck the "Enable application sandbox" in my main application, it will work! So something is wrong with the support of the sandbox, after which she does not want to communicate with my auxiliary application. Do I need more rights? I tried them all under xcode!

Answer 1

Your helper application is isolated. Thus, it cannot register the mach service dynamically, although Xcode allows it to be used for debugging.

However, when you add your helper application to the input elements (using SMLoginItemSetEnabled ()), startd automatically registers the mach service for the name with its package identifier.

Now your main application is isolated. Therefore, random messaging is not allowed. The only way to make it work is to add a temporary permission for the search.

Since 10.7.4. Apple introduced application group rights as a solution for this case, when the application must interact with the supporting application.

Both applications must have the same rights to application groups. It can be any value, but Apple requires this value to begin with your Team identifier (for example, Team-id.myApp). Then, the ID of your supporting application should start with the same right (for example, Team-id.myApp.myHelperApp). After that, your main application can freely communicate with your auxiliary application using the XPC connection with the service named with the identifier of the auxiliary application package (i.e. Team-id.myApp.myHelperApp). In addition, these two applications will share access to the group container folder named with the right of the application group (e.g. ~ / Library / Group Containers / Team-id.myApp), which you must manually create if you need it.

Answer 2

So, I learned the hard way - there are many problems with Sandboxing and XPC, not to mention helper applications and exchange databases using the so-called “shared group directory”, which is not created automatically (as the documentation says incorrectly), and NSURL does not offer the method that he claims in the documentation.

Although the documentation states that in Entitlements you can specify any line as "common application identifier" in the format <TEAM_ID>.whatever , it is obvious that it will work ONLY if you use the format: <TEAM_ID>.com.yourcompany

Anything else and it won’t work. It will compile, it will be archived, it will work, but it will not allow you to talk with its auxiliary application. After spending about 30 hours, I thought that I would try this last change, and apparently that's all! Submitting a radar to the terribly written documentation for the sandbox (which many complain about at the Apple Developers Forum) more ...