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).

I've added a Notification Service Extension as a target to my React Native iOS app following Apple's official documentation. After completing all the setup steps as outlined in the documentation, the notification titles remain unchanged - notifications are arriving without any modifications, suggesting the extension isn't functioning properly.Testing Details: Sending notifications via Apple Push Notification Console Tested on iPhone 16 Pro Max (physical device) Tested on iPhone 15 Pro simulator Both show the same issue - no title modifications The extension appears to not be executing at all. Has anyone encountered similar issues with Notification Service Extensions in React Native projects, or can suggest troubleshooting steps to verify the extension is properly configured and running?

Hello all 👋 We're developing an app for families with neurodivergent members (primarily autistic children) and have run into a critical reliability issue with silent push notifications that breaks core functionality. Our current implementation: When a caretaker updates the person's daily routine/schedule in our system, we send a silent push notification to the user's device. The app wakes, connects to our server, downloads the updated schedule, and creates/updates local notifications for upcoming activities. The problem: Because the app is rarely/never directly interacted with by the end user (the child doesn't open the app - caregivers configure it on their behalf), silent push notifications get progressively throttled and eventually stop being delivered entirely. This means schedule changes made by caregivers never reach the device, breaking the app's core value proposition. Uninstalling and reinstalling doesn't reset the throttling state Questions: Is there any way to reset or mitigate throttling for devices that legitimately need background updates but have low or no user interaction? This is an accessibility use case where the end user (child) doesn't interact with the app, but the app must reliably receive updates. Would switching to regular (visible) push notifications avoid this throttling even if the app is not interacted with? We already have Critical Alerts entitlement, but for regular updates we're worried that the "CRITICAL ALERT" banner will be too upsetting for the child. Is there any exception process for accessibility apps to change the way Critical Alerts are presented? For neurodivergent individuals, predictable routines are essential. When schedule updates don't reach their device, it can cause significant distress. This is a genuine accessibility need, not a "nice-to-have" feature. Any guidance from Apple engineers or developers who've solved similar challenges would be greatly appreciated. Thank you!

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.

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.

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

My Mac app has a launch agent (within the app bundle) that works great without the app running. There are some occasions where I need to display an alert and ask the user to launch the app to handle the issue. I thought about using UNUserNotificationCenter but I'm not able to make it work from the agent. I'm asking for authorization as follows: [center requestAuthorizationWithOptions:(UNAuthorizationOptionAlert | UNAuthorizationOptionSound | UNAuthorizationOptionBadge) completionHandler:^(BOOL granted, NSError * _Nullable error) { NSLog(@"authorization request completion. Granted: %@, error: %@ (%@)",granted?@"YES":@"NO",error, [error localizedDescription]); }]; And I'm trying to post the notification as follows: content.title = @"Your App Name"; content.body = @"Click the button to open the app"; content.sound = [UNNotificationSound defaultSound]; UNNotificationRequest *request = [UNNotificationRequest requestWithIdentifier:[[NSUUID UUID] UUIDString] content:content trigger:nil]; [center addNotificationRequest:request withCompletionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"Error showing notification: %@ %@", error, [error localizedDescription]); } }]; When running I'm getting asked to authorize, I authorize and all seems OK in system settings but I'm not able send any notifications. addNotificationRequest results in UNErrorCodeNotificationsNotAllowed error. I tried this with the authorization request inside the main app, or inside the agent, with the same results. When trying to post the notification from within the app, it does work, but that's not what I need. Is posting notifications from within the launch agent not possible at all, or is there anything here that I'm missing. TIA

Hi, am facing an issue related to voip push notifications getting delivered 1-2 hours after apns-expiration to 0 and apns-priority to 10. I had raised a similar post got a reply that it may be due to network delay. But network delay can cause the delivery of voip push to be delayed only by few seconds or minutes. But in our case voip push is getting delivered hours after the voip call was attempted. Steps to reproduce: Put our voip app in background and lock iPhone. As app is put in background, socket connections gets disconnected from server. Now if a caller makes call to this app, the call should be delivered through voip push. 2) Voip push should ideally be received even if app is in background and iPhone is locked. It is connected to a good wifi network. But it does not receive the voip push. 3) After 1-2 hours user unlocks iPhone and opens voip app. As soon as user opens app, the voip push is received and phone starts ringing.

