Migrating from Sandboxed NSConnection to NSXPCConnection

Question

Created Nov ’20

Replies 4

Boosts 0

Participants 2

I've a fully functional command line tool (CLT) communicating with its own sandboxed App.
The CLT sends messages to the App and waits until the app closes.
Now I need to migrate to NSXPCConnection and I started to study the AppSandboxLoginItemXPCDemo

The sample works fine so I added a new CLT target to the project but it can't communicate with the helper (I added plist and entitlements to sandbox it)

So now I have two questions

how can I configure the CLT to communicate with the helper?
how the helper can communicate with the App (the helper is the client and the app is the server)?

Boost

Answer 1

DTS Engineer OP

Apple

Nov ’20

Now I need to migrate to NSXPCConnection

Indeed. NSConnection, part of Distributed Objects (DO), has been formally deprecated for a while now, and has had horrible correctness and reliability problems since long before that )-: However, migrating this sort of ad-hoc communication can be quite tricky.

Can you explain more context here? Specifically:

Your app is sandboxed. Is that because it’s distributed via the Mac App Store?
Is the helper tool embedded within the app?
What’s the lifecycle relationship between your app and this helper tool? Who starts the helper tool? And is it expected to run after the app has quit?

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

0

Answer 2

dafi OP

Nov ’20

Hi Quinn,

The app is distributed via the Mac App Store
Actually I'm working inside the AppSandboxLoginItemXPCDemo, so yes the helper tool is embedded withing the app (and also the command line tool)
The answer to your last question is a bit complicated, so I prefer to describe the current scenario (with NSConnection).

The command line tool is used to make only one specific task: start the application from the terminal and "wait" until the application window associated to (or the whole app) is closed.
The command line tool passes (using NSConnection) some parameters to the application and the "wait" flag is one of them.

The command line tool is pretty much identical to the BBEdit command line bbedit and bbdiff helpers but sandboxed for the Mac App Store

0

Answer 3

DTS Engineer OP

Apple

Nov ’20

The command line tool is pretty much identical to the BBEdit command
line bbedit … helpers but sandboxed for the Mac App Store

IMO it’s best to use Apple events for this. It’s hard for a sandboxed app to publish an XPC service that can be accessed from outside of that app [1].

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

[1] The only way to do it is with a Service Management login item, installing using SMLoginItemSetEnabled, and that only makes sense if your app already needs a login item for other reasons. If not, you’re radically increasing the complexity of your architecture and running the risk of bumping into clause 2.4.5(iii) of the App Store Review Guidelines.

0

Answer 4

dafi OP

Nov ’20

IMO it’s best to use Apple events for this. It’s hard for a sandboxed
app to publish an XPC service that can be accessed from outside of that
app [1].

Ok thank you very much. I must rewrite the code in any case so if Apple Events is MAS friendly I will study them

0