I'm seeing a timestamp display issue on Apple Watch Notification Center, and I'd like to confirm whether this is a known watchOS behavior or whether there's a setup mistake on our side.
Symptom
The same APNs notification displays the correct time on iPhone Notification Center and on the initial Apple Watch banner. After the Watch screen turns off and the user later opens Notification Center on Apple Watch, the same notification may show an incorrect relative timestamp such as "3 hours ago" or even "yesterday". The drift is per-notification and persists for that notification until it's dismissed.
iPhone NC always shows the correct time. WhatsApp tested side-by-side on the same iPhone/Watch pair does not show this drift.
Setup
- iOS 26.4.2 on iPhone 16 Pro
- watchOS 26.4 on Apple Watch Series 10
- App with paired Apple Watch
- A
UNNotificationServiceExtensionthat decrypts E2EE message previews and applies Communication Notification enrichment viaINSendMessageIntentandcontent.updating(from:) - Production APNs environment, TestFlight builds
- No beta software
Isolation tests already performed
| Minimal APNs (alert + sound only) | no | no | no drift |
NSE skips content.updating(from:), INInteraction.donate/delete (still calls them as no-op via diagnostic build) | yes | yes — modifies content | drift |
NSE bypasses ALL Intents/Communication Notification APIs (no INPerson, no INSendMessageIntent, no avatar, no updating(from:)); just modifies title/body/sound/category and returns the mutable copy | yes | yes — modifies content | drift |
| Production-like APNs payload (thread-id, target-content-id, category, sound, badge, custom userInfo) but WITHOUT mutable-content | no | no | no drift |
Eliminated as causes: content.updating(from:), INSendMessageIntent, INInteraction.donate, INInteraction.delete(with:), INPerson/INPersonHandle (not even constructed in test 3), avatar fetching, thread-id, target-content-id, category, sound, badge, custom userInfo, custom createdAt timestamp, stale Siri/Apple Intelligence history (cleared manually on iPhone and Watch).
The pattern
The only consistent variable distinguishing the no-drift cases from the drift cases is whether mutable-content: 1 is set on the APNs payload (i.e. whether the UNNotificationServiceExtension is invoked). Once invoked, the extension's behavior with respect to Communication Notifications does not seem to affect the outcome — the drift reproduces even when the NSE only modifies title/body/sound and returns.
Questions
- Is there a known watchOS behavior where notifications processed by a
UNNotificationServiceExtensionuse a different timestamp source on Apple Watch Notification Center after the Watch screen has been turned off and reopened, while the initial Watch banner and iPhone Notification Center show the correct delivery time? - Are there specific
UNMutableNotificationContentproperties or APNs payload flags that should be preserved (or avoided) when returning content from an NSE to keep the Watch NC timestamp consistent with the delivery time? - For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS?
Happy to provide an anonymized snippet of NotificationService.swift and the APNs payload format if useful.
Thanks.