Hey Together, I have seen that critical notifications need to be confirmed by apple to be used. Sadly I couldn't figure out where to ask for that. Context: I have a sports tournament app for Beach Handball. There are a couple of Courts like up to 20-25. The main use for that in my app would be to notify first aiders/Medics. Right now they are called in via Speakers or by the referees just writing that into a WhatsApp chat. As this takes a long time and the speakers can be deactivated due to rain, power shortage or even the medics sometimes are not in range to exactly hear the speakers calling them. To Speed up this process I want them to download the App, Register via an E-Mail or a One Time Code. Now if a referee needs immediate Help from the Medics on their court they can send the Critical alert to the Medics without having to write a chat into a WhatsApp group, to get a call through the speakers 10 minutes later which the medics may not even hear. A couple of weeks ago we had a player falling on her back/neck/head and they couldn't figure out if she broke her neck or not. Luckily the medics were right next to the court and saw that. but what would happen if they were a couple hundred of meters away and did not notice that? I mean the PA system was off due to a power shortage. someone trying to move her? Risking her death? And while we are at it we could add those notifications if a team is missing to a court for a game that already should've started. Critical because it is urgent. Those notifications are handled with care.

Back story: I'm developing an app that communicates with a personal medical device. We use critical alerts when we have hardware issues that could result in harm to the patient. The audio file is a 30 second file to make sure the patient is aware. If the app is open when they occur, we pop up a modal message in the app. When the user dismisses the notice, we call UNNotificationCenter::removeDeliveredNotifications(withIdentifiers:) to remove the critical alert and also to stop the audio file that is playing. This normally works fine. However we discovered that if the patient leaves critical alert enabled but disables notifications for our app, that we can still post the critical alert and it goes off. However when the user dismisses the message, the removeDeliveredNotifications call does not work. I did some debugging and if call getDeliveredNotifications with this permission combination, it return 0 (normally it would return 1). Does anyone know of another way to remove the critical alert in this situation? (or should I be submitting this as a bug?)

We're experiencing an issue with Apple Push Notification service where APNs continues to return 200 OK responses for device tokens belonging to uninstalled applications. Issue Details: When sending push notifications to device tokens. APNs returns 200 OK responses even for devices where our app was uninstalled more than a month ago According to documentation(https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns), APNs should return 410 status code with JSON body for invalid tokens Expected Behavior: APNs should return 410 status code when device token is no longer valid (app uninstalled) Thanks in advanced for support

Hey everyone! I'm trying to develop an app that would need to send periodic notifications (every 20 minutes, for instance) to the user even when the app is not running (but only when the phone is being used). I've been reading through the prior comments and all about not being able to have a timer run in the background in the way I need it to, but I wanted to ask if there's any way around this, or is there truly no way? If there is no way to do this, I was just now considering another workaround, where I could try getting the time they open their phone, and from there, I schedule local notification for every 20 minutes or so for the entire day, and they keep sending until the phone is turned off, when the rest of the scheduled local notifications are cancelled. Is this possible? I would also appreciate any other suggests/workarounds for this. Happy to provide any additional details needed! Thanks!

We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures. The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows: VoIP App (callee): Launches iPhone (callee): Locks (e.g., by short-pressing the power button) VoIP App (callee): Transitions to a suspended state VoIP App (caller): Initiates a VoIP call VoIP App (callee): Receives a local push notification VoIP App (callee): Creates a UDP socket for call control (for SIP send/receive) VoIP App (callee): Creates a UDP socket for audio stream (for RTP send/receive) VoIP App (callee): Exchanges SIP messages (INVITE, 100 Trying, 180 Ringing, etc.) using the call control UDP socket VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() Immediately after executing performAnswerCallAction() in the above sequence, the sendto() function for both the "UDP socket for call control (SIP send/receive)" and the "UDP socket for audio stream (RTP send/receive)" occasionally returns errno = 57 (ENOTCONN). (of course The VoIP app itself does not close the sockets in this timing) Given that the user has performed an answer operation, the iPhone is in an active state, and the VoIP app is running, what could be the possible reasons why the sockets suddenly become unusable? Could you please provide guidance on how to avoid such socket closures? Our VoIP app uses SCNetworkReachabilitySetCallback to receive network change notifications, but no notifications regarding network changes were received at the time errno = 57 occurred. Is it possible for sockets used by an application to be closed without any notification to the application itself?

