Summary: After converting our Apple Developer account from Individual → Organization, our app stopped receiving APNs device tokens. application(:didRegisterForRemoteNotificationsWithDeviceToken:) is never called, and application(:didFailToRegisterForRemoteNotificationsWithError:) is also never called — no token, no error. This affects all new device‑token registrations app‑wide; device tokens issued before the conversion still work and continue to deliver pushes. Environment Membership status: Active Device: iPhone 15 Pro, iOS [26.6] Reproduced on both development (sandbox) builds installed via Xcode/CLI and TestFlight builds. What works Existing device tokens (created before ~Aug 1) still deliver pushes normally (server reports delivered 1/1 via our .p8 token‑based auth). So the send path and APNs auth key are fine. UNUserNotificationCenter authorization succeeds — authorizationStatus == .authorized. UIApplication.shared.isRegisteredForRemoteNotifications == true. What doesn't work We call UIApplication.shared.registerForRemoteNotifications() on the main thread after authorization is granted, but neither delegate callback ever fires — no token, no error — on any new install/launch. Timeline / trigger Everything worked before the Individual→Organization conversion. Since the conversion, no new APNs device token has been issued for the app at all. Server‑side we can confirm the most recent device token was created 2026‑08‑01, and none since, despite many fresh installs/launches across multiple users. Pre‑conversion tokens still function. What we've already tried / ruled out App ID has Push Notifications capability enabled; regenerated provisioning profiles. Generated a new APNs Auth Key (.p8) (sends already work, so this was expected not to matter). Fixed the Xcode signing team (it briefly showed "Unknown Name (TEAMID)" right after conversion; resolved by signing into the correct org account — Team now resolves correctly). Device reboot, network settings reset, app delete/reinstall, latest iOS. Confirmed delegate is wired (@UIApplicationDelegateAdaptor) — the same code issued tokens fine before the conversion. Thanks in advance!

We're experiencing an issue where push notifications are not being received on certain iOS devices, and we'd like help identifying the possible causes. What we've confirmed so far: Push notifications are sent from our own provider server to APNs. APNs returns a normal response (HTTP/2 200) The device tokens are valid and up to date. Affected users have confirmed that notifications are enabled for our app in Settings. Users report no network connectivity issues. We are sending with apns-priority: 10 and apns-push-type: alert. Scope: This is occurring for multiple users, not isolated to a single device. It happens intermittently — some notifications from the same campaign reach the device, while others don't. Critically, some affected users report that they only fail to receive notifications from our app during certain specific time windows, while notifications from other apps arrive normally during the same period. This suggests the issue is app-specific and time-correlated, rather than a device-wide or network-level problem. Questions we'd like help with: Given that APNs returns 200, are there known scenarios where the notification still doesn't reach the device? (e.g., Focus / Do Not Disturb, low power mode, high-frequency throttling, stored-then-discarded due to apns-expiration) Is there a recommended way to obtain per-notification delivery status in the production environment? Are there known limits on how many notifications can be sent to the same device within a short window before APNs starts throttling or coalescing them? Our server logs currently do not retain the apns-id returned by APNs. If we provide the affected device tokens along with the approximate send timestamps, would it be possible for Apple to help investigate the delivery status of those notifications on the APNs side? Any guidance or pointers to relevant documentation would be greatly appreciated. Thank you!

What I found during the development: The Apple phone has registered the device token and it is within the validity period, but it cannot receive the apns message. However, only after I re-registered the device token with this token could this iPhone receive apns push notifications normally... What's going on here? How can it be optimized?

Beginning July 29, 2026, we noticed a higher number of error responses from api.sandbox.push.apple.com: http2: server sent GOAWAY and closed the connection; LastStreamID=2147483647; ErrCode=PROTOCOL_ERROR; debug="Stream 3 does not exist for inbound frame DATA, endOfStream = true" The errors: Occur across multiple independent applications and regions. Are concentrated on the APNs sandbox endpoint. Did not coincide with a deployment or configuration change in our service. Were not accompanied by other typical failures such as 400 BadDeviceToken. Also increased on the APNs production endpoint, though the large majority remain concentrated on the sandbox endpoint. Could Apple confirm whether APNs recently changed how notification requests are validated or rejected, particularly in the sandbox environment? We can provide exact UTC timestamps, source regions, request metadata, and logs privately if needed.

