Seeking guidance on intercepting system-wide notifications in macOS app

I'm developing a macOS application called Blurt, which aims to provide enhanced notification management in MacOS. The core functionality I'm trying to implement is the ability to intercept and display notifications from various applications in a custom interface.

Current implementation:

  • Using AppDelegate to handle application lifecycle
  • Implemented UNUserNotificationCenterDelegate for handling notifications
  • Created a custom NotificationService extension

Challenges:

  1. Unable to intercept notifications from other applications
  2. System notifications are not being captured by our app

What I've tried:

  1. Using DistributedNotificationCenter to observe system-wide notifications
  2. Implementing a Notification Service Extension
  3. Exploring NSWorkspace notifications

Current roadblocks:

  1. Apple's sandboxing and security model seems to prevent direct access to other apps' notifications
  2. Unable to find a sanctioned API for system-wide notification interception

Questions:

  1. Is there a recommended approach to creating a centralized notification management system within Apple's guidelines?
  2. Are there any specific system notifications or events we can legally subscribe to that might help achieve similar functionality?
  3. How do other notification management apps (if any exist) handle this limitation?
  4. Are there any upcoming APIs or features in macOS that might address this use case?

I'm open to alternative approaches or pivoting the app's functionality if necessary. Any insights, suggestions, or resources would be greatly appreciated.

Thank you in advance for your help!

Answered by DTS Engineer in 793724022

One thing I wanted to clarify to I hope will save you some time. The term "notification" has been used very broadly across our APIs with multiple APIs with VERY different implementations all being called "notifications". If you're not aware of that history, it can seem like the system is blocking/impeding something "could work" when the reality is that the API you're dealing doesn't have ANYTHING to do with the notification center/APNS system.

Case in point:

Using DistributedNotificationCenter to observe system-wide notifications

DistributedNotificationCenter is a longstanding (it's older than MacOS X and was part of NextStep) architecture that uses mach messaging to provide a simple way for process to broadcast small amounts of information to any app that's registered to receive them. It's widely used throughout the system's implementation, primarily for small behavioral "details" which couldn't really justify their own full IPC infrastructure. For example, many appearance settings post a distributed notification when their changed. Specific AppKit controls/components then listen for those notifications so that they can update their appearance if/when the setting changes.

Related to that point, if you've been digging into this you may also have found reference to "darwin notifications", for example, in "CFNotificationCenterGetDarwinNotifyCenter". It was created to provide a notification system that could be used by components written "below" the ObjectiveC/CoreFoundation API layer that the DistributedNotificationCenter is built on, but is also far more limited than the higher level API. It's used very similarly to the DistributedNotificationCenter, except that components involved are lower level components like IOKit.

You also mentioned:

Exploring NSWorkspace notifications

The NSWorkspace notificationCenter is actually a convenience class, not an independant architecture of it's own. Most of it's notifications are actually by messages/callbacks from other APIs (most of which are public) which are then converted into the notification "structure". For example, most of the volume related notifications actually originated with in the DiskArbitration framework. That framework has it's own callback system and data types, so NSWorkspace is "converting" that data into something that's more "directly" useful for basic apps.

https://developer.apple.com/documentation/diskarbitration

All that background leads to here:

Are there any specific system notifications or events we can legally subscribe to that might help achieve similar functionality?

No, I don't see any way to make this work. The push notification system (which also handles local notifications) is an independant system component which doesn't provide any API for managing it's data, nor is that activity really visible/accessible to the larger system.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

One thing I wanted to clarify to I hope will save you some time. The term "notification" has been used very broadly across our APIs with multiple APIs with VERY different implementations all being called "notifications". If you're not aware of that history, it can seem like the system is blocking/impeding something "could work" when the reality is that the API you're dealing doesn't have ANYTHING to do with the notification center/APNS system.

Case in point:

Using DistributedNotificationCenter to observe system-wide notifications

DistributedNotificationCenter is a longstanding (it's older than MacOS X and was part of NextStep) architecture that uses mach messaging to provide a simple way for process to broadcast small amounts of information to any app that's registered to receive them. It's widely used throughout the system's implementation, primarily for small behavioral "details" which couldn't really justify their own full IPC infrastructure. For example, many appearance settings post a distributed notification when their changed. Specific AppKit controls/components then listen for those notifications so that they can update their appearance if/when the setting changes.

Related to that point, if you've been digging into this you may also have found reference to "darwin notifications", for example, in "CFNotificationCenterGetDarwinNotifyCenter". It was created to provide a notification system that could be used by components written "below" the ObjectiveC/CoreFoundation API layer that the DistributedNotificationCenter is built on, but is also far more limited than the higher level API. It's used very similarly to the DistributedNotificationCenter, except that components involved are lower level components like IOKit.

You also mentioned:

Exploring NSWorkspace notifications

The NSWorkspace notificationCenter is actually a convenience class, not an independant architecture of it's own. Most of it's notifications are actually by messages/callbacks from other APIs (most of which are public) which are then converted into the notification "structure". For example, most of the volume related notifications actually originated with in the DiskArbitration framework. That framework has it's own callback system and data types, so NSWorkspace is "converting" that data into something that's more "directly" useful for basic apps.

https://developer.apple.com/documentation/diskarbitration

All that background leads to here:

Are there any specific system notifications or events we can legally subscribe to that might help achieve similar functionality?

No, I don't see any way to make this work. The push notification system (which also handles local notifications) is an independant system component which doesn't provide any API for managing it's data, nor is that activity really visible/accessible to the larger system.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Seeking guidance on intercepting system-wide notifications in macOS app
 
 
Q