In didFinishLaunchingWithOptions I have this setup for getting the token to send to my server for notifications. The issue is that the delegate callback didRegisterForRemoteNotificationsWithDeviceToken gets called twice when also initializing a CKSyncEngine object. This confuses me. Is this expected behavior? Why is the delegate callback only called twice when both are called, but not at all when only using CKSyncEngine. See code and comments below. /// Calling just this triggers `didRegisterForRemoteNotificationsWithDeviceToken` once. UIApplication.shared.registerForRemoteNotifications() /// When triggering the above function plus initializing a CKSyncEngine, `didRegisterForRemoteNotificationsWithDeviceToken` gets called twice. /// This somewhat make sense, because CloudKit likely also registers for remote notifications itself, but why is the delegate not triggered when *only* initializing CKSyncEngine and removing the `registerForRemoteNotifications` call above? let syncManager = SyncManager() /// Further more, if calling `registerForRemoteNotifications` with a delay instead of directly, the delegate is only called once, as expected. For some reason, the delegate is only triggered when two entities call `registerForRemoteNotifications` at the same time? DispatchQueue.main.asyncAfter(deadline: .now() + 4) { UIApplication.shared.registerForRemoteNotifications() } func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { print("didRegisterForRemoteNotificationsWithDeviceToken") }

When User restarted iOS device, after powering on iOS App is not able to get VoIP push notification. If user opens App, immediate VoIP push receiving. In Normal (App Kill or Background state) everything works as expected. Issue is when device is powered on and immediately( In 1-2 mins) try to call on device. We are using delegate to show Call to User public func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void)

Hi Apple engineering team, I contacted Developer Support regarding the status of our entitlements request, and they recommended that I post here for visibility. It’s been just over two weeks since we submitted the request, and we haven’t received any updates yet. We understand these requests can take time, but it’s unclear what the typical timeline looks like or if there’s any way to check on the progress. Is there a way to get an update or better understand where we are in the process? We’re trying to plan our release and would really appreciate any guidance on what to expect. Thanks in advance for your help.

Provisioning profiles created for my App ID are not including the Push Notifications capability, even though Push Notifications is enabled in the App ID configuration in Apple Developer Portal. I have enabled Push Notifications for my App ID (com.abc.app) in the Apple Developer Portal. The capability shows as enabled and saved. However, when provisioning profiles are generated (either manually or through third-party tools like Expo Application Services), they do not include: The Push Notifications capability The aps-environment entitlement This results in build failures with the following errors: Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't support the Push Notifications capability. Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't include the aps-environment entitlement. Steps Taken ✅ Enabled Push Notifications in App ID configuration (com.mirova.app) ✅ Saved the App ID configuration multiple times ✅ Waited for Apple's systems to sync (waited 5-10 minutes) ✅ Removed and re-added Push Notifications capability (unchecked, saved, re-checked, saved) ✅ Created Push Notification key in Apple Developer Portal ✅ Verified Push Notifications is checked and saved in App ID ❌ Provisioning profiles still created without Push Notifications capability Expected Behavior When Push Notifications is enabled for an App ID, any provisioning profiles created for that App ID should automatically include: Push Notifications capability aps-environment entitlement (set to production or development) Actual Behavior Provisioning profiles are created without Push Notifications capability, even though: Push Notifications is enabled in App ID App ID configuration is saved Sufficient time has passed for sync Additional Information Push Notification Key: Created and valid (Key ID: 3YKQ7XLG9L and 747G8W2J68) Distribution Certificate: Valid and active Provisioning Profile Type: App Store distribution Third-party Tool: Using Expo Application Services (EAS) for builds, but issue persists with manually created profiles as well Questions Is there a delay or sync issue between enabling Push Notifications in App ID and it being available for provisioning profiles? Are there any additional steps required to ensure Push Notifications is included in provisioning profiles? Is there a known issue with Push Notifications capability not being included in provisioning profiles? Should I create the provisioning profile in a specific way to ensure Push Notifications is included? Environment Platform: iOS Build Type: App Store distribution Xcode Version: (via EAS cloud build) Thank you for your assistance. I've been unable to resolve this issue and would appreciate any guidance. iOS Deployment Target: Latest

