We have a question regarding iOS app configuration and the Remote notifications background mode. During our testing, we observed: ＊When enabling or disabling Signing & Capabilities > Background Modes > Remote notifications, the change does not take effect on devices that already have the app installed. ＊The app continues to behave according to the old configuration. ＊Only after uninstalling the app and reinstalling it from the App Store do the new settings take effect (for example, whether the app can be woken up by silent push). ＊We also tested updating the app with a new version number (App Store upgrade flow), but the new settings still did not apply. Our questions are: 1.Is there any way to make iOS re-read the updated Signing & Capabilities (Background Modes) settings without requiring a full uninstall/reinstall? 2.Is it expected behavior that even an App Store upgrade with a new version number will not apply these changes? thanks!

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

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 everyone, I'm developing a custom Apple Wallet pass using a Django backend and exposing my local server through ngrok during development. For the first ~30 minutes, everything works exactly as expected: the pass registers correctly, silent push notifications trigger instant updates, Wallet immediately performs the GET request to fetch the new .pkpass, and the changeMessage displays almost instantly on the lock screen. At some point, however, the pass stops updating entirely. Apple APNs continues to return 200 OK for every silent push I send, but the device never performs the required GET /v1/passes// call to download the updated pass. As a result, even the internal content of the pass (ex: points/balance fields) no longer updates, which confirms that Wallet is not fetching the new .pkpass at all. No changeMessage appears either. This behavior has been described informally by other developers as Apple Wallet Pass Update Throttling, where the Wallet daemon begins ignoring silent pushes after repeated updates or certain internal conditions. I’m trying to confirm whether this is indeed throttling, what triggers it, and how to avoid it during development.

Hi, We have a use case where our app needs to send repeated push notifications (both normal and critical alerts) to inform the user about a critical device state and grab their attention. Since iOS doesn’t allow us to schedule local notifications beyond 30 seconds, I need to send multiple pushes from the server side. My questions are: Is there any documented limit on how many push notifications can be sent back-to-back before Apple starts throttling or restricting them? Are critical alerts treated differently from normal notifications in terms of delivery restrictions or frequency limits? Is there a recommended approach for handling scenarios where repeated urgent notifications are necessary to keep the user informed? I want to make sure I’m following Apple’s guidelines and not risking rejection during review.

We are developing a walkie-talkie style iOS app using CallKit and PushKit for real-time voice communication. The app is intended for internal company use and requires unrestricted VoIP push capabilities to reliably deliver incoming call alerts, even in background or locked states. Our app's use case follows Apple’s guidelines, and we are not using PushKit for messaging or background data. We have already enabled "Push Notifications" in Capabilities and confirmed the provisioning profile, but are unable to enable com.apple.developer.pushkit.unrestricted-voip. Could someone from Apple or the community advise on the current process to request this entitlement for a production app? Developer Team ID: 3KX7Q4LX88 App Bundle ID: com.ksc-sys.rcc.TakumiTalk Developer Name: KOHEI TAKAOKA Company: R C C, Y.K

We have an app that uses PushKit and CallKit for video calling. These are often emergency calls, so very latency-sensitive. We keep track of when we sent out the APNs request and when the phone started ringing. The p95 latency is about 2 seconds (mean is ~800ms), which feels quite long.. Is this normal? I'd expect <500ms most of the time given that the devices and servers are all within the US. The users typically have a stable internet connection. Our requests look like this: POST https://api.push.apple.com/3/device/<DEVICE_TOKEN> apns-topic: com.vpt.physician.voip apns-push-type: voip apns-priority: 10 apns-expiration: 0 authorization: bearer <APNS_PROVIDER_TOKEN> content-type: application/json {  "aps": {    "content-available": 1  },  "title": "Example Text",  "type": "CallFromTablet",  "timeout_ms": 30000 } If there's any more info I can provide to help troubleshoot this, let me know. Thanks in advance.

