I have a VoIP app, now try to implement the new method which support the "PKVoIPPushMetadata" in iOS 26.4. Code as below: /// iOS 26.4+ (SDK with `PKVoIPPushMetadata`): prefer this path for VoIP per Apple; completion is `@Sendable` on supported SDKs. @available(iOS 26.4, *) func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingVoIPPushWith payload: PKPushPayload, metadata: PKVoIPPushMetadata, withCompletionHandler completion: @escaping @Sendable () -> Void) { print("willtest: didReceiveIncomingVoIPPushWith: metadata=\(metadata)") handleVoIPPush(payload: payload, metadataMustReport: metadata.mustReport, completion: completion) } func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { print("willtest: didReceiveIncomingPushWith: PKPushType=\(type)") handleVoIPPush(payload: payload, metadataMustReport: nil, completion: completion) } But the voip push only goes to the old method on my iOS26.4 device(iPhone17). And it will go to the new method after I delete the old method. So how can I use this method in my app? I must support iOS16+ versions.

Hello, We are experiencing an issue related to push notifications after updating devices to iOS 26.4 Beta. Our system stores push notification tokens on the server by associating the device token with the device’s IDFV in the app. After updating a device to iOS 26.4 Beta, we observed that the device token from a previously uninstalled version of the app remains valid for more than a week. As a result, two push notifications are delivered to the same device. The situation is as follows: The user installs the app and a device token is generated. The user uninstalls the app. Later, the user installs the app again and a new device token is generated. However, the previous device token does not become invalid, even after more than a week. Because IDFV changes when the app is reinstalled, our server cannot determine that the device belongs to the same user. Therefore, we cannot overwrite the old token with the new one on the server side. Could you please advise: Is this behavior expected in iOS 26.4 Beta? How long does it normally take for a device token to become invalid after an app is uninstalled? What is the recommended approach to prevent duplicate push notifications in this situation? Any guidance would be greatly appreciated. Best regards

In my VoIP app, we use StartRing and StopRing via VoIP push to my app. But recently, I found some disordered VoIP notifications, my VoIP app received the StopRing push before the StartRing push. Examples: Server log: // send StartRing startring: - Apr 9, 2026 @ 14:54:43.255 .."pushType":"voip","priority":10, ... // send StopRing stop-ring Apr 9, 2026 @ 14:54:47.645 ..."pushType":"background","priority":5,"... VoIP app log: // receive StopRing 2026-04-0909:54:48.858 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StopRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 // receive StartRing 2026-04-0909:54:49.524 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StartRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 Then we can see the StartRing send first, but received in the app after the StopRing. The StartRing took abunt 6s to send and the StopRing took about 1s. So I guess there is an issue in the APNs part on iOS26.4. We saw there is a peak after iOS26.4 and iOS 26.4.1 than old iOS versions. Thanks.

Hi everyone, I have developed an app that requires push notifications to notify users to respond to a questionnaire. After login, I inform the user that the app needs push notifications in order to function properly, and I request their consent to receive notifications. However, during the review process, Apple keeps rejecting the app with the following message: Issue Description The app requires push notifications in order to function. Next Steps Push notifications must be optional and must obtain the user's consent to be used within the app. Anyone knows how to fix this problem? Thank You

