I am currently building a sandboxed app that also contains:
- Finder Sync Extension (sandboxed)
- XPC Service (sandboxed)
The XPC Service exists to facilitate communication between the host app and the Finder Sync extension.
So far, I have succesfully established an NSXPCConnection from the host app to the XPC service and was able to invoke a method on the XPC service from the host app. However, when I try to create a similar connection upon instantiation of the principal class of the Finder Sync extension, I immediately receive an error saying that the connection to the service was invalidated. I have confirmed that the XPC service is running, but somehow the connection is still invalidated immediately. I am also using the exact same service name when establishing the connection from the host app and when doing the same thing from the Finder Sync Extension.
- What could be the reason that the NSXPCConnection is invalidated immediately?
- Is there some kind of sandbox restriction at play here?
- Is communicating throught an XPC Service the recommended IPC architecture for a sandboxed app to communicate with an embedded Finder Sync Extension?
The XPC Service exists to facilitate communication between the host app and the Finder Sync extension.
The problem here is that app-based XPC Services are scoped to the app that contains them, and you have two apps in play (well, your Finder Sync extension is an app extension, but it behaves like an app in this regard). Thus, if you put your XPC Service inside your app, it can only be seen by your app. And if you put your XPC Service inside your app extension, it can only be seen by your app extension.
The standard way out of the conundrum is to use an XPC login item for this shared state. Due to an accident of how these are implemented, they are visible to both your app and your app extension. For an example of such a login item, see AppSandboxLoginItemXPCDemo.
This approach is ideal if your Finder Sync extension needs a persistent presence, which is pretty common. However, if your Finder Sync extension needs to share state but does not need the code sharing that state to be running all the time, this is clearly suboptimal. If that’s the case then I recommend that you file enhancement request requesting a way to share this state without the login item.
If you do file a bug, please post the bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"