> > I'm surprised IPC still sucks so badly. I haven't used XPC, but I thought it > was a general-purpose solution for messaging between apps, not just for > communicating with your app's own helper processes. >
I was just doing some reading about it actually to see what it’s all about. If you get down to the xpc manpages (after all there’s a C-API down there somewhere) it is a generic IPC solution with the one caveat that you can’t register a dynamic listener, seems that only launchd is allowed to do that, for security reasons (and you can tell if something was started from /Library/LaunchDaemons or not). So basically you can talk to services listed in the LaunchAgents/Daemons list or you can connect to services in your own bundle which will be started for you. The proposed way to have two apps talk to each other is have them each register with such a running XPC service, under I guess some well-known name. Then app B queries the XPC service for app A’s XPC service it just registered and talks to it that way. What I don’t quite get about that is what kind XPC service you need? I would expect that if you bundled it inside each app, even under the exact same name and UUID and bundle ID etc, then XPC is going to launch a per-app version of the service, which would be useless, unless there’s a way to tell XPC please just make one and share it in some way which is secure. Otherwise you need to install a real one in LaunchAgents so it’s per-user. That then means I guess that anyone could technically talk to it and start shouting at your app and it would be a pain to install it too. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