I have been fighting this problem for two months and would love any help, advice or tips. Should I file a DTS ticket? Summary We attach a JPEG image to a local notification using UNNotificationAttachment. iOS reports the delivered notification as having attachments=1, but intermittently no image preview appears in Notification Center. In correlated cases, the attachment’s UNNotificationAttachment.url (which points into iOS’s attachment store) becomes unreadable (Data(contentsOf:) fails) even though the delivered notification still reports attachments=1. This document describes the investigation, evidence, and mitigations attempted. Product / Component UserNotifications framework UNNotificationAttachment rendering in Notification UI (Notification Center / banner / expanded preview) Environment App: OnThisDay (SwiftUI, Swift 6) Notifications: local notifications scheduled with UNCalendarNotificationTrigger(repeats: false) Attachment: JPEG generated from PhotoKit (PHImageManager.requestImage) and written to app temp directory, then passed into UNNotificationAttachment. Test contexts: Debug builds (direct Xcode install) TestFlight builds (production signing) iOS devices: multiple, reproducible with long runs and user clearing delivered notifications Expected Result Delivered notifications with UNNotificationAttachment should consistently show the image preview in Notification Center (thumbnail and expanded preview), as long as the notification reports attachments=1. If the OS reports attachments=1, the attachment’s store URL should remain valid/readable for the lifetime of the delivered notification still present in Notification Center. Actual Result Intermittently: Notification Center shows no image preview even though the app scheduled the notification with an attachment and iOS reports the delivered notification as having attachments=1. When we inspect delivered notifications via UNUserNotificationCenter.getDeliveredNotifications, the delivered notification’s request.content.attachments.first?.url exists but is unreadable (attempting Data(contentsOf:) returns nil / throws), i.e. the backing attachment-store file appears missing or inaccessible. In some scenarios the attachment-store file is readable for hours while the notification is pending, and then becomes unreadable after the notification is delivered. Reproduction Scenarios (Observed) Next-day reminders show attachment-store unreadable after delivery 1. Schedule a one-shot daily reminder for next day (07:00 local time) with UNCalendarNotificationTrigger(repeats: false) and a JPEG attachment. 2. During the prior day, periodic background refresh tasks verify the pending notification’s attachment-store URL is readable (pendingReadable=true). 3. After the reminder is delivered the next morning, the delivered snapshot shows the delivered notification’s attachment-store URL is unreadable (readable=false) and Notification Center shows no preview. Interpretation: the attachment-store blob appears to become inaccessible around/after delivery, despite being readable while pending. Evidence and Instrumentation We added non-crashing diagnostic logging (Debug builds) around: Scheduling time Logged that we successfully created a UNNotificationAttachment from a unique temp file. Logged that UNUserNotificationCenter.add(request) succeeded. Queried pendingNotificationRequests() and logged the scheduled request’s attachment url.lastPathComponent (iOS attachment-store filename). Delivered time (when app becomes active) Called UNUserNotificationCenter.getDeliveredNotifications and logged: delivered count, attachment count attachment url.lastPathComponent whether Data(contentsOf: attachment.url) succeeds (readable=true/false) Content fingerprinting Fingerprinted the exact JPEG bytes we wrote (SHA-256 prefix + byte count). Logged the iOS attachment-store filename (url.lastPathComponent) returned post-scheduling. Decode validation probe (later addition) When Data(contentsOf:) succeeds, we validate it decodes as an image using CGImageSourceCreateWithData and log: UTI (e.g. public.jpeg) pixel width/height magic header bytes What we tried / Mitigations Proactive “self-heal” for pending notifications Change: during background refresh/foreground refresh, verify the pending daily reminder’s attachment-store URL readability. If it’s unreadable, reschedule with a new attachment (same trigger). Rationale: if iOS drops the store file before delivery, recreating could repair it. Result: We observed cases where pending remained readable but delivered became unreadable after delivery, so this doesn’t address all observed failures. It is still valuable hardening. Increase scheduling frequency / reschedule closer to fire time (proposed/considered) We discussed adding a debug mode to always recreate the daily reminder during background refresh tasks (or only within N hours of fire time) to reduce the time window between attachment creation and delivery. Status: experimental; not yet confirmed to resolve the “pendingReadable=true → delivered unreadable after delivery” failure. Impact The primary UX value of the daily reminder is the preview photo; missing previews degrade core functionality. Failures are intermittent and appear dependent on OS attachment-store behavior and Notification Center actions (clearing notifications), making them difficult to mitigate fully app-side. Notes / Questions for Apple 1. Is iOS allowed to coalesce/deduplicate UNNotificationAttachment storage across notifications? If so, what is the retention model when delivered notifications are removed? 2. If a delivered notification still reports attachments=1, should its attachment-store URL remain valid/readable while the notification is still present in Notification Center? 3. In “next-day” one-shot scheduling scenarios, can the attachment-store blob be purged between scheduling and delivery (or immediately after delivery) even if the notification remains visible? 4. Is there a recommended pattern to ensure attachment previews remain stable for long-lived scheduled notifications (hours to a day), especially when using UNCalendarNotificationTrigger(repeats: false)? Minimal Code Pattern (simplified) 1. Generate JPEG (PhotoKit → UIImage → JPEG Data). 2. Write to a unique temp URL. 3. Create attachment: UNNotificationAttachment(identifier: <uuid>, url: <tempURL>, options: [UNNotificationAttachmentOptionsTypeHintKey: "public.jpeg"]) 4. Schedule notification with a calendar trigger for the next morning.

