Hi Apple Support team, I would like to inform you that we were receiving push notifications to all regions. Recently we were facing push notifications are not receiving to brazil region. For all other regions we are receiving. We are using same APSN certificate. Any region specific permissions do we need to add. Please let me know. Thanks.

I just switched back to Apple Watch from Garmin, and in the time away I got both work and personal vehicles with CarPlay. I've noticed that my AW10 does not get ANY notifications pushed to it while I am using CarPlay, which is annoying because only texts and calls get pushed to my CarPlay screen, so i miss everything else. Additionally, and this may be a bug issue with iOS18, but I also just noticed that my phone (16) does not light up/make sounds for notifications while using CarPlay - so it doesn't light up, nor do the vehicle speakers make sound with IG/snapchat/etc notifications, and even the screen "lock" sound doesn't audibly go off. I've only had CarPlay for a few months, but I typically keep my phone on Silent anyway, so maybe I'm just noticing this now and its not necessarily a new issue? it does make the sound when i get a text, so logically everything else should make a noise. I've made sure that my general focus and car focus modes are OFF. Sound is ON. Sound volume setting is all the way up. Have also restarted both phone and watch, and “forgot“ the phone from the vehicle and reconnected Am I doing something wrong here? is there a solution for either problem? From what I've seen, some people say that the AW not getting notifications at the same time as Carplay is a built-in safety feature, which most people do not want... maybe its the same with the phone not alerting to non-text/call notifications?

We have an authenticator app (like Google Authenticator & Microsoft Authenticator) with a push notification feature. From past 2 weeks we are not receiving push notifications in the app. Any changes made recently in Apple Firebase which would impact the push notification functionality.

Been one week and still on requested image playground image playground will not work says I’m still requested access

Hello, I have a question regarding the replacement of the APNs authentication key (.p8) in a Firebase setup for push notifications. Currently, my app uses an APNs authentication key from the original Apple Developer account. However, we are in the process of transferring app ownership to a new Apple Developer account, which will require generating a new APNs authentication key and updating it in Firebase. My concerns are: Impact on Existing Device Tokens: If we replace the existing .p8 key with a new one generated from the new developer account, will the existing APNs device tokens remain valid, or will they need to be reissued? Push Notification Delivery: Will Firebase still be able to send push notifications to devices that were registered with the previous APNs authentication key after the key is replaced? Steps for a Smooth Transition: Are there any best practices or additional steps we need to follow to ensure uninterrupted delivery of push notifications during and after the key replacement? Any insights or guidance from the Apple Developer team or community would be greatly appreciated.

Hi all, I have a React web app that we use as a Progressive Web App (PWA). We currently: Use PWA Builder to package it for Android and iOS Host the app on a secure HTTPS URL Use Firebase Cloud Messaging (FCM) for push notifications (working on Android) However, on iOS, we are unable to get push notifications to work. I understand that PWAs on iOS have limited push support (Safari only, and not through WebView). So I explored using Capacitor, but: Capacitor can load a server.url pointing to our hosted app (great for reuse), but push notifications don’t work If we build the web app locally (npm run build) and embed it in the native iOS shell via Capacitor, push works We would prefer not to fully merge our authentication and main app UIs if avoidable Questions: Is there any approved way to enable push notifications in an iOS .ipa built from a hosted web app (URL) using PWA Builder? If not, is embedding the web assets locally the only Apple-approved way to get push support? Are there any best practices or native plugin recommendations (e.g., APNs or FCM) for handling push notifications in iOS app? Thanks in advance for any guidance. 🙏 Let me know if more technical details would help.

