XPC activity doesn’t fire while main app is closed

it stops being called once the main app terminates.

That’s what I’d expect. launchd jobs run within a session. In the case of an XPC service bundled in your app [1], that session is created when the app launches and destroyed when the app quits. When the session goes away, there’s no context in which to run your XPC activity.

Could I have a bundled XPC service double as a launch agent, or would that cause other problems?

No. But you could create a launchd daemon that vends a named XPC endpoint, which should get you where you want to be.

I recommend that you install your agent using SMAppService.

I recommend that you configure your agent to launch on demand, which allows the system to stop it when it’s idle (no traffic to the named XPC endpoint and no XPC activity running).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] This is the only valid option for third-party products. See the discussion of the ServiceType property in the xpcservice.plist man page.

That all makes sense, thanks! With “named XPC endpoint”, do you mean an entry under MachServices in my agent’s launchd.plist(5)? Also, since my app is sandboxed, what’d be the best way to allow it to access the endpoint: a Mach temporary exception entitlement, or an app group?

With “named XPC endpoint”, do you mean an entry under MachServices … ?

Yes. At least in this case. I use that term as a catch all for XPC endpoints that you connect to by name, using -[NSXPCConnection initWithMachServiceName:options:] and equivalent routines in other XPC APIs. That includes stuff published via the MachServices property in launchd daemons and agents, but also other more obscure stuff [1].

In short, it’s a named Mach service that speaks the XPC protocol.

Previously I used the term XPC service for this, but that term has another well-defined meaning, namely, a small program with the .xpc extension that vends an XPC endpoint accessible via -initWithServiceName:.

what’d be the best way to allow it to access the endpoint: a Mach temporary exception entitlement, or an app group?

It depends on your deployment path. The temporary exception entitlement is easier but only if you’re distributing your app directly, with Developer ID signing. If you’re distributing on the App Store, an app group is the best option.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Service Management login items, I’m looking at you!

Perfect, thanks for the help!