Hi all, I’m trying to determine whether the loudness gap I’m seeing between AlarmKit alert playback and normal app-managed playback is expected behavior, a sound-asset issue, or something that should be reported as a bug. Observed behavior When an alarm fires through AlarmKit while the device is locked, the alarm sound is significantly quieter than playback of the same or very similar audio once the app is active and using its own audio session. The difference is large enough that it does not feel like a small mastering difference. It feels like the AlarmKit / system alerting path is using a meaningfully lower effective output level than normal app playback. Test scenario My repro is roughly: Schedule an alarm with AlarmKit. Lock the device. Let the alarm fire and listen during the system alerting phase. Enter the app / continue into the app-driven alarm experience. Play the same or equivalent alarm asset via app-managed playback. Result: AlarmKit / lock-screen alerting phase sounds much quieter. In-app playback sounds noticeably louder and fuller on the same device. Current implementation Alarm flow is currently split into two paths: 1) System alarm path Alarm scheduling and alert surfacing via AlarmKit Device may be locked No attempt to manipulate system volume No private APIs 2) In-app playback path After app activation, playback uses: AVAudioSession category .playback AVAudioPlayer Audio is routed as normal app playback This path sounds substantially louder than the AlarmKit path Important detail I am not asking how to override system volume. I understand that AlarmKit appears to follow the system ringer / alert volume model and does not expose a public API for custom alarm loudness. My question is narrower: Is it expected that the same asset or an equivalent asset will sound materially quieter during the AlarmKit alerting phase than during ordinary app playback with AVAudioSession(category: .playback)? Questions Is the lower perceived loudness during AlarmKit alerting an expected property of the framework / system alarm path? Does AlarmKit playback use a different output path, gain policy, processing chain, or speaker treatment than normal app playback with .playback? Are there recommended authoring constraints for AlarmKit alarm sounds to maximize perceived loudness on iPhone speakers? transient-heavy mix stronger mids reduced low-end different LUFS / peak strategy shorter attack, etc. Has anyone measured this directly with: the same WAV / CAF file same device same system volume locked AlarmKit playback vs unlocked in-app playback If this is not expected, would Apple want this reported as a bug with: sample project exact iOS version device model screen recording / audio recording What I’m trying to figure out For alarm-app UX, this matters a lot because: AlarmKit is the most reliable lock-screen/system path. But if AlarmKit playback is substantially quieter than normal app playback, the alarm experience is inconsistent depending on device/app state. That makes it hard to know whether to treat this as: expected system behavior, a framework limitation, an asset/mastering problem, or a bug. If anyone has tested this in a controlled way or received guidance from Apple/DTS, I’d appreciate any technical detail. Thanks.

