I have a function in my app to detect if screens are added or removed, watching for notifications from NSApplication.didChangeScreenParametersNotification. I am seeing some strange behavior when the screen attached to a Mac mini is turned off, macOS will spit out hundreds of the didChangeScreenParametersNotification, all relating to a 'ghost' screen being added and then subsequently replaced with the original screen a second later. This cycle will go on for hours until the screen is turned back on again. I can confirm this also happens with the CoreGraphics equivalent, with flags .added and .removed being the only changes. I would imagine this creates immense churn for all apps watching for screen changes. I've tried debouncing the notifications but even with a delay of 10 seconds this is still being called hundreds of times while the computer is idle and the screen is off. One constant I can see is that the CGDisplayUnitNumber() for the 'ghost' display is always 0, while the logical unit number for the real screen is '1'. Is it safe to ignore screens with 0? I'm trying to find a reliable way to prevent heavy processing for 'false' screens. I'm afraid because this ghost screen has parameters so different to the actual screen, it's otherwise not possible to ignore it as it looks like a new screen. See example below: // Observe notification NotificationCenter.default.addObserver(self, selector: #selector(displaysDidChange), name: NSApplication.didChangeScreenParametersNotification, object: nil) // Function to update screens called from displaysDidChange func updateScreens() { let screens = NSScreen.screens for screen in screens { guard let screenDisplayID = screen.displayID() else { NSLog("Screen does not have a display ID: \(screen.localizedName)") continue } let screenIdentifier = "v\(CGDisplayVendorNumber(screenDisplayID)), m\(CGDisplayModelNumber(screenDisplayID)), sn\(CGDisplaySerialNumber(screenDisplayID)), u\(CGDisplayUnitNumber(screenDisplayID)), sz\(CGDisplayScreenSize(screenDisplayID))" } // -- Logic to determine if screen is new or already exists for window management -- NSLog("Found new screen display ID \(screenDisplayID) (\(screenIdentifier)): \(screen.localizedName)") } And the logging I'll get: Found new screen display ID 2 (v16652, m1219, sn16843009, u1, sz(1434.3529196346508, 806.823517294491)): Philips FTV Found new screen display ID 10586 (v1970170734, m1986622068, sn0, u0, sz(677.3333231608074, 380.9999942779541)):

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.

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?

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?

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.

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 developing a system to send VoIP notifications to terminals with APNs. I understand that the maximum JSON Payload for VoIP is 5kb. If I want to send VoIP notifications to 3000 terminals, I am considering sending 3000 requests in parallel from the system to the APNs, will the APNs guarantee that the notifications will be sent to each terminal without a significant time lag when receiving 3000 requests simultaneously?

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!

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 have tried setting a 'apns-expiration' to current time + 30 seconds and also a value '0'. But still my voip app receives the voip push notification after 2-3 minutes. Till this time, caller has already hung up the call. But the receivers phone still rings on receiving the push notification as we have to report it to CallKit. Am I missing something or there is no way and even 'apns-expiration' does not guarantee timely delivery of Voip push notifications or discard if it is expired. I have set 'apns-priority' to 10 already as recommended.

Push-notification token is properly requested and displayed from the iOS simulator / xcode, but not from the release in the AppStore... Both popups for permission (push-notifications and critical alert) appear and can be confirmed, but no callback takes place...

Hi Team, We’re following up on our request for the Critical Alert entitlement for our app, which we plan to use to notify users about critical states of their devices. It’s been almost 4 weeks since we submitted the request, and we wanted to check on the typical review timeline so we can plan our upcoming work accordingly. If there’s anything we can provide or clarify to help complete the review or make the process easier, we’d be happy to assist. or the right forum to reach out to.

