Hi, I'm experiencing an issue with my app. I use Firebase as my server, and it is great. Still, there is one issue: when I send push notifications from my app to users, the users will get the notification if the app is open, but not when it is closed. I have tried many solutions to fix it, even asking AI, but the issue is still there. I would be happy to give you access to Firebase and the Xcode workspace, as I have no clue how to fix it.

Hello guys, i need a little help. Im building an alarm clock app, pretty good one, and i have my own sounds i want to use as the alarm ring but notifications on apple cant work when the phone is turned off or the device is in silent mode (Or at least thats how i understand it) unless they have this feature called critical alerts that lets you have notifications even when the phone is turned off or silented. Without this, the phone can do just one beep and only when you open the notification, then it starts ringing but how is this supposed to wake you up? Alarmy has this worked out fine and i cant figure out how, maybe someone here knows. Im thinking maybe they have the critical alerts enabled but then i dont know why Apple would approve theirs and not mine. I tried to submit for the critical alerts feature but apple didn’t approve it saying the app is not the use case and im kinda lost. The whole app could be ruined because of this. So my question is. is there any way how i can use my custom sounds as a notifications on ios even if the phone is turned off or in silent mode+turned off and the app is not straight up running without being approved for critical alerts? Somehow like alarmy does it but i dont know if they have the critical alerts or not. Thank you very much for any kind of help 🙏. For everyone whos reading this, take care!