Hello! I’m building a VoIP app for iPhone and Apple Watch using PushKit and CallKit. I’m trying to understand the recommended watchOS architecture for this kind of setup. What we would like is for the watch to behave as an endpoint for incoming calls, so that when a call comes in the user can answer on either the iPhone or the watch. My understanding is that VoIP notifications are not supported on watchOS, so for incoming calls what we ended up having to do was send the watch a regular APNs alert notification and only start the actual call setup after the user interacts with it. This isn’t ideal, and the notification often appears a few seconds late. What we would like to be able to do is present the incoming call on the watch more like how FaceTime calls appear on Apple Watch. So I wanted to ask whether this is the intended pattern for a companion watchOS VoIP app. Is using a regular APNs alert notification the correct way to surface an incoming call on the watch, or is there a better supported approach? Thanks!

I'm working on an app, and currently, 2 things dont work: account creation and notifications. I want to find the root of why these errors are occurring, and I want to know if these errors are coming from Firebase, certain settings in Xcode not being checked, or my actual written code not being typed correctly. I've tried to run my issue through ChatGPT many times to pretty much no success, so any help on what to do so I can clear certain areas and make sure the bugs aren't from certain spots, and help me narrow down the issue would be great. Otherwise, if there are other guides or threads I can be linked to, and help me fully break down the issue, that would be great. Thank you for your time reading, and I hope I can get some advice.

I am getting InvalidProviderToken for every APNs key I create under my team. This has persisted for over a week across 3 different fresh keys. Setup: Team ID: QJLCAXKWMB Bundle ID: com.trackntakeit.app All keys: Team Scoped, All Topics, Sandbox & Production JWT: ES256, correct kid and iss fields Tested directly from Mac via curl with fresh tokens The key file is a valid EC 256-bit private key. JWT is correctly formed. Both production and sandbox endpoints return InvalidProviderToken. Case number with Apple Developer Support: 102857626802 Has anyone seen all APNs keys for an entire team being rejected? Could there be an account-level block on APNs?

We have an iPhone app with a companion watchOS app for factory alert monitoring. What we want to achieve is: each server event is an independent event, not just a latest-state update events should not be dropped in some scenarios, new events may arrive as frequently as once per minute the watch app state/UI should reflect the event almost in real time our target is roughly within 5 seconds the watch app is expected to be opened by the user when they want to confirm details, but we want the data to already be there even if the watch app was previously in the background notification mirroring is already sufficient for immediate user awareness; the question is about reliable background data/state delivery to the watch app Our current architecture is: The server sends APNs pushes to the iPhone app. We use both: alert pushes for user-visible notifications background pushes (content-available: 1, apns-push-type: background, apns-priority: 5) for background data delivery When the iPhone app receives the push, it relays data to the watch using WatchConnectivity. On the iPhone/watch side: we use sendMessage when reachable / foreground-like communication is possible we use transferUserInfo as the background / unreachable fallback The devices are paired and connected, and the apps are not force-quit. In practice, the behavior is not stable enough for this requirement: some background deliveries are delayed some relays to the watch are not timely the end-to-end behavior is not reliable enough for independent event delivery with near-real-time expectations My understanding is that: APNs background pushes are not guaranteed and may be throttled WatchConnectivity background delivery is opportunistic immediate WC messaging depends on reachability / active state So the main question is not how to debug a single implementation issue, but whether our expectation is valid at all on Apple platforms. Questions: Is this architecture fundamentally unsuitable if the requirement is lossless, near-real-time event delivery from server -> iPhone -> watch, with a target of roughly within 5 seconds? Even if the implementation is correct, should we expect iPhone background push + WatchConnectivity relay to remain inherently non-deterministic for this kind of requirement, especially in scenarios where events may occur approximately once per minute? If notification mirroring is used only for user awareness, but the watch app still needs reliable background state/data delivery before the user opens it, is there any Apple-supported architecture for that? Would direct delivery to the watch app be the only realistic direction, or is this level of reliability/latency simply not a supported expectation for general-purpose apps? We understand that background execution and delivery are managed opportunistically by the system. What I want to confirm is whether this requirement itself is outside the practical/supported envelope of APNs background push + WatchConnectivity relay.