Hello. I'm currently implementing Apple Notification v2 to prepare for refunds for in-app purchases, but I'm not receiving requests from Apple servers to my backend server. I've applied HTTPS (TLS 1.2) and correctly registered production/sandbox notification URLs on App Store Connect. After requesting a test notification, when I check the status of testNotificationToken, I receive an UNSUCCESSFUL_HTTP_RESPONSE_CODE as follows: {"signedPayload":"......":[{"atteptDate":1752128001970,"sendAttemptResult":"UNSUCCESSFUL_HTTP_RESPONSE_CODE"}]} The endpoint for receiving notifications is set to accept POST requests with application/json format, and it responds with 200 (OK) without any content. However, Apple notifications are not coming through. Could anyone help me with this issue?

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?

I’m building a standalone Apple Watch smart alarm app that should trigger alarms on the watch in response to Bluetooth or internet events. This means the app operates in the background and attempts to trigger an alarm when such an event occurs. As far as I know, the appropriate API for this is WKExtendedRuntimeSession.notifyUserWithHaptic:repeatHandler. However, I can’t seem to start an extended runtime session while the app is in the background. I’m getting the following error: -[WKExtendedRuntimeSession _invalidationReasonAndDelegateCallbackErrorForError:outCallbackError:]:729: WKExtendedRuntimeSession hit internal error. Error Domain=com.apple.CarouselServices.SessionErrorDomain Code=17 "startSession cannot be called on a scheduled session" UserInfo={NSLocalizedDescription=startSession cannot be called on a scheduled session} Calling notifyUserWithHaptic directly also similarly fails. It seems notifyUserWithHaptic is intended to be scheduled during a foreground session to trigger at a later time, rather than being called ad hoc from a background context. Is there any way to create a proper alarm view on the Apple Watch from a background execution context?

I have a “1” above the setting app on my iPhone. However when I open settings there is no notification that shows up. I have tried force restarting and done the beta updates as they release however nothing works to got rid of it. What can I do?

Hi team, We've observed that for all background notifications (where content-available set to true, https://developer.apple.com/documentation/usernotifications/pushing-background-updates-to-your-app#Create-a-background-notification), we never received any response with error string "Unregistered". This differs from non-background pushes, where expired tokens are regularly cleared. Is this the expected behavior (i.e., background notifications will not return an "Unregistered" error), or could this indicate an issue on our side? Thanks in advance for any clarification.

以下の問題が発生しています： 特定のデバイスでプッシュ通知が受信されません。 考えられる原因は何でしょうか？ プッシュ通知は自社のサーバーから送信しており、APNs（Apple Push Notification service）からは正常な応答が返ってきています。 ユーザーはデバイスで通知が有効になっていることを確認しており、ネットワークの問題も報告されていません。 この問題は複数のユーザーに発生しています。

I am checking if the user taps on the firebase push notification and get the payload. override func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) { let userInfo = response.notification.request.content.userInfo os_log("notification tapped %{public}@", log: OSLog.push, type: .info, userInfo) handleNotificationPayload(userInfo as! [String: AnyObject]) setFlutterLinkClickedVariable() } My use case is in app terminated state when push notification is tapped, get the link from payload and navigate to corresponding screen based on the link. This is working when there is only one push notification. When there are multiple push notifications with different links in the payload, only the first notification I tap works. Rest of the notifications just launches the app and does not navigate because the link is not set. I am getting the link from the payload and invoking flutter code which sets the link in the user defaults (shared preferences) and when the app launches in the home screen it checks for this variable and navigates accordingly. func handleNotificationPayload(_ payload: [String: AnyObject]) { if let link = payload["link"] as? String { setFlutterLinkVariable(link) } } override func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) { os_log("app did receive remote notification %{public}@", log: OSLog.push, type: .info, userInfo) handleNotificationPayload(userInfo as! [String : AnyObject]) completionHandler(.newData) } Currently when there is only one push notification it works because the link is set from the above method. The click delegate is not calling. I did set the delegate in application(:didFinishLaunchingWithOptions). UNUserNotificationCenter.current().delegate = self application.registerForRemoteNotifications() How to solve this issue? Thanks.