UserNotifications UNUserNotificationCenter migration from NSUserNotification
Parent: macOS Menu-Bar App Design · Published reference · snapshot 2026-10-02
↓ Facts as markdownall context files
Source-anchored research for UserNotifications UNUserNotificationCenter migration from NSUserNotification. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- UNUserNotificationCenter is the replacement. It is available on macOS 10.14 and later, so any app targeting macOS 26-27 can use it without availability checks. (high confidence) [source]
Problems, failure modes and limitations
- Apple's documentation marks NSUserNotification as deprecated at macOS 11.0 (introduced 10.8), with the message that all NSUserNotifications API should be replaced with UserNotifications.framework API. (high confidence) (verified as of 2026-10-02) [source]
- Python processes that are not an app bundle, such as Homebrew or conda Python, cannot use UNUserNotificationCenter. desktop-notifier falls back to a dummy backend that silently drops notifications. Its author says the API works only from a signed framework Python build or a bundled app, and that notifications appear to come from 'Python' unless the app is bundled. This matters for a PyObjC menu-bar app: ship it as a signed .app with its own bundle identifier. (medium confidence) [source]
- Calling requestAuthorization from a nested helper bundle (Notifier.app inside MyApp.app) was reported to fail with NSCocoaErrorDomain Code=4099, 'connection to service named com.apple.usernotifications.usernotificationservice was invalidated'. The thread has no accepted answer. Post notifications from the main app bundle. (low confidence) [source]
Comparisons and alternatives
- The user must authorize notifications. The first requestAuthorization call prompts and records the answer. Later calls do not prompt. Apple says to call getNotificationSettings and check authorization before scheduling, because the user can change settings at any time. It also advises requesting in context rather than blindly at first launch. Provisional authorization delivers quietly to Notification Center history with no prompt. (high confidence) [source]
Facts and statements
- UNUserNotificationCenter needs a valid main bundle. From an unbundled LaunchAgent, currentNotificationCenter asserts 'bundleProxyForCurrentProcess is nil'. The forum workaround is a bundled menu-bar app that receives requests over XPC and posts them. The old NSUserNotificationCenter worked without a bundle, which is why it was the quick fix. (medium confidence) [source]
- Apple's authorization guide says a notification delivered while the app is in the foreground reaches the delegate's willPresent method. Without a UNUserNotificationCenterDelegate implementing it, the system does not show a banner for the active app. A menu-bar app can count as foreground, so set the delegate before the first post. (low confidence) [source]
- On macOS 26, a Swift @MainActor class that passes a closure to requestAuthorization crashes at launch with EXC_BREAKPOINT/SIGTRAP. UserNotifications calls the closure on its own queue (UNUserNotificationServiceConnection.call-out) and the runtime traps on the executor check. macOS 15 tolerated it. The fix is to mark the callbacks @Sendable. In an LSUIElement app the crash shows no dialog or Dock icon, so check ~/Library/Logs/DiagnosticReports/. (low confidence) (verified as of 2026-10-02) [source]
Children
- No children recorded.