NotificationServiceExtension
The docs doesn't say anything about that. In my tests it didn't work. All notifications were getting processed through a single NotificationServiceExtension
.
NotificationContentExtension
For NotificationContentExtension
the docs say:
You may add more than one notification content app extension to your
project, but each one must support a unique set of notification
categories. You specify the categories for your app extension in its
Info.plist file, as described in Declare the Supported Notification
Types.
Customizing the Appearance of Notifications
docs
I verified ☝️ and it worked! FWIW you can use a single a Notification Content Extension for multiple categories.
UNNotificationExtensionCategory (Required)
A string or an array of strings. Each string contains the identifier
of a category declared by the app using the UNNotificationCategory
class.
What's also worth mentioning is that the default plist settings of a NotificationServiceExtension
looks like this:
It's not associating itself with any given category. I tried adding the NSExtensionAttributes
, along with a UNNotificationCategoryExtension
key, value. But even though it compiled, it didn't work!. I think the way Apple decides how to use a Notification Service Extension is based off these two fields:
- A target that its bundleID is prefixed with as the
apns-topic
- An
NSExtensionPointIdentifer
field which must always be set to com.apple.usernotifications.service
. The value of this is different for Today's extension or content notification extension, etc.
So if you have two service extensions then the system has no way of deciding which one it should show
However the default plist settings of a NotificationContentExtension
does have UNNotificationCategoryExtension
key, value included:
Also thinking about this more, if an app has 5 different categories and has a service extension for each each of them and receives them all at once, then it would fire up 5 different processes (think of 5 parallel didFinishLaunchingWithOptions
callbacks. One for each category and process) and that's bad for the OS.
While not certain, the documentation on Signal's NotificationService class supports this theory.
// Note that the NSE does *not* always spawn a new process to
// handle a new notification and will also try and process notifications
// in parallel. `didReceive` could be called twice for the same process,
// but will always be called on different threads. To deal with this we
// ensure that we only do setup *once* per process and we dispatch to
// the main queue to make sure the calls to the message fetcher job
// run serially.
The same isn't true for NotificationContentExtension
. It can't process 5 contentExtensions at once. Because it's a UI featured which is gated by the main thread.