Issues with XPC as general IPC

Question

Created Mar ’20

Replies 4

Boosts 0

Views 1.3k

Participants 2

I've found little documentation about this situation as it mostly is focused on XPC in terms of XPC services. My situation is that I have an app, a helper app and a commandline program. The last two reside with in the first app's bundle.

The helper app is not handled by launchd, though may be started as a login item. There are various reasons for this, including the fact that it needs to present UI as well as unique lifecycle/scheduling requirements.

I have been using DO to communicate from the app and commmandline program to the helper. I've been told I could use XPC for this and have done the conversion. The helper has a listener on a mach service name. I am using NS API's, btw, not the xpc_* ones.

There are some problems though:

- It only seems to work if all processes are run or attached from Xcode.

- If any of the end points are run outside of Xcode, any connections are immediately invalidated with no other errors or logs presented.

Based on other articles which touch on this, I'm still not clear if this is a supported configuration and if it isn't, it would be nice to have a definitive answer. Note that all processes are part of the same app bundle. Also, if it isn't supported, it's a bit confusing that it would work within Xcode.

Thanks.

Answered by DTS Engineer in 409014022

I'm still not clear if this is a supported configuration

It is not. In an XPC world, an XPC service can only be provided by a program that’s managed by

launchd

[1].

it's a bit confusing that it would work within Xcode.

Indeed. This works when running from Xcode because Xcode configures the environment in a weird way to support its own debugging goals (specifically, it needs to be able to debug XPC Services).

Given the architecture you described, it sounds like you should put your login item at the core of your product. An XPC login item can provider an XPC service that’s visible to both your app [2] and your tool. See AppSandboxLoginItemXPCDemo for an example of this.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Off the top of my heade I believe that list is currently:

launchd

daemon,

launchd

agent, XPC Service, XPC login item, and system extension.

[2] Modulo the App Sandbox.

Boost

Answer 1

DTS Engineer OP

Apple

Mar ’20

Accepted Answer

I'm still not clear if this is a supported configuration

It is not. In an XPC world, an XPC service can only be provided by a program that’s managed by

launchd

[1].

it's a bit confusing that it would work within Xcode.

Indeed. This works when running from Xcode because Xcode configures the environment in a weird way to support its own debugging goals (specifically, it needs to be able to debug XPC Services).

Given the architecture you described, it sounds like you should put your login item at the core of your product. An XPC login item can provider an XPC service that’s visible to both your app [2] and your tool. See AppSandboxLoginItemXPCDemo for an example of this.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Off the top of my heade I believe that list is currently:

launchd

daemon,

launchd

agent, XPC Service, XPC login item, and system extension.

[2] Modulo the App Sandbox.

0

Answer 2

Mr_Noodle OP

Mar ’20

Thanks for the clarification. The helper (which is the XPC server in this case) is indeed the process which is the login item so I'll look into the example you sent.

A couple of quick questions, though:

- My app is not sandboxed. Aside from the first step in the README which won't apply to me, are there any other caveats?

- Will this work when the app is first installed or anytime the helper is killed? The helper will be launched manually by the outer app and not via login items.

0

Answer 3

DTS Engineer OP

Apple

Mar ’20

My app is not sandboxed.

That’s fine. The focus of this sample is sandboxed apps but the same techniques work for non-sandboxed ones.

The helper will be launched manually by the outer app and not via login items.

That won’t work. See my point above about the program being managed by

launchd

.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 4

Mr_Noodle OP

Mar ’20

Ok, was having various problems with it until I started using LSRegisterURL as SMLoginItemSetEnabled wasn't launching my helper. Things seem a bit more convoluted now but at least I have a working version so I know it's possible. Not fond of "hidden" login items, preferring to have an explicit entry in the login items user interface but I guess you can't have everything.

0