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!

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.

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://developer.apple.com/documentation/accessorynotifications I couldn't find a complete demo, but I found a demo based on AccessorySetup Kit, ASK Sample https://docs-assets.developer.apple.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

Hello, I'm from Microsoft team maintaining push notification api behind Teams platform. We are experiencing strange and short error spikes towards APNS that seem to mostly correlate worldwide. We checked the networking and push request code but could not find what could be causing this. These error spikes are all timeouts or connection resets (by remote host, ie. APNS servers) and seem to come and go randomly: Would it be possible to check this for outages or some other metrics on your side or investigate why would it happen? Since it's worldwide it seems unlikely it's something broken on our side. We are using the standard APNS http2 endpoint with modern support for all RFC features (so everything should work normally). Mind you, our api might be in a unique position because of the volume of notifications (in the billions per day).

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

I am currently encountering an issue: when creating a new push certificate on the Apple Push Notification Certificates portal, I am required to generate a signature beforehand. Could you please explain the specific rules for this signature and how I should go about generating it? (I previously attempted to generate the certificate using the following command—openssl req -new -key mdm_push.key -out mdm_push.csr—but after uploading it, I received an error indicating an incorrect format.) !

I have a messaging app that has been working successfully for several years. It still works for most users, but about one month ago one of my users started experiencing issues receiving notifications. From my investigation, the user's Notification Service Extension (NSE) has not been triggered since they started reporting the issue. I was able to access the user's phone and connected it to the console to check for any logs related to the NSE being triggered or a push notification being received, but there were no relevant logs. I have already verified that notifications are enabled for the app and that Do Not Disturb is not active. I also tried sending a test notification using the CloudKit Console. The notification was successfully delivered to other push notification tokens, but it did not work for this specific device’s token. I have also confirmed that the push token on the server matches the one on the device and that it is being used with the APNs production environment. The issue for this user started in iOS version 26.2 and are still ongoing in version 26.3.1 . Has anyone encountered a similar issue or have suggestions on how to further diagnose this?

Hello everyone, I’m an iOS developer working on a real-time communication app that supports VoIP calls using CallKit. The app has been in production for more than 5 years. Over the years, some users have occasionally reported that they do not receive incoming call pushes. We have tried multiple optimizations on both the client and server side, but the improvement has been limited. From Apple documentation and discussions online, I understand that iOS may restrict VoIP pushes if the system detects violations of VoIP push usage rules (for example, not presenting a CallKit call after receiving a VoIP push). However, the exact rules and thresholds for these violations are not clearly documented, so I’d like to ask a few questions to better understand the expected behavior. Below is a simplified description of our current call flow. Call Flow Caller When the user initiates a call: We do not use CallKit The call is handled entirely using a custom in-app call UI Callee When the user receives a call: Device locked or app in background A VoIP push wakes the app The app presents the CallKit incoming call UI App in foreground The server still sends a VoIP push The app first reports the call to CallKit After a very short delay, the app programmatically ends the CallKit call Then a custom in-app call UI is presented via the app's long connection The reason we always send a VoIP push (even when the app is in the foreground) is that we want to maximize call delivery reliability.