Problem Statement We are experiencing a critical and persistent issue preventing the successful signing and building of our iOS application. The core problem is that provisioning profiles, whether automatically generated by Xcode or manually created in the Apple Developer Portal, consistently fail to include the UIBackgroundModes entitlement, leading to a build failure. Specific Question Why are provisioning profiles generated via the Apple Developer Portal and/or Xcode's automatic signing process consistently omitting the UIBackgroundModes entitlement for our App ID, even when this capability is explicitly configured in Xcode? We seek guidance or backend intervention to ensure our provisioning profiles include the necessary entitlement. Expected Outcome We expect to be able to successfully build and sign our iOS application, with provisioning profiles that correctly include the UIBackgroundModes entitlement, allowing for proper implementation of remote notifications. Observed Symptoms Primary Build Error: Consistent build failure with the exact error message: "Automatic signing failed: Provisioning profile 'iOS Team Provisioning Profile: com.scott.ultimatefix' doesn't include the UIBackgroundModes entitlement." Missing Entitlement in Profile (Confirmed by Inspection): Direct inspection of downloaded .mobileprovision files (including those manually generated in the Developer Portal for com.scott.ultimatefix) consistently shows the absence of the UIBackgroundModes entry within the section of the Entitlements dictionary. The aps-environment key for Push Notifications is present, indicating Push Notifications are enabled, but Background Modes are not. Certificates Correctly Recognized in Xcode: Our "Apple Development: Stephen Criscell Scott" and "Apple Distribution: Stephen Criscell Scott" certificates are correctly displayed and recognized in both Keychain Access and Xcode's Preferences > Accounts > Manage Certificates window (without "Not in Keychain" status). Furthermore, the Signing & Capabilities tab for the target in Xcode now correctly shows Signing Certificate: Apple Development: Stephen Criscell Scott. Persistent Issue Across Resets: The problem persists despite extensive local cache invalidation, Xcode reinstallation, and even testing in a fresh macOS user account (which confirmed the issue was not user-specific).

I'm trying to provide custom localized descriptions for the iOS notification permission popup in my app, which supports multiple locales. To achieve this, I'm using InfoPlist.strings files per locale with the following keys: NSUserNotificationsUsageDescription NSUserTrackingUsageDescription The issue I'm facing is that NSUserTrackingUsageDescription is working correctly across all tested locales, but NSUserNotificationsUsageDescription only works for some locales. Locales tested: Working: ja, tr, fr-CA Not working: fr-BE, nl-BE In each case, the correct localized NSUserTrackingUsageDescription appears, but the NSUserNotificationsUsageDescription falls back to the default or does not appear as expected in fr-BE and nl-BE. I'm using Xcode 16 and testing on both iOS 18 simulator and physical devices, and the issue is consistent across both. Any insights on whether this is a known issue in iOS or if there are additional steps needed for NSUserNotificationsUsageDescription to localize properly would be greatly appreciated.

Subject: Seeking Native iOS Solution for Push Notification Acknowledgement and User Interaction Tracking I’m exploring whether there is a native solution in iOS to track the confirmation/acknowledgement of a received push notification on the device, as well as any user interaction with it (e.g., tapping or dismissing the notification). Although I’ve come across multiple discussions on this topic suggesting that it’s not possible, I’d like to know if there have been any recent updates or enhancements in iOS that provide this capability. Has anyone found a reliable approach or workaround for this? Any insights would be appreciated! Thanks!

According to the Apple notification alert received in October 2024, the APNS server certificate update for production is scheduled for February 24, 2025. Has this change been implemented, or is there a platform or method to verify whether this update has been applied in production? If so, where can we check this?"

