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.

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.

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://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"