Thanks Kevin. Since I don’t see a way to edit or add comments to the existing submitted requests from Certificates, Identifiers & Profiles, I submitted a new request with the corrected E2EE VoIP framing you clarified. The new request ID is: JK87HBYZZN I noted in the request that this is a clarification of the previous submitted requests, and that the entitlement is needed specifically for Taski’s E2EE incoming audio/video call flow using reportNewIncomingVoIPPushPayload(_:completion:), not for general message notification filtering. I’ll also continue tracking the watchOS Notification Center timestamp issue separately via FB22781345. Thanks again, Stefano

Thanks Kevin, that clarification helps a lot. A clarification on Taski’s side: today our audio/video calls already use E2EE for the media stream, but the incoming-call VoIP push payload itself is not yet E2EE. The APNs payload currently includes call-related fields such as caller ID, caller name, and call type in cleartext. The signaling side is exactly the gap your “Sending End-to-End Encrypted VoIP Calls” guidance is designed to close, and it is where we would like to evolve next: the backend would send a mutable-content push with an encrypted call payload, our NSE would decrypt it, and then promote it to PushKit via reportNewIncomingVoIPPushPayload(_:completion:). That would let us make Taski’s incoming-call architecture fully E2EE, including the call-related payload fields currently visible in the VoIP push. That is the framing in which the Notification Filtering entitlement is actually needed for us. If the recommended process is to withdraw the existing request and resubmit it with this VoIP framing, I’m happy to do that. Otherwise, I can add a comment/update to the existing request. Any preference? For the watchOS Notification Center timestamp issue, I’ll proceed with the local-route refactor you described in parallel, without waiting on the entitlement. I’ll keep tracking that separately via FB22781345. I’ll also file the duplicate of r.102434375 asking for the reportNewIncomingVoIPPushPayload(_:completion:) entitlement restriction to be removed, and post the bug number here. Thanks again, Stefano

Quick update with results from a diagnostic build I ran on iOS/watchOS 26.5. To validate the distinction you described between the NSE-returned content path and the locally posted notification path, I shipped an internal TestFlight build where the NSE additionally posts a local UNNotificationRequest via UNUserNotificationCenter.add() in parallel with the standard contentHandler() call. The local notification uses the same title and body as the NSE-returned notification, except for a [L] prefix in the body and a local-z- identifier prefix. The same [L] marker is visible on iPhone and Apple Watch, so the local-route notification can be reliably matched across both devices. Test protocol: Send a message with a known timestamp in the body, for example Timestamp 00:19 Wait for delivery on Apple Watch Turn the Watch screen off Wait approximately 2–3 minutes Wake the Watch and open Notification Center Result on Apple Watch, using iOS 26.5 + watchOS 26.5: Local-route notification, [L] Timestamp 00:19: correct relative timestamp, for example “2 minutes ago” when viewed approximately 3 minutes after delivery. NSE-route notification, Timestamp 00:19: incorrect relative timestamp, shown as “Now” despite the notification being several minutes old. A second build with the local probe disabled, leaving only the original NSE-route path matching production, confirmed that the NSE-route notification continues to drift on its own. In that build, I observed its relative timestamp in Apple Watch Notification Center jump from “1 minute ago” to “14 minutes ago” within a few real minutes, i.e. non-monotonic timestamp updates unrelated to the actual delivery time. On iPhone Notification Center, both paths render the correct timestamp consistently. The issue appears to be Watch-only. One interesting note on the symptom in 26.5: on earlier versions, the drift typically appeared as “X minutes/hours ago” on a fresh notification. On 26.5, I’m now also seeing the inverse pattern — “Now” on a notification that is several minutes old — as if the relative timestamp is being re-anchored to a Watch wake or Notification Center refresh event rather than to the original delivery time. This appears consistent with the same underlying issue, just surfaced in a different way. These results seem to support the theory you outlined: the issue appears specific to the path that mirrors NSE-returned push content to Apple Watch Notification Center, while routing the final notification through UNUserNotificationCenter.add() from the NSE preserves the correct timestamp on the Watch. Given this, I would like to move forward with the architectural refactor you described: having the NSE post the final local notifications and dropping the original push via the Notification Filtering entitlement. The entitlement request I submitted earlier is still in the “Submitted” state. If this is the right entitlement for that architecture, any guidance on the recommended follow-up channel, contact, or technical framing would be very welcome. I’ll attach screenshots from the diagnostic build to the Feedback Assistant report when I file it, and I’ll post the FB number here as soon as it’s available. Thanks again, Stefano Bigioggero

Hi Kevin, Thanks for the detailed reply — really helpful framing on the local-notification path. Bug number I’ll file a Feedback Assistant report referencing this thread and post the FB number here as soon as the form completes. System versions Tested on the following device pairs: iPhone 16 Pro on iOS 26.4.2 + Apple Watch Series 10 on watchOS 26.4 iPhone 16 Pro on iOS 26.5 + Apple Watch Series 10 on watchOS 26.5 The drift reproduces with the same test matrix on both 26.4 and 26.5, so the issue is still present on the current release version. Filtering entitlement The “post local notifications from the NSE and discard the push” pattern you described is very relevant to our architecture. To confirm my understanding: in order to actually drop the original push and avoid duplicate notifications, the NSE would need the Notification Filtering entitlement, correct? My NSE currently doesn’t have it. I have already submitted a request for the Notification Filtering entitlement, but it is still in the “Submitted” state. If this is indeed the right entitlement for the architecture you described, any guidance on the correct technical framing or whether there is a better path to follow would be very helpful. Diagnostic step before any refactor Before going through a larger refactor, I plan to ship a small diagnostic build where the NSE additionally posts a local notification in parallel to returning the modified content via contentHandler. The goal is to observe whether that local notification exhibits the same Watch Notification Center drift after the screen turns off and is reopened. If the locally posted notification renders the correct timestamp while the contentHandler-returned notification drifts, that would help isolate the issue to the path that mirrors NSE-returned push content to Apple Watch, and would justify pursuing the entitlement + notification-engine refactor. I’ll report back here with the FB number and the diagnostic build outcome. I’m happy to share an anonymized minimal reproducible Xcode project, NSE logs, screenshots, or the entitlement request details privately if useful. Thanks again, Stefano Bigioggero Taski