When I request channel list for bundle id "com.apnspush.LiveActivityPushDemo", the request returns "TopicMismatch". Then when I request channel list for bundle id "com.apnspush.liveactivitypush", the request return is normal. I have tried all my bundle ids that include capital letters, they all failed with "TopicMismatch". Does anyone know the reason? curl -v -X GET \ -H "authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IkdZSDM5WEZMREEifQ.eyJpYXQiOjE3Mjg3MDM4MDksImlzcyI6IjNXSkdFRjI4R1kifQ.wruX6J4qaovq2X-ZlO7g0YyMWjt50g8YoMoZ4G9ZsLDI5wC8u7PFTaG05BmDvbEzLpzrK9ifwPeo5BJ2eZ3hTg" \ -H "apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127" \ --http2 \ https://api-manage-broadcast.sandbox.push.apple.com:2195/1/apps/com.apnspush.LiveActivityPushDemo/all-channels Note: Unnecessary use of -X or --request, GET is already inferred. * Host api-manage-broadcast.sandbox.push.apple.com:2195 was resolved. * IPv6: (none) * IPv4: 17.138.176.4 * Trying 17.138.176.4:2195... * Connected to api-manage-broadcast.sandbox.push.apple.com (17.138.176.4) port 2195 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Request CERT (13): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Certificate (11): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF * ALPN: server accepted h2 * Server certificate: * subject: C=US; ST=California; O=Apple Inc.; CN=api-manage-broadcast.sandbox.push.apple.com * start date: May 30 17:31:41 2024 GMT * expire date: Apr 10 00:00:00 2025 GMT * subjectAltName: host "api-manage-broadcast.sandbox.push.apple.com" matched cert's "api-manage-broadcast.sandbox.push.apple.com" * issuer: CN=Apple Public Server RSA CA 12 - G1; O=Apple Inc.; ST=California; C=US * SSL certificate verify ok. * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://api-manage-broadcast.sandbox.push.apple.com:2195/1/apps/com.apnspush.LiveActivityPushDemo/all-channels * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: api-manage-broadcast.sandbox.push.apple.com:2195] * [HTTP/2] [1] [:path: /1/apps/com.apnspush.LiveActivityPushDemo/all-channels] * [HTTP/2] [1] [user-agent: curl/8.7.1] * [HTTP/2] [1] [accept: */*] * [HTTP/2] [1] [authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IkdZSDM5WEZMREEifQ.eyJpYXQiOjE3Mjg3MDM4MDksImlzcyI6IjNXSkdFRjI4R1kifQ.wruX6J4qaovq2X-ZlO7g0YyMWjt50g8YoMoZ4G9ZsLDI5wC8u7PFTaG05BmDvbEzLpzrK9ifwPeo5BJ2eZ3hTg] * [HTTP/2] [1] [apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127] > GET /1/apps/com.apnspush.LiveActivityPushDemo/all-channels HTTP/2 > Host: api-manage-broadcast.sandbox.push.apple.com:2195 > User-Agent: curl/8.7.1 > Accept: */* > authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IkdZSDM5WEZMREEifQ.eyJpYXQiOjE3Mjg3MDM4MDksImlzcyI6IjNXSkdFRjI4R1kifQ.wruX6J4qaovq2X-ZlO7g0YyMWjt50g8YoMoZ4G9ZsLDI5wC8u7PFTaG05BmDvbEzLpzrK9ifwPeo5BJ2eZ3hTg > apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127 > * Request completely sent off < HTTP/2 403 < apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127 < * Connection #0 to host api-manage-broadcast.sandbox.push.apple.com left intact {"reason":"TopicMismatch"}% curl -v -X GET \ -H "authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IkdZSDM5WEZMREEifQ.eyJpYXQiOjE3Mjg3MDM4MDksImlzcyI6IjNXSkdFRjI4R1kifQ.wruX6J4qaovq2X-ZlO7g0YyMWjt50g8YoMoZ4G9ZsLDI5wC8u7PFTaG05BmDvbEzLpzrK9ifwPeo5BJ2eZ3hTg" \ -H "apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127" \ --http2 \ https://api-manage-broadcast.sandbox.push.apple.com:2195/1/apps/com.apnspush.liveactivitypush/all-channels Note: Unnecessary use of -X or --request, GET is already inferred. * Host api-manage-broadcast.sandbox.push.apple.com:2195 was resolved. * IPv6: (none) * IPv4: 17.138.176.4 * Trying 17.138.176.4:2195... * Connected to api-manage-broadcast.sandbox.push.apple.com (17.138.176.4) port 2195 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Request CERT (13): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Certificate (11): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF * ALPN: server accepted h2 * Server certificate: * subject: C=US; ST=California; O=Apple Inc.; CN=api-manage-broadcast.sandbox.push.apple.com * start date: May 30 17:31:41 2024 GMT * expire date: Apr 10 00:00:00 2025 GMT * subjectAltName: host "api-manage-broadcast.sandbox.push.apple.com" matched cert's "api-manage-broadcast.sandbox.push.apple.com" * issuer: CN=Apple Public Server RSA CA 12 - G1; O=Apple Inc.; ST=California; C=US * SSL certificate verify ok. * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://api-manage-broadcast.sandbox.push.apple.com:2195/1/apps/com.apnspush.liveactivitypush/all-channels * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: api-manage-broadcast.sandbox.push.apple.com:2195] * [HTTP/2] [1] [:path: /1/apps/com.apnspush.liveactivitypush/all-channels] * [HTTP/2] [1] [user-agent: curl/8.7.1] * [HTTP/2] [1] [accept: */*] * [HTTP/2] [1] [authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IkdZSDM5WEZMREEifQ.eyJpYXQiOjE3Mjg3MDM4MDksImlzcyI6IjNXSkdFRjI4R1kifQ.wruX6J4qaovq2X-ZlO7g0YyMWjt50g8YoMoZ4G9ZsLDI5wC8u7PFTaG05BmDvbEzLpzrK9ifwPeo5BJ2eZ3hTg] * [HTTP/2] [1] [apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127] > GET /1/apps/com.apnspush.liveactivitypush/all-channels HTTP/2 > Host: api-manage-broadcast.sandbox.push.apple.com:2195 > User-Agent: curl/8.7.1 > Accept: */* > authorization: bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IkdZSDM5WEZMREEifQ.eyJpYXQiOjE3Mjg3MDM4MDksImlzcyI6IjNXSkdFRjI4R1kifQ.wruX6J4qaovq2X-ZlO7g0YyMWjt50g8YoMoZ4G9ZsLDI5wC8u7PFTaG05BmDvbEzLpzrK9ifwPeo5BJ2eZ3hTg > apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127 > * Request completely sent off < HTTP/2 200 < apns-request-id: 2288cf3f-70d8-46a6-97d7-dd5d00867127 < * Connection #0 to host api-manage-broadcast.sandbox.push.apple.com left intact {"channels":["vtVPwIhLEe8AAG79CdMNuQ=="]}%

