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 ?

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!

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.

Hello Apple Developer Support Team, I am experiencing an issue with the CallKit framework on iOS where the CXCallObserver.calls property does not accurately reflect the active call status in real-time. The Issue: Even when there are no active CallKit calls (all calls have been hung up), accessing callObserver.calls still returns CXCall objects where hasEnded is false. This leads to false positives when we check: callObserver.calls.contains { !$0.hasEnded } Our Setup: We maintain a strong reference to CXCallObserver inside a singleton manager. We have assigned the CXCallObserverDelegate and it is receiving events. We noticed a significant delay (sometimes permanently on simulator/certain devices) between the call actually ending on the system level and the calls array being cleared. Questions: Is the CXCallObserver.calls array designed to be an asynchronous snapshot, or should it guarantee real-time consistency with the actual system call state? Is this a known caching issue with callservicesd where ended calls are not immediately deallocated from the observer’s calls array? What is the recommended best practice for determining if there is an active call on the device without relying on the potentially stale callObserver.calls property? Thank you for your support, and I look forward to your guidance. Best regards,

I'm migrating my Push-to-Talk app from the old VoIP-push approach (PushKit PKPushTypeVoIP) to the PushToTalk framework (iOS 16+), sending apns-push-type: pushtotalk notifications with the .voip-ptt topic. My app currently has these entitlements from the old implementation: com.apple.developer.pushkit.unrestricted-voip com.apple.developer.pushkit.unrestricted-voip.ptt And I've now added: com.apple.developer.push-to-talk My questions: When migrating to the PushToTalk framework, is it mandatory to update the App ID and remove the unrestricted-voip and unrestricted-voip.ptt entitlements? Or can the new push-to-talk entitlement coexist with them? Can I submit an app update that uses only PushToTalk notifications (no VoIP pushes), while the App ID / provisioning profile still has the voip and voip-ptt entitlements enabled? Will this pass App Review, or does the presence of the old entitlements cause issues? I currently see the runtime warning "Your app must be updated to use the Push to Talk framework" — is this triggered specifically by the presence of the unrestricted-voip.ptt entitlement, and will removing it resolve the warning? Thanks in advance.

Hi everyone, We have an iOS app that is currently live on the App Store under Company 1's Apple Developer account, and we are planning to transfer it to Company 2's Apple Developer account using Apple's App Transfer process. Our current push notification setup is as follows: Push notifications are sent using Firebase Cloud Messaging (FCM). Firebase is configured with an APNs Authentication Key (.p8) generated from Company 1's Apple Developer account. The app uses the same Bundle ID before and after the transfer. We would like to understand the expected behavior after the app transfer. Our questions are: Will users who already have the app installed continue to receive push notifications after the app has been transferred? Once the app is owned by Company 2, will the APNs Authentication Key from Company 1 continue to work, or must it be replaced immediately with a new key generated from Company 2's Apple Developer account? Is there any supported way to configure APNs so that both the old and new APNs Authentication Keys can be used during the migration period, allowing push notifications to be delivered seamlessly to all users? 3)If simultaneous APNs keys are not supported, what is the recommended migration strategy to avoid any interruption in push notification delivery during the transfer? Our goal is to ensure that existing users continue receiving push notifications without disruption while we complete the App Store transfer. Any guidance or best practices from Apple or developers who have gone through a similar migration would be greatly appreciated. Thank you!

