Fabien Bavent
## Summary
NotificationContentRecord
(the native Swift record backing
scheduleNotificationAsync
's
content
) declares
threadIdentifier
as a
@Field
, so it's correctly parsed out of the JS-supplied object and even read back out when serializing a
received
notification. But
toUNMutableNotificationContent()
— the method that builds the actual outgoing
UNMutableNotificationContent
for a
scheduled
local notification — never assigns it. Every other field on that record (
title
,
body
,
categoryIdentifier
,
sound
,
attachments
,
interruptionLevel
, ...) is copied over;
threadIdentifier
is the one silent exception.
Net effect: passing
threadIdentifier
when scheduling a local notification compiles, is accepted by the native module, and does... nothing. iOS falls back to its own default "Automatic" notification grouping instead of the app-authored one that was requested.
_Posted here, it's kind of a bug, but not an error. But I can't, neither I will, create an full application to trigger the issue_
## Where
packages/expo-notifications/ios/ExpoNotifications/Notifications/NotificationRecords.swift
```swift
@Field public
var categoryIdentifier: String?
@Field
var threadIdentifier: String? // <- declared, parsed from input, read back on output...
...
func toUNMutableNotificationContent() -> UNMutableNotificationContent {
let content = UNMutableNotificationContent()
...
if let categoryIdentifier = categoryIdentifier {
content.categoryIdentifier = categoryIdentifier
}
// ...threadIdentifier is never assigned to
content
anywhere in this function.
if let sound = sound {
...
## Fix
```swift
if let threadIdentifier = threadIdentifier {
content.threadIdentifier = threadIdentifier
}
placed alongside the
categoryIdentifier
assignment. One-line native fix. The public
NotificationContentInput
TS type should also expose
threadIdentifier
as an input field — right now it's only documented on
NotificationContentIos
, the read/output-only type (
For the input type, see NotificationContentInput
), so even a caller who wanted to use this had no typed way to do it.
```ts
/**
* iOS notification-thread identifier, used to group related notifications together in
* Notification Center / on the Lock Screen.
* @platform ios
*/
threadIdentifier?: string;
## Reference implementation
I already have a working `patch-package` fix for both changes above, build but not tested against `expo-notifications@57.0.7` (don't have iOS dev license yet). Happy to open this as a PR if useful — let me know.
## How I found this
I was investigating explicit notification grouping on Android (see Support explicit Android notification grouping (`setGroup`/`setGroupSummary`) for local `scheduleNotificationAsync`) and, before assuming iOS was fine by default, went looking for the iOS equivalent of Android's `setGroup`/`setGroupSummary`. `threadIdentifier` is the iOS mechanism for that, and tracing it through the native module is how I found it's a no-op today.
To be clear, this is **not** the same failure mode as the Android issue: iOS doesn't need an app-authored group summary to keep each notification's actions reachable (grouped notifications stay individually addressable via long-press regardless of `threadIdentifier`), so nothing is *broken* by this bug today for apps that don't rely on `threadIdentifier`. It's a silently-dead input, not a crash or a regression — but anyone trying to use it will see it fail with no error or explanation.
## Environment
expo: ~57.0.8
expo-notifications: ~57.0.7
react-native: 0.86.0
Platform: iOS
```
## Related issues
  • #28580 — grouping for
    push
    notifications (
    android.group
    /
    threadId
    in the FCM/APNs payload). Different code path (remote push, not local
    scheduleNotificationAsync
    ); the reporter there also tried
    threadId
    on iOS without success, which is consistent with what I found, but that issue is scoped to push and doesn't diagnose the local-notification root cause.
Searched the repo for existing issues about
threadIdentifier
being dropped/ignored before filing — didn't find one covering this specific gap.