About notification of application launch and registration to "LaunchDaemons"

Which specific notification are you registering for?

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

Which specific notification are you registering for?

"NSWorkspaceDidLaunchApplicationNotification" and "NSWorkspaceDidActivateApplicationNotification" are registered.
Neither can get notifications.

Ah, I figured that might be the case. NSWorkspace is part of AppKit and AppKit is not a daemon-safe framework. You will not get reasonable results via this approach. For more background on this issue, see Technote 2083 Daemons and Agents.

Note The specific issue here is that the NSWorkspace view of the world is confined to a particular GUI login session. If you have two GUI users logged in, an app running in user A’s session won’t get NSWorkspace notifications about user B launching an app. This is as it should be, but it means that the API makes no sense in a daemon context.

How you proceed from here depends on what your overall goal. Is this a security product, where the goal is to log app launches? If not, what is your goal in receiving these notifications?

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

Is this a security product, where the goal is to log app launches? If not, what is your goal in receiving these notifications?

This is a security product that aims to log app launches.
Is there a way to solve this problem?

This is a security product that aims to log app launches.

Our general advice for security products is that they adopt Endpoint Security (ES). This gives you access to process launches via the ES_EVENT_TYPE_NOTIFY_EXEC message.

Note The best intro to ES is WWDC 2020 Session 10159 Build an Endpoint Security app.

The main drawback to this approach is that you lose a lot of context. A process is a kernel level construct whereas an app is a user-level one. NSWorkspace is closer to the user and thus gives you more context about user operations.

One option here is to run a launchd agent in each GUI login session that talks to NSWorkspace and forward results on to your ES client. However, this isn’t without its challenges. A launchd agent is ultimately under the control of the user — for example, the user can unload the agent — and thus you have to account for the possibility of your agent being subverted.

Finally, if there’s some bit of context that your ES client need but isn’t provided by the current ES API, I recommend that you file an enhancement request describing your requirements.

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