Hi) we have two ios apps in same Firebase project - with different apple bundle ids. One of them had connected APNS with Firebase and everything had worked perfectly - push notifications where delivered every time. But recently we occationaly put same APNS to other our Firebase's ios app and as result we lost all pushes - on both app. After deletion APNS from both of them and reconnecting APNS to app with proper apple bundle id push notifications didn't start to work. could you please suggest what we are suppose to do to resolve issue?

We submitted firewall request to below destination subnets and we still see connection refused to port 5223. Please advise why are we seeing connection refused and should we need 5223 port. Subnets - 17.249.0.0/16, 17.252.0.0/16, 17.57.144.0/22, 17.188.128.0/18, 17.188.20.0/23

I’m using Appnotic from my server to send notifications for an emergency service, where it is critical that notifications are delivered immediately. My payload looks like this: "aps": { "alert": "Test alert", "sound": { "critical": 1, "name": "sound.wav", "volume": 0.5 }, "content-available": 1, "category": "alert" }, "topic": "com.fireservicerota.FSR-Primary-Alerting", "custom_payload": { "id": "11", "type": "alert", "incident_id": 23434, "incident_response_id": 2652343, "expiration_time": "2024-06-06T16:59:05+01:00" } } I already have the critical alert entitlement and background processing enabled. Everything seems fine when debugging, but I’m experiencing issues: • Some notifications never arrive • Around 60% of notifications arrive with noticeable delay Since this is an emergency app, delivery speed is crucial. What could be causing this inconsistency?