I’m experiencing a confusing issue with App Store Server Notifications (Version 2) in the Sandbox environment. I've configured my Sandbox URL, but I'm not receiving any notifications despite successful API responses. App Details: App ID: 6753059790 Bundle ID: com.xmojong.widgetTest Sandbox URL: https://webhook.site/97938287-07e8-4482-a053-b6ccfca76634 The Problem: I am calling the requestTestNotification endpoint via the App Store Server API. The API call is successful and consistently returns a 200 OK status code. However, no notification (Type: TEST) is ever delivered to my Webhook.site endpoint. What I've verified: Endpoint Accessibility: I tested the Webhook URL by sending a manual POST request directly from my iOS app; it was received instantly. Configuration: The URL is correctly entered in the Sandbox Server URL field (not Production) in App Store Connect. Notification Version: It is set to Version 2. Propagation Time: It has been over 3 hours since I updated the URL and saved the changes in App Store Connect. JWT Token: The JWT for the API call is valid (verified by the 200 response from Apple). My Question: If the requestTestNotification API returns a 200, doesn't that mean the App Store server has successfully queued the notification for my specific URL? Is there a known delay for Sandbox notification delivery or URL propagation recently? Or are there any hidden requirements for the Sandbox environment that I might have missed? Any help or insights would be greatly appreciated! Thanks in advance!

Are there some requirements to use Notification Content Extensions other than including the target to my iOS app? I have done it, configured it to match a certain category of notifications, but my custom interface doesn’t show up. is there anything I need to configure on my main app? Is that anything that should be changed there, such as disabking its botifications handling? is there any requirement concerning the payload? I tried to disable time sensitive and content-available notifications, but it didn’t help.

I am working on a large-scale e-commerce application and we are trying to solve a specific issue regarding push notifications and user experience. We have a use case where we need to send a standard push notification to the user, but under certain local conditions on the device, we want to intercept that notification via a Notification Service Extension and suppress/drop it so it does not alert the user. We understand that the com.apple.developer.usernotifications.filtering entitlement allows a Notification Service Extension to drop notifications. However, looking at the entitlement request form, the categories seem strictly limited to: End-to-end encrypted messaging Earthquake warnings Education/learning platforms Enterprise healthcare apps My questions for the community and Apple staff: Is it possible for an e-commerce or retail app to be approved for this entitlement if we have a highly specific, valid use case that improves user experience. If this entitlement is strictly off-limits for our domain, what is the Apple-recommended architecture to achieve this? Thank you in advance for any insights or guidance!

token：eb3b63ab94b136f6d25a86d48bb4b7ff20377e393f137cb4f43b17560112bf51 msgId：67d4c88d-61b1-4f51-df0b-2efa022fd672 机型：iPhone7 系统：iOS 15.8.3 问题描述：后端服务器调用苹果提供的pushKit推送API且已成功返回上述msgId，客户端App也已经实现对应的CallKit方法reportNewIncomingCall，但没有收到对应的推送，这是什么原因呢？

Since upgrading to Xcode 26 beta 4 and using the iOS 26 simulator for testing our app, we've stopped being able to receive device tokens for the simulator from the development APNS environment. The APNS environment is able to return meta device information (e.g. model, type, manufacturer) but there are no device tokens present. When running the same app using the iOS 18.5 simulator, we are able to register the device with the same APNS environment and receive a valid device token.

