OK. First things first, I need to draw a distinction between a Mac App Store app and a Developer ID app that has opted in to the App Sandbox. The key difference here relates to temporary exception entitlements. In a Mac App Store app, these have to be approved by App Review and, in my experience, they are very reluctant to do this. In contrast, Developer ID apps can use temporary exception entitlements at will.
This is relevant here because a sandboxed app cannot reach out and connect to an arbitrary XPC service. To do this, you’ll need to global Mach service temporary exception entitlement (
com.apple.security.temporary-exception.mach-lookup.global-name
). So, the arrangement you propose is only feasible in a Developer ID app.
Beyond that, I can’t see any specific problem with your proposal. You wrote:
or only when the app runs?
You should make your agent launches on demand, which should then allow the system to terminate it when it’s not in use.
Main app somhow manages to connect to all services that are "connected" to the plugin service
You can definitely do that using an XPC endpoint. The app would connect to the agent telling it what plug-in it wants to use. The agent then connects to the plug-in’s service in order to ‘check in’. The plug-in’s reply contains an XPC endpoint. The agent can include that in its reply to the app. At this point the app can connect to the plug-in directly via that endpoint.
The main problem here is lifecycle management. For example, if the plug-in crashes, it won’t be relaunched by the app’s connection. The app would have go back through the agent to get it to start.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"