I would like to do exactly this but the API doens't seem to allow it. Was wondering if there were any creative workarounds? Basically, I have a reminder app that needs to send reminders at a certain time each day (there are several of these reminders per day). Each reminder has a couple of follow-ups scheduled at 5 min intervals. If a user takes action on the task before the reminder is sent however, I would like to unschedule that notification (and follow ups) until the next day. The unscheduling part is easy, but there seems to be no reliable way to re-schedule it for the next day and continue repeating. Looked into background tasks and they don't seem intended for these purposes nor do they seem reliable. The user isn't guaranteed to take action on notifications nor open the app within a 24-hour period after they have taken action on their task.

Hello Apple Developer Team, I am facing an issue with remote notifications in my iOS app. When the app is in a terminated (kill) state, notifications are successfully received by the device, but none of the app's handlers (like _firebaseMessagingBackgroundHandler in Flutter) are invoked. This is impacting our ability to process silent notifications or perform background tasks reliably when the app is not running. Steps to reproduce: Send a remote notification with content-available: 1 in the payload. Confirm the notification is received by the device while the app is in kill mode. Observe that no background or foreground notification methods are triggered in the app. Expected Behavior: The app should invoke the background handler to process the notification payload, even in a terminated state. Observed Behavior: The notification is delivered to the device, but no app-level processing occurs because none of the methods are triggered. Can you please confirm if this is the intended behavior due to iOS limitations, or if there is a configuration or alternative solution to allow background handlers to execute in such scenarios? Any guidance or clarification would be highly appreciated. Thank you!

Currently working on a dating app which needs voip for audio and video calls for ios. the voip notifications only comes to the app in active and inactive mode but doesnt wake the device in background or terminated mode. After debugging i noticed that com.apple.developer.voip entitlement wasnt included which i later added, trying to create a build i get the eas error that the entitlement wasnt added to the identifier capabilities. My issue now is that i can't seem to find the voip capability to check in the identifiers capabilities list for the bundle id.d

Hello, I'm trying to use critical alerts on the CarPlay, but I'm facing couple of issues: Sound of critical alerts is not played by the CarPlay's speakers (played by the iPhone's speakers) Tapping on a critical alert doesn't open the app like other notifications. Critical alerts of the app are always shown if the CarPlay is connected, even if the app doesn't have the CarPlay entitlement. didReceive is not called if the user taps on a notification on the CarPlay. Any help would be greatly appreciated

I'm encountering an unexpected issue in my app since upgrading to iOS 18, and I’m wondering if anyone has found a solution or workaround. The Problem: The userNotificationCenter(:willPresent:withCompletionHandler:) method is being triggered twice whenever a push notification arrives while the app is in the foreground. Additionally, application(:didReceiveRemoteNotification:fetchCompletionHandler:) is also being triggered once during the same notification event. This redundant triggering is causing inconsistent behavior and double-processing of notifications, which is obviously problematic for my use case. The exact flow looks like this: userNotificationCenter(:willPresent:withCompletionHandler:) — called twice. application(:didReceiveRemoteNotification:fetchCompletionHandler:) — called once. Has anyone else experienced this behavior specifically in iOS 18? Is this a known issue with the new version? This issue is affecting how we handle notifications in a major way, and I’m hoping there's a more fundamental fix or explanation for this behavior in iOS 18.

I'm observing that when a silent push notification is sent to our app, is is started up in the background for 30 seconds before being suspended until the app is launched by the user. This causes data to persist from the silent push notification to the user app launch. I couldn't find documentation on this behavior for silent push notifications, and was wondering if it's possible to have the app terminate after handling the silent push notification. Is there documentation on the general flow of silent push notifications as well? I'm able to handle the edge cases if the app has to be suspended until user launch, but just want to confirm that this is the expected behavior before I go about handling it this way.