I’m building a firefighter app that needs to automatically check in a firefighter when they arrive at the station and check them out when they leave — even if the app is killed. We need reliable enter/exit detection, low latency, and only one fixed location per user. We’re evaluating Region Monitoring, which works in the killed state but may introduce delays and inconsistent accuracy. To ensure mission-critical reliability, we are considering the Location Push Service Extension, since it can fetch precise location on demand and wake the extension even when the app is terminated. Before requesting the restricted entitlement, we need clarification on Apple’s expectations: Is Region Monitoring recommended for this fixed-location use case? Would Apple consider approving the Location Push Service Extension for a public-safety workflow? What prerequisites do we need before submitting the entitlement request (Always permission, prototype, privacy disclosures, etc.)? What details should be included in the justification form? Our goal is to follow the most reliable and Apple-approved approach for firefighter check-in/out. Any guidance would be greatly appreciated.

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?

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") } } } } }

I created an app. One if its functionalities is receive Remote Notification in the background, while app is monitoring Significant Location Changes (SLC). This functionality worked fine. I was receiving these notifications correctly. Sometimes instantly, sometime with small or large delay. And then I send the app for review. It was rejected with 3 remarks: The app or metadata includes information about third-party platforms that may not be relevant for App Store users, who are focused on experiences offered by the app itself (I wrote that app communication works both for iOS and Android.) The app declares support for audio in the UIBackgroundModes key in your Info.plist but we are unable to locate any features that require persistent audio. EULA (End User License Agreement) is missing for in-app purchases. After the rejection the app is no longer receiving these notifications. They are there, since the app receives them, when I open app, or significant location change is detected. It also works, when I run the app directly from Xcode (in debug mode), not from TestFlight nor in Sandbox. It seem to me like Apple somehow spoiled my background capabilities on purpose or accidentally. Is it possible? What can I do with it? Is it the case that I should just fix the review remarks and send the app back to review, and once the app passes it, it will work again? Or should I not count on it? Any suggestions? I asked Apple using: https://developer.apple.com/contact/topic/#!/topic/select but so far no response.

Hello, We are planning to shut down our mobile app service and need to discontinue our auto-renewable subscription product. Our service termination date is July 31, and we are currently preparing the backend implementation for this. We have reviewed the official documentation and Apple Developer Forums, but there are several behaviors we cannot confirm through sandbox testing, as the "Remove from Sale" setting does not appear to affect the sandbox environment. We would greatly appreciate clarification on the following: Server notification at the moment of "Cleared for Sale" being unchecked When we uncheck "Cleared for Sale" in App Store Connect, is any App Store Server Notification (V2) sent to our server immediately at that moment? If yes, what is the exact notificationType and subtype value sent? If no, when is the first notification triggered for existing active subscribers after this action? 2. Notification sequence from product removal through final expiration For existing active subscribers, what is the exact sequence of notificationType and subtype values our server should expect — from the moment we remove the product from sale through the subscriber's final expiration? Based on our research, we believe the sequence may be: (1) Cleared for Sale unchecked → (2) No immediate notification → (3) At next renewal attempt → EXPIRED with subtype PRODUCT_NOT_FOR_SALE Could you confirm whether this is correct, or provide the accurate sequence? 3. Whether DID_CHANGE_RENEWAL_STATUS is sent before EXPIRED Is a DID_CHANGE_RENEWAL_STATUS notification sent to our server at the moment of removal from sale, before the EXPIRED notification at the renewal date? If yes, what is the subtype of this notification? 4. Recommended server-side handling per notification For each notification in the sequence above, what is the recommended server-side action? For example: On EXPIRED with subtype PRODUCT_NOT_FOR_SALE → revoke entitlement immediately? On DID_CHANGE_RENEWAL_STATUS (if sent) → update status only, do not revoke entitlement yet? Sandbox testing limitations We have confirmed that the "Remove from Sale" setting does not affect the sandbox environment. Is there any recommended way to test this scenario before applying it in production? If sandbox testing is not possible for this case, is there any official confirmation of this limitation? We have a fixed service termination schedule and need to ensure our backend handles this correctly. Any clarification or pointers to official documentation would be greatly appreciated. Thank you.