Environment: iOS 26.4 beta Xcode 26.4 beta Framework: AccessoryNotifications, AccessorySetupKit, AccessoryTransportExtension Description: I'm implementing notification forwarding to a custom BLE accessory using the new AccessoryNotifications framework in iOS 26.4. I've set up an AccessoryDataProvider extension following the documentation, but I'm unclear about how the data is actually transmitted to the BLE accessory. Current Implementation: Main App - Uses AccessorySetupKit to discover and pair accessories: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "FEE0") let displayItem = ASPickerDisplayItem( name: "Notification Accessory", productImage: UIImage(systemName: "applewatch")!, descriptor: descriptor ) accessorySession.showPicker(for: [displayItem]) { error in // Handle error } AccessoryDataProvider Extension - Implements NotificationsForwarding.AccessoryNotificationsHandler: @main struct AccessoryDataProvider: AccessoryTransportExtension.AccessoryDataProvider { @AppExtensionPoint.Bind static var boundExtensionPoint: AppExtensionPoint { Identifier("com.apple.accessory-data-provider") Implementing { AccessoryNotifications.NotificationsForwarding { NotificationHandler() } } } } // NotificationHandler sends messages via: let message = AccessoryMessage { AccessoryMessage.Payload(transport: .bluetooth, data: data) } try await session?.sendMessage(message) Info.plist Configuration: EXExtensionPointIdentifier com.apple.accessory-data-provider NSAccessorySetupBluetoothServices FEE0 Questions: What BLE Service and Characteristic should the accessory advertise? - The documentation mentions specifying transport: .bluetooth, but doesn't explain what Service/Characteristic the accessory needs to implement to receive the notification data. 2. How does AccessoryMessage with transport: .bluetooth actually transmit data? - Is there a specific Apple-defined BLE protocol? - Does the accessory need to run specific firmware or support a particular protocol stack? 3. Is there any documentation about the accessory-side implementation? - The iOS-side documentation is clear, but I couldn't find information about what the BLE peripheral needs to implement. 4. Is MFi certification required for the accessory? - The documentation doesn't explicitly mention MFi, but it's unclear if custom third-party accessories can use this framework. Any guidance on how the BLE communication works under the hood would be greatly appreciated.

We recently developed the provisional permission for our app, but we have noticed that is not working as expected in iOS 16 (We have tested only there). Currently we request the permissions like this: UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound, .provisional]) { [weak self] _, _ in // here we register for pushes in case authorizationStatus is provisional or authorised } What happens is we do get the 1st notification with the keep CTA - once tapped we see that there pops an action: "Deliver Immediately", but even though the user selects that, we still see under setting the pushes are marked as "Deliver Quietly". In addition to this the sound and bage still stay as toggled off - and the lock screen and banner as well stay off. Basically, nothing changes after the user selects "Deliver Immediately"

I'm working on an app that syncs with Apple Health events. Every time an event occurs, the app should send a notification. The problem occurs when the app is backgrounded or force-closed; it can no longer send local notifications, and because these events can occur at any time, scheduled notifications can't be used. I'm just wondering if anyone's found a creative way around this. I know we can't override system behaviour, I'm just thinking of other alternative solutions for the matter.

The APP was not awakened by system after start a liveactivity and the liveactivity has showed on lock screen.so the updatetoken wont send to our inner server and the liveactivity can not update,often like this,but sometimes it can work. it makes me confuse,and i don't know how should i can do,because the liveactivity like a black box,i can not analyse the data link.for example ,inner server send a start liveactivity,but it can not accept a updatetoken unless the user lanuch APP. i hope the liveactivity can start and update on background. And i have developed it as described in the document. Hope to get your help，thank you very much.

Having voice control enabled now puts three menu bar items. The blue icon it has always had, supplemented with an orange microphone and an orange dot next to control center. I know this orange icon is there to notify me that a third-party application is accessing the microphone, but this is a first-party system service that is always running. If another app starts accessing the microphone I won't know, since the orange icon is always there anyway. It's like a California prop 65 warning. Maybe it was a good idea in principal but with it being ubiquitous everyone just ignores it. Siri is also always accessing the microphone, but doesn't trigger this orange eyesore because it's a system service. Both Siri and voice control are always on in the background, are first-party system services that must be specifically enabled, and both have their own menu bar icon that can be removed if not wanted. This orange icon with voice control potentially introduces MORE risk by training me to ignore the orange icon. Please return to the pre-26.3 behaviour of using this orange icon for third-party apps and not first-party system services. FB22036182 -- "Voice control causes extra menu bar icon"

I am developing a VoIP service. Usually, when receiving a VoIP Push, Callkit is exposed immediately after receiving the message and the app is designed to be used. However, there is an extremely intermittent phenomenon (not well reproduced) where the app does not wake up even when receiving a VoIP Push. And after a long time, the app wakes up and Callkit is activated. (A long time after receiving the call…) Has anyone experienced the above phenomenon? I wonder if there are any reported parts depending on the OS version. (I have identified that it does not occur in the 17.x version, but it is difficult to guarantee because it occurs extremely intermittently) The app is not running in the background, but... Could this be happening if there are a lot of pending operations in the background? I need help urgently