In my Notification Service Extension I'm doing two things in parallel inside didReceive(_:withContentHandler:): Downloading and attaching a rich media image (the standard content modification work) Firing a separate analytics POST request (fire-and-forget I don't wait for its response) Once the image is ready, I call contentHandler(modifiedContent). The notification renders correctly. What I've observed (via Proxyman) is that the analytics POST request completes successfully after contentHandler has already been called. My question: Why does this network request complete? Is it because: (a) The extension process is guaranteed to stay alive for the full 30-second budget, even after contentHandler is called so my URLSession task continues executing during the remaining time? (b) The extension process loses CPU time after contentHandler but remains in memory for process reuse and the request completes at the socket/OS level without my completion handler ever firing? (c) Something else entirely? I'd like to understand the documented behaviour so I can decide whether it's safe to rely on fire-and-forget network requests completing after contentHandler, or whether I need to ensure the request finishes before calling contentHandler.

Issue: Push notifications are not being received for some users. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving success responses from APNS. Users have confirmed that notifications are enabled on their devices, and they report no network issues.

Hello, I am currently developing an MDM solution, including both the sever-side(.NET) and the client app. I have recently been granted the "MDM CSR" signing permission in the Certificates, Identifier & Profiles of my developer account. I am following the official Apple documentation, "Setting up Push Notifications for your MDM Customers," to generate the required MDM Push Certificate. However, I keep encountering the "Invalid Certificate Signing Request" error when uploading the encoded .plist file to the Apple Push Certificates Portal(identity.apple.com/pushcert). The steps I have taken so far: Generated .csr file via Keychain Access Used the MDM SCR certificate to sign the request. Created a .plist file for th final upload containing : Customer CSR: Base64 encoded Signature : Signed using the SHA256withRSA algorithm and Base64 encoded. Certificate Chain : Including my MDM Vendor Signing Certificate, the Apple WWDR intermediate certificate, and the Apple Root CA. Issues/Questions: Is there a specific requirement for the order of the certificates in the chain? Are there common pitfalls regarding the .plist structure or the encoding of the signature that might cause the "Invalid CSR" error? Is there a tool or a specific validation step I can use to verify the integrity of the generated .plist before uploading? I have double-checked the encoding and the signing process, but the portal continues to reject the request. Any insights or guidance from community would be greatly appreciated. Thank you in advance for your help!

The following issue has occurred: Push notifications are not being received on certain devices. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving normal responses from APNs. Users have confirmed that notifications are enabled on their devices, and they report no network issues. This problem is occurring for multiple users.

I am planning to run the AccessoryNotifications framework on xcode26.4 and ios26.4, please refer to the documentation https://aninterestingwebsite.com/documentation/accessorynotifications I couldn't find a complete demo, but I found a demo based on AccessorySetup Kit, ASK Sample https://docs-assets.aninterestingwebsite.com/published/89f5eef578ef/SettingUpAndAuthorizingABluetoothAccessory.zip. So I plan to practice the entire process of AccessoryNotifications based on this demo. Find accessories based on ASK Sample and connect them, OK Call requestForwarding (for:), OK Add AccessoryData Provider extension to receive system notifications But this step failed. I added an extension according to the documentation, but the following method will not be executed func activate(for session: NotificationsForwarding.Session) func add(notification: AccessoryNotification alertingContext: AlertingContext, alertCoordinator: AlertCoordinating) {} I found the following error log in console.app Error 16:38:17.582340+0800 usernotificationsd ### XPC DAEventExtension decode failed: DAExtensionSession: CID 0x89B80004, DAExtensionSessionConfiguration 'AB83C506-9F35-40FB-9A68-919D43B4D098': BundleID 'com.sifli.ASKSample', DAErrorDomain:350001 'DAExtensionEvent init bad type: 42' I have tried many methods to send messages to the testing phone, local Notifications, We can't even trigger the AccessoryData Provider, activate:for,add:notification: 1.Do I have to add the following two extensions according to the document in order to debug successfully? AccessoryTransportSecurity Manages cryptographic key exchange with your accessory. AccessoryTransportAppExtension Relays encrypted data to your accessory over Bluetooth. 2.What should be selected in the extension template panel of xcode 26.4 when creating these extensions? Geniric Extension Accessory Data Transport I am currently using Geniric Extension