Beginning July 29, 2026, we observe communication erros while sending push notifications to https://api.push.apple.com like: Error in the HTTP2 framing layer Send failure: Connection reset by peer Also we ran tcpdump which clearly indicates that TCP RESET packets are coming from various APNS IP like 17.188.x.x. Errors mostly occure during traffic peak but also outside. We also did a test from different datacenter in other country and which resulted a same issue

We're investigating an edge case around push/local notification handling on macOS when multiple instances of the same app are running simultaneously, launched via open -n /path/to/App.app. We're aware this isn't the standard/expected usage pattern for macOS apps, which are singleton by default, but we need to understand and correctly handle this case, so any clarity here would help. Setup: macOS app, AppKit, using NSApplicationDelegate and UNUserNotificationCenterDelegate. Two separate processes of the same app launched via open -n, each independently calling UNUserNotificationCenter.current().delegate = self and registerForRemoteNotifications() on launch. Questions: Device token : is the device token unique per device and app installation, or could two separately-running processes of the same installed app each be issued a different token? Our understanding from Apple's documentation is that the token identifies the app and device combination, not a specific process. Can you confirm this holds even in a multi-instance scenario? Notification tap routing : when a notification, local or remote, is tapped and both process instances have independently registered a UNUserNotificationCenterDelegate, which instance's delegate receives userNotificationCenter didReceive withCompletionHandler? Is this deterministic, for example the most recently registered instance, or the one most recently connected to usernoted? Is it arbitrary or undefined? Or does the system only allow one instance's delegate connection to be active at a time, silently disconnecting the other? Is there any documented or recommended way for an app to detect it's running as a secondary instance launched via open -n, and adjust its notification handling behavior accordingly, if relevant? We understand this falls outside the normal supported usage pattern for macOS apps, but since the behavior isn't documented for this scenario, any insight, even confirming this is undefined behavior, would be genuinely useful for us to plan around.

It's been 2+ months now since I've submitted an entitlement request for the Notification Service Filtering Entitlement (NSE). I have a mobile app that I transferred from a previous developer account due to business reorganization and the previous account had this entitlement. However, after transferring the app, I am unable to push any updates to the app on iOS because the new developer account does not have the same entitlement. Everything outside of the developer account that the app is associated to remains the same - same workflow, same audience, same app use cases, etc.. However, we still have not had any progress on receiving the entitlement even after multiple escalations and follow-ups with the Apple Developer Support team. I am curious to know if any others within the Developer Community have requested this specific entitlement before and what your experience has been with it? Any advice on how I can expedite the approval for the entitlement? Otherwise our app continues to go stale on the iOS app store.