手机型号：iPhone 13 Pro iOS版本号：iOS 18.6.2 (22G100) 用户开启了应用的系统通知功能，在收到离线推送后应用右上角展示未读消息数。在APP启动或者从后台恢复的时候，应用会用如下方法清理应用桌面图标的未读数角标。但是在部分机型上，应用转为“后台模式”时仍然会出现一个未读角标，且每次都是一个固定值；如果直接kill进程就不会出现未读角标。请问如何能够【完全】清理消息未读数，确保不会在退后台的时候再次出现呢？ [[UIApplication sharedApplication] setApplicationIconBadgeNumber:0]; [[UIApplication sharedApplication] cancelAllLocalNotifications]; if (@available(iOS 16.0, *)) { [[UNUserNotificationCenter currentNotificationCenter] setBadgeCount:0 withCompletionHandler:nil]; [[UNUserNotificationCenter currentNotificationCenter] removeAllPendingNotificationRequests]; [[UNUserNotificationCenter currentNotificationCenter] removeAllPendingNotificationRequests]; } UNMutableNotificationContent *content = [[UNMutableNotificationContent alloc] init]; content.badge = @(-1); UNNotificationRequest *request = [UNNotificationRequest requestWithIdentifier:@"clearBadge" content:content trigger:nil]; [[UNUserNotificationCenter currentNotificationCenter] addNotificationRequest:request withCompletionHandler:^(NSError * _Nullable error) { // Do nothing }];

I have been fighting this problem for two months and would love any help, advice or tips. Should I file a DTS ticket? Summary We attach a JPEG image to a local notification using UNNotificationAttachment. iOS reports the delivered notification as having attachments=1, but intermittently no image preview appears in Notification Center. In correlated cases, the attachment’s UNNotificationAttachment.url (which points into iOS’s attachment store) becomes unreadable (Data(contentsOf:) fails) even though the delivered notification still reports attachments=1. This document describes the investigation, evidence, and mitigations attempted. Product / Component UserNotifications framework UNNotificationAttachment rendering in Notification UI (Notification Center / banner / expanded preview) Environment App: OnThisDay (SwiftUI, Swift 6) Notifications: local notifications scheduled with UNCalendarNotificationTrigger(repeats: false) Attachment: JPEG generated from PhotoKit (PHImageManager.requestImage) and written to app temp directory, then passed into UNNotificationAttachment. Test contexts: Debug builds (direct Xcode install) TestFlight builds (production signing) iOS devices: multiple, reproducible with long runs and user clearing delivered notifications Expected Result Delivered notifications with UNNotificationAttachment should consistently show the image preview in Notification Center (thumbnail and expanded preview), as long as the notification reports attachments=1. If the OS reports attachments=1, the attachment’s store URL should remain valid/readable for the lifetime of the delivered notification still present in Notification Center. Actual Result Intermittently: Notification Center shows no image preview even though the app scheduled the notification with an attachment and iOS reports the delivered notification as having attachments=1. When we inspect delivered notifications via UNUserNotificationCenter.getDeliveredNotifications, the delivered notification’s request.content.attachments.first?.url exists but is unreadable (attempting Data(contentsOf:) returns nil / throws), i.e. the backing attachment-store file appears missing or inaccessible. In some scenarios the attachment-store file is readable for hours while the notification is pending, and then becomes unreadable after the notification is delivered. Reproduction Scenarios (Observed) Next-day reminders show attachment-store unreadable after delivery 1. Schedule a one-shot daily reminder for next day (07:00 local time) with UNCalendarNotificationTrigger(repeats: false) and a JPEG attachment. 2. During the prior day, periodic background refresh tasks verify the pending notification’s attachment-store URL is readable (pendingReadable=true). 3. After the reminder is delivered the next morning, the delivered snapshot shows the delivered notification’s attachment-store URL is unreadable (readable=false) and Notification Center shows no preview. Interpretation: the attachment-store blob appears to become inaccessible around/after delivery, despite being readable while pending. Evidence and Instrumentation We added non-crashing diagnostic logging (Debug builds) around: Scheduling time Logged that we successfully created a UNNotificationAttachment from a unique temp file. Logged that UNUserNotificationCenter.add(request) succeeded. Queried pendingNotificationRequests() and logged the scheduled request’s attachment url.lastPathComponent (iOS attachment-store filename). Delivered time (when app becomes active) Called UNUserNotificationCenter.getDeliveredNotifications and logged: delivered count, attachment count attachment url.lastPathComponent whether Data(contentsOf: attachment.url) succeeds (readable=true/false) Content fingerprinting Fingerprinted the exact JPEG bytes we wrote (SHA-256 prefix + byte count). Logged the iOS attachment-store filename (url.lastPathComponent) returned post-scheduling. Decode validation probe (later addition) When Data(contentsOf:) succeeds, we validate it decodes as an image using CGImageSourceCreateWithData and log: UTI (e.g. public.jpeg) pixel width/height magic header bytes What we tried / Mitigations Proactive “self-heal” for pending notifications Change: during background refresh/foreground refresh, verify the pending daily reminder’s attachment-store URL readability. If it’s unreadable, reschedule with a new attachment (same trigger). Rationale: if iOS drops the store file before delivery, recreating could repair it. Result: We observed cases where pending remained readable but delivered became unreadable after delivery, so this doesn’t address all observed failures. It is still valuable hardening. Increase scheduling frequency / reschedule closer to fire time (proposed/considered) We discussed adding a debug mode to always recreate the daily reminder during background refresh tasks (or only within N hours of fire time) to reduce the time window between attachment creation and delivery. Status: experimental; not yet confirmed to resolve the “pendingReadable=true → delivered unreadable after delivery” failure. Impact The primary UX value of the daily reminder is the preview photo; missing previews degrade core functionality. Failures are intermittent and appear dependent on OS attachment-store behavior and Notification Center actions (clearing notifications), making them difficult to mitigate fully app-side. Notes / Questions for Apple 1. Is iOS allowed to coalesce/deduplicate UNNotificationAttachment storage across notifications? If so, what is the retention model when delivered notifications are removed? 2. If a delivered notification still reports attachments=1, should its attachment-store URL remain valid/readable while the notification is still present in Notification Center? 3. In “next-day” one-shot scheduling scenarios, can the attachment-store blob be purged between scheduling and delivery (or immediately after delivery) even if the notification remains visible? 4. Is there a recommended pattern to ensure attachment previews remain stable for long-lived scheduled notifications (hours to a day), especially when using UNCalendarNotificationTrigger(repeats: false)? Minimal Code Pattern (simplified) 1. Generate JPEG (PhotoKit → UIImage → JPEG Data). 2. Write to a unique temp URL. 3. Create attachment: UNNotificationAttachment(identifier: <uuid>, url: <tempURL>, options: [UNNotificationAttachmentOptionsTypeHintKey: "public.jpeg"]) 4. Schedule notification with a calendar trigger for the next morning.

Scenario: User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue: Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

Approx Dec 13th 2025 til now (Dec 29th) I noticed my APNS dropped off to nothing daily. When I try to send APNS alerts on the developer site tool it always returns "discarded as device was offline" for multiple devices which I know are online. When I try pushing through my VPS (as I always have without any code changes for months) I get status codes of 400 and 403 mostly and a few 200's without it delivering also. I created a new sandbox certificate just in case it was that but still no luck, I get the same results. Ive checked for any firewall issues and I see the following on my VPS: nslookup gateway.push.apple.com Server: 1.1.1.1 Address: 1.1.1.1#53 ** server can't find gateway.push.apple.com: NXDOMAIN This seems like a second issue but not the primary issue that the portal is reporting. Any ideas what to check? Im at a loss as to why its not working at all through apples test notification portal on my developer account. It seems thats the initial issue I need to solve. Thank you for any ideas/help

I am using UNCalendarNotificationTrigger and from my initial tests with simulator and timezone changes in my mac i see that notification donot get triggered at specific times if timezone changes, is this expected behaviour ?

I have used the Push Notifications Console and verify that the test notification reaches my device (it says "not necessarily the app"). However, GameCenter notifications are not reaching the app. When one device passes the turn, the turn is successfully passed as seen in the Matchmaker VC. However, the app does not get the turn pass notification whether or not it is running. No banner appears if the app is not running (but it does when using the Push Notifications Console). Please advise.

Hi, We have a simple calendar reminder app that uses UNNotificationRequest to schedule local notifications for user events. I’m wondering whether UNNotificationRequest has a system-imposed limit of 64 upcoming scheduled notifications, similar to the deprecated UILocalNotification. We’re asking because one of our users is not receiving recently scheduled reminders. Our current workflow is: We schedule notifications on app launch and when the app is about to quit. Before scheduling, we call removeAllPendingNotificationRequests(). We then fetch the 64 nearest upcoming events and schedule them using UNUserNotificationCenter.current().add(...). This approach works fine during our testing, but we’re unsure what might be causing the issue for some users. Any insights would be appreciated. Thanks!

I am currently testing the Declared Age Range / Parental Consent flow in the Sandbox environment, and I am experiencing an issue where the RESCIND_CONSENT App Store Server Notification is not being delivered to my server. 🔍 Test Environment iOS version: iOS 26.2 (Sandbox environment) App Store Server Notifications: Sandbox environment 🔄 Test Scenario App Settings > Developer > Sign in with a Sandbox account Launch the app In App Settings > Developer > Sandbox Account > Management > Revoke App Consent, enter the app’s Bundle ID, tap the Revoke Consent button, and confirm that the revocation completion popup message is displayed Check whether App Store Server Notifications are received by the server Confirm that the RESCIND_CONSENT notification is not received by the server ✅ Expected Result The App Store Server sends a RESCIND_CONSENT notification to the Sandbox endpoint The notification payload includes appTransactionId The server can block app access based on the corresponding appTransactionId ❌ Actual Result No RESCIND_CONSENT notification is received in the Sandbox environment ❓ Questions Is this behavior an intended limitation of the Sandbox environment, or is it a known issue or bug? Is it possible that RESCIND_CONSENT notifications will only be delivered starting January 1, 2026? Additionally, when a RESCIND_CONSENT server notification is received, I currently update my database with the appTransactionId and the registration date. When a minor attempts to access the app, I check the latest appTransactionId status, and if the most recent state indicates consent has been revoked, I block app access and prompt the user to request parental consent again using PermissionKit.

Currently, I have implemented local cache update with server data when app is killed using Push Notification and Notification Service Extension. So it works even the app is killed by the user, but I wanted to know whether this is app review safe work around or not as I am not finding any documentation for 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") } } } } }

Hello, I recently had an unusual experience, and I’m wondering if this is related to Apple’s policies, so I wanted to ask. While a call is in Picture-in-Picture (PIP) mode, notification pushes from the same app do not appear. The API is being triggered, but the notification banner does not show on the device. Once PIP is closed, the notifications start appearing normally again. Is this behavior enforced by Apple’s policies? What’s interesting is that banners from other apps do appear — only the banners from the app currently in PIP are not shown.

We are implementing a camera intercom calling feature using VoIP Push notifications (PushKit) and LiveCommunicationKit (iOS 17.4+). The app works correctly when running in foreground or background, but fails when the app is completely terminated (killed by user or system). After accepting the call from the system call UI, the app launches but gets stuck on the launch screen and cannot navigate to our custom intercom interface. Environment iOS Version: iOS 17.4+ (testing on latest iOS versions) Xcode Version: Latest version Device: iPhone (tested on multiple devices) Programming Languages: Objective-C + Swift (mixed project) Frameworks Used: PushKit, LiveCommunicationKit (iOS 17.4+) App State When Issue Occurs: Completely terminated/killed Problem Description Expected vs Actual Behavior App State Behavior Foreground ✅ VoIP push → System call UI → User accepts → Navigate to intercom → Works Background ✅ VoIP push → System call UI → User accepts → Navigate to intercom → Works Terminated ❌ VoIP push → System call UI → User accepts → App launches but stuck on splash screen → Cannot navigate Root Issues When app is terminated and user accepts the call: Data Loss: pendingNotificationData stored in memory is lost when app is killed and relaunched Timing Issue: conversationManager(_:perform:) delegate method is called before homeViewController is initialized Lifecycle Confusion: App initialization sequence when launched from terminated state via VoIP push is unclear Code Flow VoIP Push Received (app terminated): func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { let notificationDict = NotificationDataDecode.dataDecode(payloadDict) as? [AnyHashable: Any] let isAppActive = UIApplication.shared.applicationState == .active // Store in memory (PROBLEM: lost when app is killed) pendingNotificationData = isAppActive ? nil : notificationDict if !isAppActive { // Report to LCK try await conversationManager.reportNewIncomingConversation(uuid: uuid, update: update) } completion() } User Accepts Call: func conversationManager(_ manager: ConversationManager, perform action: ConversationAction) { if let joinAction = action as? JoinConversationAction { // PROBLEM: pendingNotificationData is nil (lost) // PROBLEM: homeViewController might not be initialized yet if let pendingData = pendingNotificationData { ModelManager.share().homeViewController.gotoCallNotificationView(pendingData) } joinAction.fulfill(dateConnected: Date()) } } Note: When user taps "Accept" on system UI, LiveCommunicationKit calls conversationManager(_:perform:) delegate method, NOT a manual acceptCall method. Questions for Apple Support App Lifecycle: When VoIP push is received and app is terminated, what is the exact lifecycle? Does app launch in background first, then transition to foreground when user accepts? What is the timing of application:didFinishLaunchingWithOptions: vs pushRegistry:didReceiveIncomingPushWith: vs conversationManager(_:perform:)? State Persistence: What is the recommended way to persist VoIP push data when app is terminated? Should we use UserDefaults, NSKeyedArchiver, or another mechanism? Is there a recommended pattern for this scenario? Initialization Timing: When conversationManager(_:perform:) is called with JoinConversationAction after app launch from terminated state, what is the timing relative to app initialization? Is homeViewController guaranteed to be ready, or should we implement a waiting/retry mechanism? Navigation Pattern: What is the recommended way to navigate to a specific view controller when app is launched from terminated state? Should we: Handle it in application:didFinishLaunchingWithOptions: with launch options? Handle it in conversationManager(_:perform:) delegate method? Use a notification/observer pattern to wait for initialization? Completion Handler: In pushRegistry:didReceiveIncomingPushWith, we call completion() immediately after starting async reportNewIncomingConversation task. Is this correct, or should we wait for the task to complete when app is terminated? Best Practices: Is there a recommended pattern or sample code for integrating LiveCommunicationKit with VoIP push when app is terminated? What are the best practices for handling app state persistence and navigation in this scenario? Attempted Solutions Storing pendingNotificationData in memory → Failed: Data lost when app is killed Checking UIApplication.shared.applicationState → Failed: Doesn't reflect true state during launch Calling gotoCallNotificationView in conversationManager(_:perform:) → Failed: homeViewController not ready Additional Information Singleton pattern: LCKCallManagerSwift, ModelManager homeViewController accessed via ModelManager.share().homeViewController Mixed Objective-C and Swift architecture conversationManager(_:perform:) is called synchronously and must call joinAction.fulfill() or joinAction.fail() Requested Help We need guidance on: Correct app lifecycle handling when VoIP push is received in terminated state How to persist VoIP push data across app launches How to ensure app initialization is complete before navigating Best practices for integrating LiveCommunicationKit with VoIP push when app is terminated Thank you for your assistance!

We are facing an issue: push notifications are not being received. We are using the Marketing Cloud SDK for push notifications. On install, the app correctly registers for push notifications. We pass the required information to Marketing Cloud — for example, contact key, token, etc. Marketing Cloud also confirms that the configuration is set up, and we have tried sending push notifications with proper delivery settings. The issue is that after some time, the device gets automatically opted out in the Marketing Cloud portal. When we consulted their team, they said this is caused by the “DeviceTokenNotForTopic” error received from APNs. I have verified the certificates and bundle ID from my end — everything looks correct. Device: iPhone 15, iPhone 17 iOS: 18.7.2, 26.1

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.

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

Provisioning profiles created for my App ID are not including the Push Notifications capability, even though Push Notifications is enabled in the App ID configuration in Apple Developer Portal. I have enabled Push Notifications for my App ID (com.abc.app) in the Apple Developer Portal. The capability shows as enabled and saved. However, when provisioning profiles are generated (either manually or through third-party tools like Expo Application Services), they do not include: The Push Notifications capability The aps-environment entitlement This results in build failures with the following errors: Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't support the Push Notifications capability. Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't include the aps-environment entitlement. Steps Taken ✅ Enabled Push Notifications in App ID configuration (com.mirova.app) ✅ Saved the App ID configuration multiple times ✅ Waited for Apple's systems to sync (waited 5-10 minutes) ✅ Removed and re-added Push Notifications capability (unchecked, saved, re-checked, saved) ✅ Created Push Notification key in Apple Developer Portal ✅ Verified Push Notifications is checked and saved in App ID ❌ Provisioning profiles still created without Push Notifications capability Expected Behavior When Push Notifications is enabled for an App ID, any provisioning profiles created for that App ID should automatically include: Push Notifications capability aps-environment entitlement (set to production or development) Actual Behavior Provisioning profiles are created without Push Notifications capability, even though: Push Notifications is enabled in App ID App ID configuration is saved Sufficient time has passed for sync Additional Information Push Notification Key: Created and valid (Key ID: 3YKQ7XLG9L and 747G8W2J68) Distribution Certificate: Valid and active Provisioning Profile Type: App Store distribution Third-party Tool: Using Expo Application Services (EAS) for builds, but issue persists with manually created profiles as well Questions Is there a delay or sync issue between enabling Push Notifications in App ID and it being available for provisioning profiles? Are there any additional steps required to ensure Push Notifications is included in provisioning profiles? Is there a known issue with Push Notifications capability not being included in provisioning profiles? Should I create the provisioning profile in a specific way to ensure Push Notifications is included? Environment Platform: iOS Build Type: App Store distribution Xcode Version: (via EAS cloud build) Thank you for your assistance. I've been unable to resolve this issue and would appreciate any guidance. iOS Deployment Target: Latest

We are in the process of preparing our app to support the new Texas law (SB2420) that takes effect 1/1/2026. After reviewing Apple's recent announcements​/docs concerning this subject, one thing isn't clear to me: how to associate an app install with a​n App Store Server RESCIND_CONSENT notification​ that could be delivered to our server. Our app is totally free so there isn't an originalTransactionId​ or other similar transaction IDs that would be generated as part of an in-app purchase (and then subsequently sent as part of the payload in the notification to our server during an in-app purchase scenario). So my question is: How do I associate an app (free app) install with an App Store Server RESCIND_CONSENT notification​ that is sent to our server​?