I’m currently developing an iOS app built in Unity, exported to Xcode for signing and deployment. The app needs to register for Apple Push Notifications (APNs) to retrieve the device token and register it with a backend service (PlayFab). Despite enabling the required capabilities and entitlements, the app never receives a device token — the authorization request succeeds, but the token remains empty (req.DeviceToken is null in Unity). I’ve confirmed that the issue occurs before PlayFab or Firebase are involved, meaning the app never receives the token from Apple Push Notification service (APNs) itself. The Unity script I am using is: #if UNITY_IOS using UnityEngine; using Unity.Notifications.iOS; using PlayFab; using PlayFab.ClientModels; using System.Collections; using System; public class iOSPushInit : MonoBehaviour { private const int MaxRetries = 5; private const float RetryDelay = 2f; // seconds void Start() { Debug.Log("🛠 iOSPushInitDebug starting..."); StartCoroutine(RequestAuthorizationAndRegister()); } private IEnumerator RequestAuthorizationAndRegister() { // Request Alert + Badge + Sound permissions and register for remote notifications var authOptions = AuthorizationOption.Alert | AuthorizationOption.Badge | AuthorizationOption.Sound; using (var req = new AuthorizationRequest(authOptions, true)) { Debug.Log("⏳ Waiting for user authorization..."); while (!req.IsFinished) { yield return null; } Debug.Log($"🔔 Authorization finished at {DateTime.Now}: granted={req.Granted}, error={req.Error}"); if (!req.Granted) { Debug.LogError("❌ User denied notification permissions! Cannot get APNs token."); yield break; } // Authorization granted → check for device token int attempt = 0; string token = req.DeviceToken; Debug.Log($"req.DeviceToken: {req.DeviceToken}"); while (string.IsNullOrEmpty(token) && attempt < MaxRetries) { attempt++; Debug.Log($"ℹ️ APNs token not available yet. Attempt {attempt}/{MaxRetries}. Waiting {RetryDelay} seconds..."); yield return new WaitForSeconds(RetryDelay); token = req.DeviceToken; } if (string.IsNullOrEmpty(token)) { Debug.LogWarning("⚠️ APNs token still null after multiple attempts. Try again on next app launch."); yield break; } Debug.Log($"📱 APNs Token acquired at {DateTime.Now}: {token}"); // Register with PlayFab var request = new RegisterForIOSPushNotificationRequest { DeviceToken = token, SendPushNotificationConfirmation = false }; PlayFabClientAPI.RegisterForIOSPushNotification(request, result => Debug.Log("✅ APNs token successfully registered with PlayFab."), error => Debug.LogError("❌ Failed to register APNs token with PlayFab: " + error.GenerateErrorReport())); } } } #endif When running on a real device (not simulator), the following is logged in Xcode: 🔔 Authorization finished: granted=True, error= ℹ️ APNs token not yet available. Try again on next app launch. In the Xcode console, I do not see the expected APNs registration message: [Device] Registered for remote notifications with token: <...> Environment Details: Engine: Unity 6000.2.6f2 Notifications package: com.unity.mobile.notifications 2.4.2 Xcode: 16.4 (16F6) iOS Device: iPhone 12, iOS 26.0.1 Testing Method: Building directly from Unity → Xcode → real device Signing mode: Automatic (with correct Team selected) Certificates in account: Apple Development certificate (active) Apple Distribution certificate (active) Provisioning Profile: Type: App Store (also tested Development profile) Enabled Capabilities: Push Notifications, In-App Purchase App ID Capabilities: Push Notifications: Enabled Development SSL certificate: Present Production SSL certificate: Not generated (yet) Background Modes -> remote notifications What I Have Verified: ✅ Push Notifications capability is enabled in the Xcode target (not UnityFramework). ✅ Team and Bundle Identifier match my Apple Developer App ID. ✅ App ID has Push Notifications enabled in the Developer Portal. ✅ Tested on a real iOS device with working internet. ✅ Rebuilt and reinstalled app after enabling Push Notifications. ✅ Authorization dialog appears and permission is granted by user. How can I resolve this issue?