My app produces local notification but unfortunately they only play a sound but do not produce an alert. Of course I requested authorization with: let center = UNUserNotificationCenter.current() center.requestAuthorization(options: [.alert, .sound]) {(granted, error) in // Enable or disable features based on authorization. } And scheduled the notification with: func localNotification(_ title:String, message:String, sound:UNNotificationSound?, badge:Int?, interval:TimeInterval, userInfo: [AnyHashable : Any]?, category:UNNotificationCategory?=nil){ let content = UNMutableNotificationContent() content.title = NSString.localizedUserNotificationString(forKey: title, arguments: nil) content.body = NSString.localizedUserNotificationString(forKey: message, arguments: nil) content.sound=sound let ti = NSInteger(interval) let seconds = ti % 60 let minutes = (ti / 60) % 60 let hours = (ti / 3600) //let ms = Int((interval.truncatingRemainder(dividingBy: 1)) * 1000) var dateInfo = DateComponents() dateInfo.hour=hours dateInfo.minute=minutes dateInfo.second=seconds let trigger = UNCalendarNotificationTrigger(dateMatching: dateInfo, repeats: false) let request = UNNotificationRequest(identifier: "EndOfMeditation", content: content, trigger: trigger) let center = UNUserNotificationCenter.current() center.delegate = self center.add(request) { (error : Error?) in if let theError = error { print(theError.localizedDescription) } } } and have no queue about to know better.

I used the following class to post local notifications: class LocalNotification: NSObject, UNUserNotificationCenterDelegate{ func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification) async -> UNNotificationPresentationOptions{ print("torna notification") return [.sound, .badge, .banner] } func localNotification(_ title:String, message:String, sound:UNNotificationSound?, badge:Int?, interval:TimeInterval, userInfo: [AnyHashable : Any]?, category:UNNotificationCategory?=nil){ let content = UNMutableNotificationContent() content.title = NSString.localizedUserNotificationString(forKey: title, arguments: nil) content.body = NSString.localizedUserNotificationString(forKey: message, arguments: nil) content.sound=sound let ti = interval * 60 let seconds = ti.second let minutes = ti.minute let hours = ti.hour //let ms = Int((interval.truncatingRemainder(dividingBy: 1)) * 1000) var dateInfo = DateComponents() dateInfo.hour=hours dateInfo.minute=minutes dateInfo.second=seconds let trigger = UNCalendarNotificationTrigger(dateMatching: dateInfo, repeats: false) let request = UNNotificationRequest(identifier: message, content: content, trigger: trigger) let center = UNUserNotificationCenter.current() center.delegate = self center.add(request) { (error : Error?) in if let theError = error { print(theError.localizedDescription) } } } } But still function: UNUserNotificationCenterDelegate{ func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification) async is never called and more importantly no notification is delivered, either sound or banner.

Hello, I am implementing background processing using Silent Push Notifications in an iOS application. The app needs to receive requests from a server and execute processing in the background. For this purpose, I am using Silent Push Notifications to wake up the application. However, the application is not being launched as expected when running the TestFlight version. I would appreciate any guidance regarding this behavior. Environment Xcode 26.3 iOS 18.6 TestFlight distribution Push Notifications capability enabled Background Modes enabled Remote notifications enabled APNs Authentication Key (.p8) APNs Production environment Background Previously, the application periodically connected to a server in the background and sent location information when requested by the server. Since that background processing no longer behaves as expected, I started implementing an alternative approach using Silent Push Notifications. When running the application directly from Xcode in Debug mode, Silent Push works correctly and the app is launched in the background. However, when using the TestFlight build on the same device, the behavior differs and the app is not launched in the background. Observed Behavior The APNs request appears to be successful: APNs response status is HTTP 200 Using the device token obtained from the TestFlight build Alert Push notifications are received successfully application:didReceiveRemoteNotification:fetchCompletionHandler: is called when the app is in the foreground The same method is not called when the app is in the background Silent Push payload: { "aps": { "content-available": 1 } } HTTP/2 headers: apns-push-type: background apns-priority: 5 Verified Items Production device token is being used APNs topic matches the application's bundle identifier Alert Push notifications work correctly Background App Refresh is enabled on the device The application has not been force-quit completionHandler is always called after processing completes Console Logs The following logs appear when the push is sent: Submitted: com.apple.pushLaunch.jp.co.comp.MyApp.ext.mdm Application Policy response: {100, 0.00, [{[pushDisallowed]: Required:0.00, Observed:1.00},]} Decision: AMNP I also see: Insufficient history window for deviceActivityLikelihood stream deviceActivityLikelihood returned a nil timeline Questions Under what conditions are pushDisallowed and Decision: AMNP generated? What factors can cause iOS to reject a background launch triggered by a Silent Push Notification? Since Alert Push notifications are received successfully, is it reasonable to conclude that APNs configuration, topic configuration, and device token usage are correct? Are there any specific settings, entitlements, or implementation details that should be reviewed to resolve the pushDisallowed condition? The behavior differs between the Debug build launched from Xcode and the TestFlight build running on the same device. Are there any restrictions, policies, or differences applied to TestFlight builds that could explain this behavior? If the observed behavior is expected by design, what would Apple recommend as the appropriate architecture or API for server-triggered background processing in this scenario? Thank you for your time and assistance.

Push notifications are never delivered to my iOS app and I've exhausted the usual checks. Bundle: com.thomasmanfredini.lafrench, Team 7TWV3839F3, TestFlight (production). Architecture: Firebase Cloud Messaging (the app registers an FCM token; Firebase relays to APNs). Key symptom: a direct FCM test message (Firebase Console → "Send test message") to a valid registration token delivers nothing (app killed, lock screen). Already verified (all correct): notification permission ON (incl. Lock Screen); TestFlight build with aps-environment=production; GoogleService-Info.plist matches the Firebase iOS app (project la-french, sender 649219813428); FCM token generated and valid; APNs Auth Key in Firebase with correct Key ID + Team ID — tried two keys (one Production, one Sandbox & Production), neither delivers; bundle ID matches the APNs topic. Since even a direct FCM test fails with a valid token and correct config, what could prevent APNs from delivering to this app? What should I check next (account-level APNs, Push Notifications capability on the App ID, etc.)? Thanks!

Hello, We have an assessment application that placing the device into Education Assessment Mode (also referred to as Single App Mode) to provide a secure exam environment. On our test devices, Education Assessment Mode behaves as expected. While an assessment session is active, we have verified that third-party notifications (such as WhatsApp and Snapchat) do not appear. However, one of our customers recently reported that during an active exam, a Snapchat notification was displayed while the device was still in Education Assessment Mode. We have been unable to reproduce this behavior on any of our test devices, even after repeated testing with the same application. Has anyone experienced similar behavior with education assessment mode? Specifically: Can there be any scenario where third-party notification banners are shown while an assessment session is active? Are there any known edge cases or system conditions that could allow notifications to appear during Education Assessment Mode? Is there any way to verify from the application that the assessment session is still fully enforced by the system? We're also interested in knowing whether Apple is aware of any issues related to notification suppression while an education assessment mode is active. Any insights would be greatly appreciated. Thank you.