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.

iOS 27 I can not clear this 1 on my iPad Pro. even after the latest update it still shows 1 unread.

When scheduling a local notification, it can be delayed by up to 5 seconds. On iOS 26, the notification appears instantly at the scheduled time. Feedback ID: FB23218437

We’re planning a migration from App Store Server Notifications V1 to V2 and are reviewing our rollback strategy before enabling V2 in production. While researching, we found TN3180: TN3180: Reverting to App Store Server Notifications V1 | Apple Developer Documentation The technote appears to describe reverting App Store Server Notifications from V2 back to V1 using the Modify an App endpoint. Before proceeding, we’d like to clarify a few points: Is V2 → V1 rollback via the Modify App endpoint fully supported for production applications? If an application is reverted from V2 back to V1, can it later be migrated back to V2 again? During a rollback, should developers expect any overlap period where both V1 and V2 notifications may be delivered due to retries or notifications already in flight? Our goal is to understand whether the V2 → V1 capability should be treated as a fully supported operational rollback mechanism or as an emergency recovery path intended only for exceptional situations. Thank you for any clarification.

Hi Team We are building a live activity feature for our app. While using the APNS broadcast API (https://api.push.apple.com:443/4/broadcasts/apps/), we are getting throttled. The updates are infrequent (sport games) and yet we are facing this issue. Our understanding was that the throughput is quite high but there is no documentation on the actual limitations. Furthermore, all of our updates are using a priority of 5. We have currently configured retry with exponential backoff and jitter but we would like to understand the APNS throttle limit for live activity broadcast. Is the limit per channel id or at API level? What is the hard limit for the API request per seconds? Can we request increase to the API rate limit?

When attached app to debugger with real device, the OS seems to kill the app if the Callkit interface isn't emitted by the app at background within 5s. Do you have any tip in debugging?

"The introduction of team-scoped keys is a fantastic step forward for tightening security and isolating responsibilities within larger development organizations. However, as infrastructure moves closer to Zero Trust architectures, managing these keys across decentralized microservices or CI/CD pipelines still presents challenges. I have two questions regarding the long-term roadmap for APNs authentication: 1 App-Level Scoping: Are there plans to allow authentication keys to be scoped down to specific App IDs (Bundle IDs) rather than the entire team? Currently, a compromised team-scoped key could still potentially impact other apps within the same developer account. 2 Short-lived / Ephemeral Tokens: Is Apple considering support for short-lived, dynamically generated authentication tokens (similar to AWS IAM roles or OAuth 2.0 client credentials with expiration) to eliminate the need for storing long-lived ⁠.p8⁠ master keys on third-party backend servers? Understanding the direction of APNs security would greatly help us architect our next-generation notification backend."

Years ago a notification evangelist had recommended supporting NotificationContentExtension and NotificationServiceExtension. Fast forward to notification AI summaries, live activities, and lock screen widgets, iPhone mirroring, and all the others I'm missing, are there any other features developers should be utilizing when building out a notification strategy? Conversely, are there things to look out for if we DON'T adopt something as a negative? For context, the notifications might be general all audience, as well as, direct to user with custom content.

When updating Notifications, is it best practice to delete and reset all of them, or just delete and reset the Notifications that need to change? We have data coming from multiple sources, and as a result, we are often updating the notifications. This can be several times in under 10 seconds.

We have an emergency alert app that can trigger alarms in the event of a potential accident. We currently use Critical Alerts, which works well when the app is suspended or running in the background. A key requirement is that the alarm continues playing until the user explicitly acknowledges or dismisses it, as nearby people may need to notice the alarm and assist. Today, we’re achieving this by scheduling multiple Critical Alert notifications with the maximum sound duration (30 seconds) to create a longer continuous alarm. While this mostly works, it feels like a workaround and isn’t fully reliable. Is there a recommended way to implement a persistent emergency alarm experience on iOS? Would AlarmKit be an appropriate solution for this use case, or is it intended only for user-scheduled alarms and timers? Are there any other APIs or patterns you would recommend?