What does the thread-id field actually do?

Question

jonchambers OP

Created Dec ’16

Replies 4

Boosts 0

Views 8.6k

Participants 2

Hi, everybody!

The `thread-id` APNs payload field was introduced earlier this year. According to the APNs docs, users should:

> Provide this key with a string value that represents the app-specific identifier for grouping notifications. The system groups notifications with the same thread identifier together in Notification Center and other system interfaces.

In testing, though, I haven't been able to spot any differences in behavior between notifications with and without a thread ID. I've tried:

- Sending only notifications with the same thread ID

- Sending notifications with different thread IDs

- Sending a combination of notifications with and without thread IDs

- Sending notifications to multiple apps with various combinations of thread IDs

In all cases, notifications seem to appear on the home screen in the order in which they were received and in Notification Center in the order they were received, but grouped by application. What actual behavioral changes should I be looking for with a thread ID? Thanks!

Answered by jonchambers in 201748022

As Adam Jones of the apns2 project points out, the behavior we're looking for here is actually pretty subtle. It appears that iOS itself won't do much with the thread ID, but instead gives the receiving application an opportunity to take action. A better explanation from the didReceiveNotification: docs:

> The system calls this method to deliver notifications to your Notification Content app extension. Use this method to configure the contents of your view controller or to incorporate content from a new notification. This method may be called multiple times while your view controller is visible. Specifically, it is called again when a new notification arrives whose

threadIdentifier

value matches the thread identifier of the notification already being displayed. The method is called on the main thread of your extension.

Boost

Answer 1

jonchambers OP

Dec ’16

My mistake; it looks like this has already come up in another thread, but was never resolved. I'll file a bug report.

0

Answer 2

jonchambers OP

Dec ’16

I've filed this as rdar://29670386.

0

Answer 3

jonchambers OP

Dec ’16

Accepted Answer

As Adam Jones of the apns2 project points out, the behavior we're looking for here is actually pretty subtle. It appears that iOS itself won't do much with the thread ID, but instead gives the receiving application an opportunity to take action. A better explanation from the didReceiveNotification: docs:

> The system calls this method to deliver notifications to your Notification Content app extension. Use this method to configure the contents of your view controller or to incorporate content from a new notification. This method may be called multiple times while your view controller is visible. Specifically, it is called again when a new notification arrives whose

threadIdentifier

value matches the thread identifier of the notification already being displayed. The method is called on the main thread of your extension.

0

Answer 4

honey9 OP

Mar ’20

The accepted answer is misleading!
If all you want is too group notifications on the device's notificationCenter then you don't need `NotificationContentExtension`!

Just pass in `thread-id` in your payload. The only problem is that you have to wait a bit so the iOS renders the notifications into groups. After it renders the first time, then it starts to work. This seems like a bug to me!
The following quote on docs is about something else:
>The system calls this method to deliver notifications to your Notification Content app extension. Use this method to configure the contents of your view controller or to incorporate content from a new notification. This method may be called multiple times while your view controller is visible. Specifically, it is called again when a new notification arrives whose

threadIdentifier

value matches the thread identifier of the notification already being displayed. The method is called on the main thread of your extension.
Think of iMessage.
You get a message from your friend.
You Long press the notification.
It will open a pop where you can chat from within the contentExtension
If your friend sends more messages, then your content-extension's ` didReceiveNotification: docs again because the payload will be of the same `threadi-d`. It gets called so you can update the conversation.
☝has nothing to do with grouping.
Grouping and getting continous callbacks to your contentExtension for a single thread-id are just two separate use cases of using `thread-id`!

0