Apps distributed via TestFlight have a 90-day expiration period, and we have been sending push notifications to mobile devices daily. Will push notifications still be delivered to mobile devices after the app has expired?

when I implementation the UNUserNotificationCenterDelegate func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) { var status = "" if (UIApplication.shared.applicationState == .active) { status = "active" } else if (UIApplication.shared.applicationState == .background) { status = "background" } else if (UIApplication.shared.applicationState == .inactive) { status = "inactive" } completionHandler() } I find that UIApplication.shared.applicationState == .background this case can not execute when application is in background。 why applicationState is inactive not background?

Hello, I have a couple of questions regarding the change of the Certification Authority (CA) for Apple Push Notification service (APNs) and I will be grateful for any answers. Does it require only making sure the server machine has the SHA-2 Root: USERTrust RSA Certification Authority certificate included in Trust Store (/etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem with SHA256: 8a3dbcb92ab1c6277647fe2ab8536b5c982abbfdb1f1df5728e01b906aba953a) ? Should the Certificate Signing Request be updated (that one that is uploaded to https://identity.apple.com/pushcert/) ? Does it have any connection with the certificates that are created on https://identity.apple.com/pushcert/ ? Is the push type "mdm" affected too? Which certificate should be added and where specifically? Is it for Certificate Signing Request to https://identity.apple.com/pushcert/ or the certificate that is generated on https://developer.apple.com/account/resources/certificates/list or like mentioned in the first question? Can a certificate for sandbox environment be created on https://identity.apple.com/pushcert/ ? Thank you for any help.

Hello everyone in the iOS Devolution community! I'd like to share a suggestion that I believe would bring an unprecedented level of intelligence and comfort to the daily iPhone experience: Smart Adaptive Volume & Brightness. The Problem We Aim to Solve How many times has your iPhone rung too loudly in a quiet environment, embarrassing you in a meeting or waking someone up? Or, the opposite, you missed an important call on a busy street because the volume was too low? And what about screen brightness? It's a constant adjustment: too bright in the dark, hard to see in the sun. Currently, we have to manually adjust volume and brightness, or rely on Auto-Brightness (which only works for the screen) and Focus modes, which can be a bit "all or nothing." This leads to interruptions, frustration, and that feeling that your phone isn't really adapting to you. The Solution: Smart Adaptive Volume & Brightness My proposal is for iOS to use the iPhone's own sensors to dynamically adapt notification and ringtone volume, and screen brightness, to the environment we're in. How it would work in practice: Environmental Scan Before Ringing/Displaying: When a notification (call, message, app alert) is about to be delivered, and even before it makes a sound, the iPhone would briefly activate its sensors. The microphone would read the ambient noise level (in decibels), but without recording audio or analyzing any content. Just the "noise" of the surroundings. The ambient light sensor would assess the light intensity around the device. Intelligent and Coordinated Adjustment: Based on these combined readings of noise and brightness, iOS would make the adjustments: In noisy and bright environments (e.g., on the street during the day): The ringtone volume would be automatically increased to ensure you hear it, and the screen brightness would also be raised to facilitate viewing in strong light. In quiet and dark environments (e.g., cinema, bedroom at night): The volume would be discreetly reduced to avoid disturbances, and the screen brightness would be dimmed for your visual comfort and to avoid bothering others. Adjustments would be gradual, adapting to any type of environment (office, cafe, etc.). User Control: Of course, we'd have the option to enable or disable "Smart Adaptive Volume & Brightness" in the settings. We could also define minimum and maximum limits for these automatic adjustments, ensuring the iPhone adapts to our personal comfort levels. This feature would complement existing Focus modes, operating within the permissions of any active Focus. The Benefits for the User Goodbye to Inconvenient Interruptions: No more startling loud rings in quiet places. Never Miss a Call Again: In noisy environments, your iPhone will adapt to be heard. Constant Visual Comfort: The screen will always be at the ideal brightness, without blinding you in the dark or disappearing in the sun. Smoother Experience: Fewer manual adjustments, more time to focus on what matters. Guaranteed Privacy: The use of microphones and sensors would be strictly for environmental measurement, without recording or analyzing personal data. I believe this feature would bring a new level of intelligence and usability to iOS, making the iPhone even more intuitive and adapted to our daily lives. What do you all think of this idea?

I am an iOS development engineer. Recently, I updated the Xcode version to 16.1 (16B40) and updated my debugging device (iPhone 15) to iOS 18.1.1. However, I found that I could not respond to the delegate method. I confirmed that my code, certificate, Xcode settings, and network environment had not changed. Simply executing application.registerForRemoteNotifications() in func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool did not receive a response(didRegisterForRemoteNotificationsWithDeviceToken or didFailToRegisterForRemoteNotificationsWithError ). In the same environment, when I switched to another device for debugging (iOS 17.0.3), the delegate method would respond. I really don't know what to do, I hope someone can help me, I would be very grateful. Please note: Everything is normal when using devices before iOS 18.1.1 version

When I use https://api.push.apple.com/3/device/e0ae826f3905b010e37c4a07e873481b8446c9dc2788511b2995992884468068 Return error message: {"reason":"BadDeviceToken"} When I use https://api.development.push.apple.com/3/device/e0ae826f3905b010e37c4a07e873481b8446c9dc2788511b2995992884468068 Return error message:{"reason":"TopicDisallowed"} why?

Dear Apple Team, I hope this message finds you well. I wanted to share a playful and innovative idea that could enhance the iPhone experience—particularly when viewing content in full-screen mode through apps like Apple TV or YouTube. Feature Concept: Hands-Free Dismissal of Notifications When the iPhone is in landscape mode, incoming notifications can interrupt the viewing experience. While Focus Mode and swipe gestures help, I thought of a more intuitive and hands-free interaction: using a light puff of air directed toward the screen to dismiss a notification. This interaction could use the microphone or other onboard sensors to detect a brief burst of air, providing a fun and natural way to maintain immersion without touching the device. If this isn’t feasible with current hardware, here are a few alternative concepts that align with the same goal: Blink to Dismiss: Using Face ID sensors to detect a quick blink as a hands-free gesture. Shake to Dismiss: A gentle shake gesture when holding the iPhone in one hand. Gaze-Based Dismissal: Notifications automatically disappear after a brief moment of eye contact. These ideas could offer both accessibility benefits and a touch of delight—making the iPhone feel even more magical and responsive. Thank you for your time and for considering this suggestion! Warm regards, Badhan Baidya

we already got access to com.apple.developer.usernotifications.filtering , we have set up this special permission in our app extension entitlement and provision profile. but we are still unable to filter notification by providing empty UNNotificationContent

I'm working on implementing Apple Wallet passes using background push notifications. My server successfully sends the push notification using APNs. The response from the server is HTTP/2 200, and the device receives the push — I can confirm this from device logs. However, the device logs show the following error: "Failed to parse JSON message payload for topic " "Unable to deserialize JSON message payload" My payload is below 2 payload. //string payload = "{"aps":{"content-available":1}}"; string payload = JsonConvert.SerializeObject(new { aps = new Dictionary<string, object> { { "content-available", 1 } } }); string curlArgs = $"-s -o nul -w \"%{{http_code}}\" " + $"--data-binary \"{payload}\" " + $"-H \"apns-topic: {bundleId}\" " + $"-H \"apns-push-type: background\" " + $"-H \"apns-priority: 5\" " + $"-H \"content-type: application/json\" " + $"-H \"authorization: bearer {jwt}\" " + $"--http2 https://api.push.apple.com/3/device/{token}"; I’ve confirmed that: The device has the Wallet pass installed. The apns-topic header is set to my passTypeIdentifier. The apns-push-type is background and apns-priority is 5. Steps to Reproduce: Install Wallet pass on iOS device. Send background push to device using the above payload. Observe the device logs using Console.app or log stream. See error: unable to deserialize JSON message payload. Is there a specific payload format expected for Wallet passes? Or any additional fields required in the push payload to avoid this deserialization error?

There is one xpc server and two xpc clients (clientA and clientB). When clientB sends a message to the xpc server, xpc server fills a value for dummyString in it's memory and I want clientA to know that dummyString got updated and also the new value for this dummyString. The updation of dummyString is not something that happens often. Two options we tried: Have a timer for 5 seconds in clientA and keep polling and request for the value of this dummyString. Setup a darwin notification in server that gets posted whenever dummyString is being updated. clientA receives requests for dummyString value only when it observes a notification being posted. Which of these two approaches causes the least delay for clientA to know the updated value of dummyString?

Hi all, We encountered an issue where APNs (Apple Push Notification service) push messages cannot be received during development. The specific description is as follows: Our app runs on an iPad that connects to the cellular network using a SIM card and accesses the Internet through the company's MDM, which provides APN setting proxies. During operation, we found that the device fails to receive push messages from APNs. Network packet capture revealed that the connection attempt by apsd to port 5223 failed. According to Apple's documentation (https://support.apple.com/zh-cn/102266), when port 5223 cannot be connected to, it will fall back to port 443 and use a proxy. However, our packet capture showed that when port 5223 was unreachable, the apsd service on the iPad did not attempt to establish a connection to port 443. Since the iPad device currently cannot establish a connection with APNs, it consistently fails to receive push messages from APNs. We tried disconnecting the SIM card and using a Wi-Fi environment, and in this case, the iPad device was able to receive push messages from APNs normally. Could you advise us on how to proceed with troubleshooting in this situation?

I'm facing an issue delivering VoIP push notifications to user devices. It's pretty random, sometimes notifications are delivered and sometimes not. I've had a call with the user to understand and narrow down the issue, including testing delivery of pushes to their device token via Push Notification Console as described here: https://developer.apple.com/documentation/usernotifications/testing-notifications-using-the-push-notification-console#4181180. I asked a user to use Wi-Fi first and tried delivering around 10 pushes via console and 2 of them were lost while the rest was delivered. I asked a user to use cellular and tried delivering also around 10 pushes and most of them were lost and only few of them were delivered. Production environment was used to deliver pushes hence I cannot see delivery log and so I have no visibility over a reason why push wasn't delivered. I wanted to file a code-level support ticket to get help however I need to supply a sample xcode project which in this particular case doesn't make any sense as I'm using Apple's Push Notification Console tool and it delivers pushes in some cases while doesn't deliver it in other cases. I'm pretty familiar with all potential reasons why push might not be shown on device, including app early crashes, not reporting a call to CallKit etc. => although you never know, I'm pretty sure it's not our case. How can I get support on investigating specific user device token delivery issues like in the case I described above? I have device token and push console records but it's not clear how to get support on that. Thank you!

I am trying to retrieve delivered notifications using UNUserNotificationCenter.getDeliveredNotifications(completionHandler:), but I have encountered an issue: Notifications triggered by UNTimeIntervalNotificationTrigger or UNCalendarNotificationTrigger appear in the delivered list. However, notifications triggered by UNLocationNotificationTrigger do not appear in the list. Here is the code I use to fetch delivered notifications: UNUserNotificationCenter.current().getDeliveredNotifications { notifications in for notification in notifications { print("Received notification: \(notification.request.identifier)") } } The notification is scheduled as follows: let center = UNUserNotificationCenter.current() let content = UNMutableNotificationContent() content.title = "Test Notification" content.body = "This is a location-based notification." content.sound = .default let coordinate = CLLocationCoordinate2D(latitude: 37.7749, longitude: -122.4194) // Example coordinates let region = CLCircularRegion(center: coordinate, radius: 100, identifier: "TestRegion") region.notifyOnEntry = true region.notifyOnExit = false let trigger = UNLocationNotificationTrigger(region: region, repeats: false) let request = UNNotificationRequest(identifier: "LocationTest", content: content, trigger: trigger) center.add(request) { error in if let error = error { print("Error adding notification: \(error.localizedDescription)") } } Why does getDeliveredNotifications not return notifications that were triggered using UNLocationNotificationTrigger? How can I retrieve such notifications after they have been delivered?

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'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?

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.

When I turn the Ringtone and Alerts volume all the way up, I expect standard notifications to play at the loudest level the device allows. In theory, this should match the volume of a critical alert with its sound.volume set to 1.0 in payload. However, I’ve noticed that non-critical notifications still play quieter than critical alerts under these conditions. Critical alerts with volume: 1.0 sound noticeably louder than standard notifications, even though the Ringtone and Alerts slider is already set to maximum. And I couldn't find a documentation for this behavior anywhere. Is this expected behavior on iOS? And is there any way to make non-critical notifications play at the same maximum loudness as critical alerts? Thanks in advance for any clarification.

The APNs Feedback Service domain “feedback.push.apple.com” was deprecated on March 31, 2021, and became unavailable after August 2025 due to domain name resolution failures. Will this feedback service become available again in the future? Also, is it possible to use the APNs Feedback Service with a domain different from “feedback.push.apple.com”?

I am currently implementing VoIP push notifications in my iOS app using PushKit. On iOS 18, I am able to receive VoIP notifications successfully when the app is in the foreground. However, when the app is in the background or in a terminated (kill) state, the notifications do not arrive. In earlier iOS versions, my existing implementation worked as expected across all app states. This issue seems to have started after testing on iOS 18, which appears to have introduced stricter permission or background execution requirements. Questions: Has iOS 18 introduced new permission requirements or entitlements for VoIP push notifications? Do I need to explicitly request a new type of user permission for VoIP notifications? Are there additional background modes, Info.plist keys, or PushKit changes required for VoIP to work in background and terminated states on iOS 18? Additional Information: . Foreground: Works fine, pushRegistry(_:didReceiveIncomingPushWith:for:completion:) is triggered. . Background/Terminated: No call to the above delegate method. . Using correct voip push type in the payload. . PushKit is configured in AppDelegate. . Background modes for "Voice over IP" and "Background Processing" are enabled. . Using a real device with iOS 18 for testing (not simulator). Any guidance or updated documentation references for handling VoIP pushes in iOS 18 would be greatly appreciated.

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