Updated with FB24122131. Here's the ready-to-paste forum post: Title: registerForRemoteNotifications() never completes (no success, no error callback) since July 3 — App Store Connect metrics confirm same cutoff Body: Posting in case anyone else has hit this — happy to compare notes, and I've also filed FB24122131 with Apple directly. Since ~July 3, 2026, our app (MyRoost, iOS) has been completely unable to register for remote notifications. registerForRemoteNotifications() is called at launch, but neither didRegisterForRemoteNotificationsWithDeviceToken: nor didFailToRegisterForRemoteNotificationsWithError: ever fires. No token, no error — just silence, indefinitely. This isn't a new-integration bug — the same code worked fine through July 2. What's interesting is that App Store Connect's own "Push Notifications → Overview" dashboard for our app independently shows notifications received by APNs dropping from ~20/day to flat zero starting exactly July 3, matching our own logs precisely. We've ruled out essentially everything on our side: Push Notifications capability + entitlements (independently verified present in the actual signed binary, not just source, via a CI step that dumps the compiled .ipa's Info.plist and codesign entitlements) Firebase/APNs Authentication Key configuration OS-level notification permission (confirmed granted) MDM/configuration profiles (none), Screen Time restrictions (none) Wi-Fi vs. cellular (identical failure on both) Full device reboot, clean reinstall, account logout/login Reproduced identically on two separate physical devices (iPhone 17 Pro, iOS 26.5.2; iPad A16, iPadOS 26.5.2) Added native diagnostic logging to capture the raw error from didFailToRegisterForRemoteNotificationsWithError: directly — confirms the native callback itself never fires, not just that we're failing to observe it Filed an Apple Developer Support case (102936910825) on July 8 — after investigation, closed 2026-07-30 as "outside scope" and redirected here / to Feedback Assistant. Has anyone else seen a total, silent APNs registration failure like this, starting around the same early-July timeframe? Any workaround, or confirmation this is a known platform-side issue, would be hugely appreciated.

Across two completely separate App IDs under the same Apple Developer Team, calling registerForRemoteNotifications() (via a standard push-notification plugin wrapping this exact API) resolves successfully — but afterward neither application(:didRegisterForRemoteNotificationsWithDeviceToken:) nor application(:didFailToRegisterForRemoteNotificationsWithError:) is ever called. No token, no error. Registration just stalls permanently. Environment Xcode 26.4.1 Distribution: TestFlight (App Store distribution profile → production APNs environment) iOS on all test devices: current release The key finding This isn't specific to one app. I reproduced the identical failure on: Our primary app's App ID, which has existed for a while and had Push Notifications enabled after initial creation. A brand-new, throwaway App ID created from scratch specifically to test this, with Push Notifications capability checked at creation time (no toggling after the fact, no history at all). Both show the exact same symptom: register() resolves, then silence — no callback of either kind, ever. Since this reproduces identically on an App ID with zero prior history, it rules out anything specific to one app's configuration or App Store Connect record, and points at something at the Team level with APNs backend authorization. What I've ruled out Entitlements/provisioning are correct and matching, verified via direct inspection of the signed binary: codesign -d --entitlements :- MyApp.app and the provisioning profile's own entitlements: security cms -D -i MyApp.app/embedded.mobileprovision | plutil -extract Entitlements xml1 -o - - Both show identical, correct values — aps-environment: production, correct application-identifier, correct team-identifier. Reproduced identically across: 2 separate App IDs (one long-standing, one brand new) 2 different physical iPhones 2 different WiFi networks 2 different accounts/user sessions within the app Already tried with no change in behavior: Enabling Push Notifications after initial App ID creation, vs. checking it at creation time on the fresh App ID Toggling the capability off/on and regenerating the provisioning profile Generating multiple fresh App Store distribution profiles Confirmed the Distribution certificate referenced is correct and valid Client code confirmed correct via instrumented logging at every step (permission check → permission request → listener attachment → register() call). Every step up to and including register() resolving completes exactly as expected. The stall is strictly after that point, entirely on the OS/APNs side. What I'm trying to determine Given this reproduces on a completely fresh App ID with no history, I believe this points at something about how APNs backend authorization is provisioned for this Developer Team as a whole, rather than any individual App ID's configuration. Has anyone seen this exact symptom — registration call succeeding but zero callback of either kind — and found a resolution that wasn't visible from anything in the Developer Portal or Xcode? Filed as Apple Developer Support case 20000117948923 — happy to share any additional diagnostics.

We are investigating a notification-reply issue with a BLE accessory on iOS 27 Beta 4, built with Xcode 26.5. Our app uses an Accessory Transport App Extension and an Accessory Data Provider Extension for notification forwarding and text replies. Expected behavior A text reply entered on the accessory should be delivered to the transport extension, forwarded to the data provider extension, and then submitted through the system notification response API. Observed behavior A messaging notification with a text-input Reply action is forwarded successfully to the accessory. If the user replies shortly after the notification arrives, the full path succeeds: the BLE reply payload is received by the transport extension, forwarded to the data provider extension, parsed, and the system notification response API succeeds. If the user waits about 1-2 minutes before replying, the reply fails. The original notification was forwarded successfully and BLE was ready. We see the accessory acknowledgement for notification delivery. Log evidence The successful path contains BLE receive, transport reassembly, a parsed Reply action with user text, and a successful notification response API call. In the delayed-reply case, after the background window expires the host app is reported as running-suspended. When the accessory reply is attempted, there is no new invocation of either extension and no incoming BLE reply payload in those extensions. Therefore no notification response API call is made. This does not appear to depend on screen state. The relevant difference is whether the accessory reply occurs before or after the background execution window ends. Question After an accessory notification has already been delivered, what is the supported mechanism for a delayed accessory text reply to wake or re-invoke the Accessory Transport App Extension and route the reply to the Accessory Data Provider Extension? Is this expected lifecycle behavior for these extensions on iOS 27 Beta 4, or is there an entitlement, configuration, or API requirement needed to support delayed replies? We can provide a sysdiagnose and a minimal reproduction timeline privately if needed.We are investigating a notification-reply issue with a BLE accessory on iOS 27 Beta 4, built with Xcode 26.5. Our app uses an Accessory Transport App Extension and an Accessory Data Provider Extension for notification forwarding and text replies. Expected behavior A text reply entered on the accessory should be delivered to the transport extension, forwarded to the data provider extension, and then submitted through the system notification response API. Observed behavior A messaging notification with a text-input Reply action is forwarded successfully to the accessory. If the user replies shortly after the notification arrives, the full path succeeds: the BLE reply payload is received by the transport extension, forwarded to the data provider extension, parsed, and the system notification response API succeeds. If the user waits about 1-2 minutes before replying, the reply fails. The original notification was forwarded successfully and BLE was ready. We see the accessory acknowledgement for notification delivery. Log evidence The successful path contains BLE receive, transport reassembly, a parsed Reply action with user text, and a successful notification response API call. In the delayed-reply case, after the background window expires the host app is reported as running-suspended. When the accessory reply is attempted, there is no new invocation of either extension and no incoming BLE reply payload in those extensions. Therefore no notification response API call is made. This does not appear to depend on screen state. The relevant difference is whether the accessory reply occurs before or after the background execution window ends. Question After an accessory notification has already been delivered, what is the supported mechanism for a delayed accessory text reply to wake or re-invoke the Accessory Transport App Extension and route the reply to the Accessory Data Provider Extension? Is this expected lifecycle behavior for these extensions on iOS 27 Beta 4, or is there an entitlement, configuration, or API requirement needed to support delayed replies? We can provide a sysdiagnose and a minimal reproduction timeline privately if needed.

I’m seeing what appears to be a regression in custom local-notification sounds on macOS 26.6. According to the UNNotificationSound documentation, a custom sound can be stored in the main application bundle and supplied using UNNotificationSound(named:). Environment: macOS 26.6 (25G72) Xcode 26.6 (17F113) Swift 6.3.3 Apple Silicon Sandboxed native macOS application Notification authorization granted Sounds enabled for the application in System Settings import AppKit import UserNotifications let center = UNUserNotificationCenter.current() let soundFilename = "notification_probe.aiff" guard Bundle.main.url( forResource: soundFilename, withExtension: nil ) != nil else { fatalError("Sound is missing from the application bundle") } let content = UNMutableNotificationContent() content.title = "Custom sound test" content.body = "This should play the bundled custom sound." content.sound = UNNotificationSound( named: UNNotificationSoundName(rawValue: soundFilename) ) // Ensure the application is inactive so macOS presents the notification. NSApp.hide(nil) try await Task.sleep(for: .milliseconds(250)) try await center.add( UNNotificationRequest( identifier: "custom_sound_test", content: content, trigger: nil ) ) The sound is correctly copied to: MyApp.app/Contents/Resources/notification_probe.aiff I tested two separate files: CAF and AIFF both files are shorter than 30 seconds and comply with the documented custom-sound requirements. Actual result: The notification is delivered and displayed correctly. macOS plays the default notification sound. The custom sound is not played. The unified log shows Notification Center receiving the correct custom filename, but ToneLibrary then rejects it: [com.apple.unc:sound] Playing notification sound { nam: notification_probe.aiff } for com.example.MyApp [com.apple.ToneLibrary:ToneManagement] Tone with identifier 'notification_probe.aiff' is neither in the collections for system or iTunes tones. Performed basic check for validity of tone with identifier 'notification_probe.aiff': NO. -toneWithIdentifierIsValid:(notification_probe.aiff): Returning NO. Immediately afterwards, SystemSoundServer plays the standard macOS notification sound. Immediately afterwards, SystemSoundServer plays the standard macOS notification sound At present, the only working solution is to submit a silent notification and play the sound independently through AudioToolbox, which loses the normal coupling between notification presentation and sound playback. Is this a bug or what ?

On the first connection after pairing, our accessory acts as an ANCS client over GATT over BR/EDR. After service discovery, we enable notifications by writing the CCCDs of both the Notification Source and Data Source characteristics. This succeeds, but the iPhone does not send notifications for existing unread notifications. It only sends Notification Source notifications for newly received notifications (for example, new instant messaging notifications), which is the behavior we expect. After disconnecting and reconnecting the BR/EDR connection, our accessory performs the same ANCS initialization sequence and enables the same CCCDs again. If there are a large number of unread notifications on the iPhone (approximately 30 or more), the iPhone immediately starts sending Notification Source notifications for many existing unread notifications. During this process, the GATT over BR/EDR connection becomes unresponsive. Our accessory sends an ATT Write Request to the ANCS Control Point characteristic to retrieve notification attributes. The iPhone HCI log shows that the Write Request is received by the iPhone, but no corresponding ATT Write Response is ever sent. About 30 seconds later, the iPhone disconnects the GATT over BR/EDR L2CAP channel. This issue is reproducible only when there are many unread notifications (approximately 30 or more). If there are only a few unread notifications, the problem does not occur. Expected Behavior The iPhone should continue processing ANCS requests normally regardless of the number of unread notifications. After receiving the ATT Write Request to the ANCS Control Point characteristic, it should return the corresponding ATT Write Response and continue sending Data Source notifications containing the requested notification attributes.

Summary On a physical iPhone, the app never receives an APNs device token (application:didRegisterForRemoteNotificationsWithDeviceToken: never fires, even after waiting 60 seconds after login and calling registerForRemoteNotifications). The symptom reproduces identically in two different apps (different bundle IDs, same Team), over both WiFi and cellular data, even after a full device restart. Other apps on the same device (WhatsApp, Gmail, etc.) receive push notifications normally. Account details Team ID: 6NJN39FM4A Program: Apple Developer Program (Individual), active through June 26, 2027, no pending payments or agreements Signing Apple ID: my developer Apple ID (account in good standing) Affected apps (same issue in both) com.movicolombia.driver com.movicolombia.passenger For both App IDs, in Certificates, Identifiers & Profiles, the Push Notifications capability is checked/enabled (Environment: Sandbox & Production, Key Restriction: Team Scoped). Test device Physical iPhone, iOS 26.5.2, installed directly via Xcode (flutter run --release, automatic signing, development provisioning profile — not TestFlight or App Store) Configuration already verified as correct Correctly signed entitlements: confirmed by inspecting the device system log at launch time — the embedded entitlement includes aps-environment: development and the correct application-identifier. Push Notifications capability added in Xcode (Signing & Capabilities) for both targets, with Automatically manage signing on, no signing/provisioning errors in the build. APNs authentication key (.p8) uploaded in Firebase Console → Cloud Messaging → Apple app configuration, applied to both the development and production rows. Notification permission granted by the user (confirmed in Settings). No active Content & Privacy Restrictions. No VPN or device management profiles installed. Active iCloud account on the device with the same development Apple ID. Troubleshooting already performed (all unsuccessful) Full app reinstall Full device restart Test over WiFi — getAPNSToken() nil after 60s Test over cellular data (WiFi off) — same result Full build cache wipe (flutter clean + deleting ~/Library/Developer/Xcode/DerivedData) and rebuild from scratch, to rule out a stale binary Test with a second app (different bundle ID) on the same device — same exact failure Technical detail After registerForRemoteNotifications is invoked (automatically, by the Firebase Messaging SDK on app launch), neither didRegisterForRemoteNotificationsWithDeviceToken: nor didFailToRegisterForRemoteNotificationsWithError: is ever called. As a result, FirebaseMessaging.getAPNSToken() (Flutter/FlutterFire) returns nil indefinitely, and getToken() throws: [firebase_messaging/apns-token-not-set] APNS token has not been set yet. Please ensure the APNS token is available by calling getAPNSToken(). I instrumented a polling loop calling getAPNSToken() every second for 60 seconds after login — across more than 10 test runs (WiFi, cellular, before/after device restart) it never returned a non-nil value. What I'm hoping to learn Whether there's something on Apple's side (APNs service state, account/ Team status, or this specific device) preventing this iPhone from completing push registration for apps signed with this Team ID — since I've ruled out every app-level, Xcode-level, and Firebase-level configuration issue I could think of.

I haven't touched the code for my app (AirCompare) for months but I'm seeing a new and surprising behavior with it in iOS 26.5.2. (It may have started before this without me noticing.) My app does some fetching of web data in the background and, when conditions are warranted, sends a local notification to get the user's attention. The weird thing is that now, even after quitting the app - by swiping it up to remove it from the carousel - I'm still getting notifications! I've tried toggling the iPhone's power and the behavior remains. This seems like potentially a very serious security issue, that an app can continue to run even after the user has killed it. I haven't tried un-installing the app. How can I ensure my app is fully "off" after the user kills it?

On iOS 18, my app’s badge sometimes remains visible after the app is opened, even though I reset it to zero. Has anyone seen this behavior with UNUserNotificationCenter, or is an additional update needed?

After opening the app, the notification badge sometimes stays visible even after setting applicationIconBadgeNumber to zero. Has anyone seen this behavior on iOS 18, or is there a more reliable way to clear it?

We are the publisher of an iOS application available on the App Store, published under our Apple Developer account. Our app is a B2B enterprise product where multiple independent enterprise server deployments — each operated by a separate customer organisation — send push notifications to their own end users through our single published app binary. To support this multi-tenant architecture, we have designed the following push notification setup: A single iOS app published under our Apple Developer Team A single APNs P8 authentication key generated from our Apple Developer account One Firebase project provisioned per customer organisation, each configured with the same P8 key and the same iOS bundle ID Each customer's Firebase project independently delivers push notifications only to device tokens registered by that customer's users At any point in time, a single device is registered with exactly one customer's Firebase project — there is no concurrent multi-Firebase registration on a single device We have technically validated that multiple Firebase projects sharing the same P8 key and bundle ID can each deliver push notifications to our app without conflict. APNs validates the JWT signed by the P8 key and the bundle ID claim, which is consistent across all projects. Our question is: Does this architecture — where multiple Firebase projects, all controlled by the app publisher or partners and provisioned with the same APNs P8 key and bundle ID, independently send push notifications to a single App Store app — comply with the Apple Developer Program License Agreement and Apple's APNs usage policies? We want to confirm this before proceeding to production and App Store submission to ensure we are fully compliant with Apple's guidelines? Multiple server will send push notifications to single app store app via each separate firebase account per server, will it violate any apple policy? Please let us know if any additional technical details would help clarify our setup.

I've had this identifier since 2019, but I can't receive push notifications—I keep getting the error: "no valid aps-environment entitlement string for application." I’ve already recreated the certificates and the provisioning profile, but nothing works. I don't know what else to do. Push notifications are enabled in the Capabilities section, yet when debugging, the console shows the error mentioned above, and the device doesn't receive the notification. Can anyone help me?

I'm running a PoC to validate remote push notification delivery on macOS (AppKit, no Storyboard, programmatic setup) using UNUserNotificationCenter. Environment: macOS Version 26.5 (25F71) Xcode Version 26.2 (17C52) App: sandboxed, entitlements include aps-environment: development, Push Notifications + Background Modes (Remote notifications) capabilities enabled Auth: token-based (.p8 key, ES256 JWT), sent via curl directly to api.sandbox.push.apple.com Setup: UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in if granted { NSApplication.shared.registerForRemoteNotifications() } } Delegate implements both: func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) and the legacy: func application(_ application: NSApplication, didReceiveRemoteNotification userInfo: [String: Any]) Repro steps: App launches, permission granted (true), device token successfully obtained via didRegisterForRemoteNotificationsWithDeviceToken Local notifications (via UNNotificationRequest + UNTimeIntervalNotificationTrigger) work correctly — banner displays, willPresent fires as expected Send a remote push via curl: curl -v --header "apns-topic: $TOPIC" --header "apns-push-type: alert" \ --header "authorization: bearer $AUTHENTICATION_TOKEN" \ --data '{"aps": {"alert": {"title": "Test Title","body": "Test Body"}}}' \ --http2 https://api.sandbox.push.apple.com/3/device/$DEVICE_TOKEN APNs responds HTTP/2 200 with a valid apns-id — accepted successfully Observed: No banner appears on screen Notification does not appear in Notification Center either Console log shows application(_:didReceiveRemoteNotification:) fired with the correct payload willPresent is never called for this remote push, despite firing correctly for local notifications in the same session Question: Given willPresent is documented to be the method responsible for foreground presentation decisions, and it's working correctly for local notifications, why would a remote alert-type push (with a proper alert dict, no content-available) route only through the legacy didReceiveRemoteNotification path and never reach willPresent/get displayed, despite a 200 response from APNs? One thing I noticed while investigating: the App ID used for this app (auto-created by Xcode's automatic signing) lists its Platform as "iOS, iPadOS, tvOS, watchOS, visionOS" only — macOS is not checked, even though the app itself is macOS-only and Push Notifications capability shows as enabled. Could this platform scoping on the App ID be responsible for APNs/the OS accepting the push at the network layer but not treating it as "alert-UI eligible" for display? Is macOS required to be explicitly checked as a platform on the App ID for willPresent to be invoked correctly, or is that unrelated? Any guidance on what determines whether a remote push is routed to the foreground presentation path vs. the legacy background delegate path on macOS would be appreciated.

I'm using UNNotificationSound.criticalSoundNamed with the Critical Alerts entitlement. I have two separate alarms that can each be active at the same time, each scheduling its own local notification on a repeating timer. Before switching to critical alerts, I played these with two AVAudioPlayer instances, and they overlapped fine. Now, using critical alert notifications instead, only one sound plays at a time — even when both are triggered around the same time. Is this expected? Does iOS only ever play one critical alert sound at a time per app (or system-wide), or is there a way to get two to play simultaneously?