We are trying to figure out a strange issue. Our app has not changed for at least 10 months but my devices and the QA tester device have all stopped receiving push/call notifications for twilio voip The twilio credential and apple voip services certificate are in date and valid It is pointing to the correct bundle id and topic (not changed configuration for years) token passed in to TwilioVoiceSDK.register() is retrieved from PKPushRegistry as per guide Running locally the Twilio Voice SDK successfully registers and retrieves APNs token What is interesting is if I log in with exactly the same client account on an iOS 18.5 device (and an older iPad) call notifications work perfectly (I have made sure all focus modes/dnd are off and notification settings are identical) The only changes myself and QA have made recently is minor iOS 18 version updates - 18.6.2 and 18.7.1 These now receive Invalid device token from APNs when Twilio attempts to create a call/voip notification for the user identity Our devices sometimes switch environments test/prod so I installed the app cleanly on a borrowed 18.6.2 device and got the exact same issue We have tested on these devices most of the year with no issues. I have been in touch with twilio support and added code to explicitly unregister and re register on an affected device to clear any bindings but it didn't help. Have apple made any changes in PushKit or token behaviour for later versions of iOS 18? Thanks

In the new update of macOS 26 Tahoe, I have noticed that on my MacBook Air M3, I am not getting a warning when my battery is low or when it's about to go to sleep. My MacBook is just turning off without warning.

When subscription renewing , can do purchase_date faster than notification_date quickly? I received my app user purchase notification this purchase date is 2025-08-31 06:42:54(UTC) but notification date is 2025-08-30 22:45:01(UTC) how can you do this? I can't understand it please let me explain

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!

I dont want my server to be spammed. Currently I am only in payment-related notifs (eg: user successfully renewed his subscription, user didnt successfully renew his subscriptions, ..) Where can I set that?

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.

