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?

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.