The iOS documentation shows notification actions buttons with the text center aligned: https://developer.apple.com/documentation/usernotifications/declaring-your-actionable-notification-types But there's no apparent way for an app to control this. The buttons are controlled and rendered by the system and the text is always left aligned. Is there some way to get the text center aligned?

We are facing an issue where VoIP notifications are not delivered to a user's device. If we login with the user credentials on another device the VoIP notifications are being received, if he logs in on his device VoIP notifications are not being received anymore on all devices. So When the user logs in on the affected device, all devices on that account stop receiving VoIP pushes (including the affected one). Logging out on the affected device restores delivery to other devices. What could cause this issue? It's only happening for this user so the configuration and mobile app PushKit code is working as intended.

I have my app configured as a Driving Task app with the entitlement and provisioning profile correctly set up. I am also requesting the ".carPlay" notification authorization option and setting up the carplay notification category with the ".allowInCarPlay" category, both without error. When testing with the iPhone and carplay simulators the user notifications I send are appearing on the phone but not in carplay. When I check the notification settings with UNUserNotificationCenter.current().getNotificationSettings() I see that carplay is shown to be not supported ("carPlaySetting: NotSupported"). The CarPlay Developer Guide 2025-06-09 (which is the version currently referenced in the Apple docs) states that "Starting in iOS 18.4, notifications are also supported in CarPlay driving task apps". Has this discrepancy been addressed anywhere, or is this an open issue? My software versions: MacOS: Sequoia 15.6 XCode: 16.4 iPhone Simulator: iPhone 16 with iOS 18.6

I have a working AlarmKit app, but I've noticed that after any iOS update (e.g. the 26.0.1 update from a few days ago), my scheduled alarms seem to lose their UI strings, so instead of the Stop button saying "Stop", it says "alarm_ui_stop_button" (which is my localization key for the button text). If I delete the alarm and re-add it, then it works again... until the next software update. It seems like OS updates are interfering with the link between scheduled alarms and app localization strings, which I believe are dynamically looked up at alarm time (not at configuration time). I am settings the strings in the standard way like this: AlarmManager.AlarmConfiguration( schedule: .fixed(date), attributes: AlarmAttributes<SDAlarmMetadata>( presentation: AlarmPresentation( alert: AlarmPresentation.Alert( title: "alarm_ui_title", stopButton: .init(text: "alarm_ui_stop_button", textColor: .yellow, systemImageName: "xmark") ) ), metadata: SDAlarmMetadata(title: title, subtitle: subtitle), tintColor: .yellow ), sound: .default ) Has anyone else noticed this or found a workaround? I guess I could use localization keys that are identical to the desired text, but this would only work for one language.

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!

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.

After porting code to Swift 6 (Xcode 16.4), I get a consistent crash (on simulator) when using UNUserNotificationServiceConnection It seems (searching on the web) that others have met the same issue. Is it a known Swift6 bug ? Or am I misusing UNUserNotification ? I do not have the crash when compiling on Xcode 26 ß5, which hints at an issue in Xcode 16.4. Crash log: Thread 10 Queue : com.apple.usernotifications.UNUserNotificationServiceConnection.call-out (serial) As far as I can tell, it seems error is when calling nonisolated func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) I had to declare non isolated to solve a compiler error. Main actor-isolated instance method 'userNotificationCenter(_:didReceive:withCompletionHandler:)' cannot be used to satisfy nonisolated requirement from protocol 'UNUserNotificationCenterDelegate' I was advised to: Add 'nonisolated' to 'userNotificationCenter(_:didReceive:withCompletionHandler:)' to make this instance method not isolated to the actor I filed a bug report: Aug 10, 2025 at 2:43 PM – FB19519575