We have implemented Carplay in our voip based project and in this we have implemented Incoming call and chat notification feature for Carplay. For Carplay we implemented siri. Siri Object donated Successfully in Notification service Extension when notification didreceive method called. Donation Code :- func donateIncomingMessageIntent(sender: String, senderId: String, message: String, messageId: String, userInfo: [AnyHashable: Any],destination:String) { // Create proper name components clearAllinteraction() var nameComponents = PersonNameComponents() nameComponents.givenName = sender //unknown let senderPerson = INPerson( personHandle: INPersonHandle(value: senderId, type: .unknown), nameComponents: nameComponents, displayName: sender, image: nil, contactIdentifier: senderId, customIdentifier: "sender_\(senderId)" ) let recipientPerson = INPerson( personHandle: INPersonHandle(value: "me@example.com", type: .emailAddress), nameComponents: nil, displayName: "Me", image: nil, contactIdentifier: "me_id", customIdentifier: "user_id" ) let inMessage = INMessage( identifier: messageId, conversationIdentifier: "conversation_\(senderId)", content: message, dateSent: Date(), sender: senderPerson, recipients: [recipientPerson], groupName: nil, messageType: .text ) let intent = INSearchForMessagesIntent( recipients: [recipientPerson], senders: [senderPerson], searchTerms: [message], attributes: .unread, dateTime: nil, identifiers: [messageId], notificationIdentifiers: [messageId], groupNames: ["Messages"] ) let interaction = INInteraction(intent: intent, response: nil) interaction.identifier = "message_\(messageId)" interaction.direction = .incoming // Add direction DispatchQueue.global(qos: .userInitiated).async { interaction.donate { error in if let error = error { print("❌ Failed to donate INSearchForMessagesIntent: \(error.localizedDescription)") } else { print("✅ Donated INSearchForMessagesIntent successfully!") let intentData: [String: Any] = [ "senderName": sender, "senderId": senderId, "message": message, "messageId": messageId, "timestamp": Date().timeIntervalSince1970, "conversationId": "conversation_\(senderId)", // Add conversationId "destination":destination ] let defaults = UserDefaults(suiteName: "group.com.chatapp") // 🔁 Use your App Group ID defaults?.removeObject(forKey: "lastCarPlayIntentData") defaults?.set(intentData, forKey: "lastCarPlayIntentData") defaults?.synchronize() } } } } Here SenderID is like 3000@abc,2000@abc etc. In siri ,When we handle INSearchForMessagesIntent at that time all data getting from Userdefaults because without Userdefaults INSearchForMessagesIntent value nil. Even we enabled announcement using .allowAnnouncement. We also tried to save same sender in contact Book because sometime siri search contact and not found then may be raise this type of issue. So we need code level support for read incoming message in carplay when notification comes. Thank you.

token:009739d008a19dbe7e2273a1e4e8b5f73c4e2d7e220e7308f41e316f4c2fcf56 最近app无法收到服务端通过apns推送的通知，提交是成功的，但是app的所有用户都无法收到通知

When sending a single push notification to iOS 18 devices users receive the same notification multiple times. This issue appears specific to iOS 18 and was not observed in previous iOS versions Our server logs confirm each notification is sent only once. Notification payloads include proper apns-id values for identification and no network issues detected on our side

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.

Hey there,i start a live activity,but it not works, and sometime it can work; apns-unique-id 46445cfa-1bf6-0f63-5ea3-2afa53e02b0d and it show that " 2025年5月19日 GMT+8 15:13:25.836 received by APNS Server 2025年5月19日 GMT+8 15:13:26.244 discarded as application was not registered" but i did not know how can i do; thanks for you help

I wanted to know if Apple ever supported displaying a red dot on notificationswith no indication number.

Is there a public method to know when an APNS has appeared on the screen? wrapping up a very high end photogrammetry app, using the front facing camera and screen illumination- incoming notifications completely throw off the math. Ideally, it would be great to turn on Do Not Disturb for the short process, but we’d settle for just the detection of the notification banner. also: extra credit - programattically adjusting Auto Dimming, and True Tone would be lovely too.

Hi all, May I please ask for an official clarification or documentation reference from Apple regarding this scenario: Is it possible for an iOS app to automatically launch or open a specific screen when a push notification is received — while the app is in the background or terminated (killed) state? I understand that for most cases, user interaction (such as tapping the notification) is required before the app can show UI. However, I’d like to confirm whether this is also true for time-sensitive or critical alert notifications, including emergency use cases (e.g. public safety alerts). Specifically: Can a critical alert notification directly launch the app or present a view controller? Or is user interaction always required before the app can present any UI, even with the critical alert entitlement? I would appreciate if anyone — especially Apple staff or engineers — could share an official Apple document or statement that confirms this behavior. Thank you very much! (Use case context: I’m developing an emergency broadcast feature for a property management / tenant app.)

We are observing an weird behaviour where a user uninstalled the app back in February (more than a month ago) but APNs is still accepting push notifications are returning success responses. We know that using APNs response codes for uninstall tracking is not reliable and that Apple will use fuzzy schedule to invalidate tokens. However, showing successful responses for month+ old tokens seems a bit misleading and results in wasted token processing for both us and Apple. Could you please confirm that invalidation (or fuzzy schedule) could take more than months to invalidate tokens on the APNs side? Is that expected or is this a bug somewhere?

Hi, there is a issue that iOS background NFC scanning will only provide a notification result, It need user click to enter my APP, can I have any method to enter my APP directly without user action ?

We are so interested in AlarmKit which is presented at WWDC25. While we planning our app using AlarmKit, We had a few questions come to mind and were hoping you could provide some clarity. Please excuse the rather long list of questions, as we don't currently have a device available to test these features ourselves. System Actions Related Is there a limit to the number of alarms that can be scheduled using AlarmKit? Are alarms scheduled with AlarmKit persistent across device reboots? When an alarm is dismissed (either by swiping or pressing the power button), can our app detect this action and execute code in response? Can we control the behavior of the physical Lock Screen buttons when an AlarmKit alarm is active, for instance, to trigger a snooze action? Does AlarmKit function correctly during Do Not Disturb or Low Power Mode? What is the expected behavior when an alarm from our app (using AlarmKit) overlaps with an alarm from another app that also uses AlarmKit? Which one is going to get its priority? Thank you for your help. Sincerely

I'm experiencing issues with didRegisterForRemoteNotificationsWithDeviceToken not being called on iOS 18.1.1. Here's what I've tried: Basic Setup: Properly configured UNUserNotificationCenter Requested permissions with requestAuthorization(options:) Registered for remote notifications with registerForRemoteNotifications() Environment: Xcode 16.3 iOS 18.1.1 (physical device) Firebase (tried with and without it) Troubleshooting: Verified provisioning profile includes Push Notifications Confirmed APNs certificate is valid Disabled Firebase's method swizzling Tested on a clean project (works fine) Checked device logs (no relevant errors) Code Snippet: // In AppDelegate.swift public func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { let tokenParts = deviceToken.map { data in String(format: "%02.2hhx", data) } let tokenString = tokenParts.joined() print("📱 Device Token: \(tokenString)") // Store the token for your backend UserDefaults.standard.set(tokenString, forKey: "deviceToken") // Send to backend Task { do { try await APIService.shared.setDeviceToken(tokenString) } catch { print("❌ [AppDelegate] Failed to send device token to backend: \(error)") } } } public func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool { // IMPORTANT: First handle push notification registration UNUserNotificationCenter.current().delegate = self // Request notification permissions self.requestNotificationPermissions() // Register for remote notifications DispatchQueue.main.async { UIApplication.shared.registerForRemoteNotifications() } return true } private func requestNotificationPermissions() { UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in guard granted else { print("❌ Notification permission not granted") return } print("✅ Notification permission granted") } }

I have multiple app ids that are registered with Push Notification, however they do not hsow up in the Push Notification Console for testing.

In macOS, how can I use UnmutableNotificationContent notifications to prevent the main window from activating when clicking the notification? code： import Cocoa import UserNotifications // Mandatory import for notification functionality class ViewController: NSViewController { override func viewDidLoad() { super.viewDidLoad() // Automatically request permissions and send a test notification when the view loads sendLocalNotification() } /// Core method to send a local notification func sendLocalNotification() { let notificationCenter = UNUserNotificationCenter.current() // 1. Request notification permissions (Mandatory step; user approval required) notificationCenter.requestAuthorization(options: [.alert, .sound, .badge]) { [weak self] isGranted, error in guard let self = self else { return } // Handle permission request errors if let error = error { print("Permission request failed: \(error.localizedDescription)") return } // Exit if user denies permission if !isGranted { print("User denied notification permissions; cannot send notifications") return } // 2. Construct notification content using UNMutableNotificationContent let notificationContent = UNMutableNotificationContent() notificationContent.title = "Swift Notification Test" // Notification title notificationContent.subtitle = "macOS Local Notification" // Optional subtitle notificationContent.body = "This is a notification created with UNMutableNotificationContent" // Main content notificationContent.sound = .default // Optional notification sound (set to nil for no sound) notificationContent.badge = 1 // Optional app icon badge (set to nil for no badge) // 3. Set trigger condition (here: "trigger after 3 seconds"; can also use time/calendar triggers) let notificationTrigger = UNTimeIntervalNotificationTrigger( timeInterval: 3, // Delay in seconds repeats: false // Whether to repeat (false = one-time only) ) // 4. Create a notification request (requires a unique ID for later cancellation if needed) let notificationRequest = UNNotificationRequest( identifier: "SwiftMacNotification_001", // Unique identifier content: notificationContent, trigger: notificationTrigger ) // 5. Add the request to the notification center and wait for triggering notificationCenter.add(notificationRequest) { error in if let error = error { print("Notification delivery failed: \(error.localizedDescription)") } else { print("Notification added to queue; will trigger in 3 seconds") } } } } }