Hello everyone, Our team is currently developing a PTT (Push-to-Talk) application using the officially recommended PushToTalk framework. During development, we've encountered a point of confusion regarding the application's behavior after being force-quit by the user. Based on our understanding of the PushToTalk framework documentation (https://developer.apple.com/documentation/pushtotalk/creating-a-push-to-talk-app/) and the PTChannelManager session restoration mechanism, when a user manually kills the app from the background (App Switcher), the current PTT session (the system session managed by PTChannelManager) should terminate. Subsequent pushtotalk type pushes sent via APNS, without an active session, appear to be silently discarded by the system and cannot wake the app for processing (similar to what Kevin Elliott DTS mentioned in https://developer.apple.com/forums/thread/760506 Point D). This seems to prevent reliable PTT message reception in our app after a user force quits. However, we've observed that some popular PTT applications on the market (e.g., TenTen) appear to successfully receive and play PTT voice messages from friends even after the user has performed a force-quit action. This behavior seems inconsistent with our test results and understanding based on the standard framework, posing a challenge for us in providing similar reliability using standard methods. This naturally leads us to wonder how this capability is achieved. We've reviewed developer forums and are aware of the historical existence of a PTT-specific com.apple.developer.pushkit.unrestricted-voip entitlement, which allowed PushKit usage for PTT without CallKit binding. While Apple DTS engineers have repeatedly stated this entitlement is being deprecated and urged migration to the PushToTalk framework (e.g., https://developer.apple.com/forums/thread/763289), we are curious if the observed "wake-after-force-quit" capability might be related to some apps potentially still utilizing this outgoing special entitlement. Alternatively, is there perhaps a mechanism within the standard PushToTalk framework that allows wake-up after force quit that we haven't fully grasped? Therefore, we'd like to ask fellow developers for clarification and discussion: When using the standard PushToTalk framework, have others confirmed that the app indeed cannot be woken up by pushtotalk pushes after being force-quit by the user? Is this the expected behavior? Has anyone successfully achieved a TenTen-like experience (reliable PTT reception after force quit) using only the standard PushToTalk framework? If so, could you share key implementation insights or areas to focus on? (e.g., Is it related to specific usage patterns of the restorationDelegate?) How do you view this potential discrepancy between standard framework capabilities and the behavior exhibited by some apps? What considerations does this bring to development planning and user experience design (especially when users might have expectations set by the "always-on" behavior of other apps)? Are there any best practices or specific techniques when using PTChannelManager session management and restoration that maximize PTT message reliability (especially after the app is terminated by the system in the background), while still adhering to the framework's design principles (like user awareness of the session via UI)? [For instance, another developer raised challenges related to PTT framework restrictions here: https://developer.apple.com/forums/thread/773981] We hope this discussion can help clarify our understanding of the framework and gather community best practices for building reliable PTT functionality while adhering to Apple's guidelines. Thanks for any insights or shared experiences!

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

Hi, We have a simple calendar reminder app that uses UNNotificationRequest to schedule local notifications for user events. I’m wondering whether UNNotificationRequest has a system-imposed limit of 64 upcoming scheduled notifications, similar to the deprecated UILocalNotification. We’re asking because one of our users is not receiving recently scheduled reminders. Our current workflow is: We schedule notifications on app launch and when the app is about to quit. Before scheduling, we call removeAllPendingNotificationRequests(). We then fetch the 64 nearest upcoming events and schedule them using UNUserNotificationCenter.current().add(...). This approach works fine during our testing, but we’re unsure what might be causing the issue for some users. Any insights would be appreciated. Thanks!