Thanks again for your replies --

Maybe I didn't describe this well enough: 

- The daemon is non-graphical of course and runs with or without a login session as root.

- I *do* have GUI applications (the "agents") that are to show UI. As mentioned, the "backup plan" is to use the plist system where they are registered to load at login (/Library/LaunchAgents/*.plist). This works for *most* of the cases.

I know how to manually launch an application that's either registered or not *in the current session* via launchctl. The issue is launching one "in to" another specific session.



Please don't have your daemon launch an app; that's an exercise fraught with compatibility liability.  

Can you elaborate here more? I know they are different worlds, but we do this on Windows without any issue. I already know and track sessions, know when a user logs in or out, etc.

 
The most straightforward solution to this problem is to install a tiny GUI launchd agent [1].  It can then communicate with the daemon, allowing the daemon to know about all the login sessions and send messages to the agent in one specific session or all sessions.  If the agent needs to display GUI, it can either do so directly or launch an app to do so.  It's safe for a GUI launchd agent to launch an app because it is, by definition, running in a GUI login context.

Again this is what I'm calling my "back up plan". It does work most of the time, but there are edge cases in which it would be extremely desirable to programmatically (from the daemon) launch said GUI agents into a users session.

In the end, I think I can make this work with the /Library/LaunchAgents plists perhaps with some KeepAlive logic, but it will require quite a few works arounds in our code base, and it seems odd that there are no clean APIs to programmatically target a session and launch a GUI agent in it from a privileged (e.g. root) service/daemon.

Bryan