Hello guys, We have updated our app icon, and it is correctly reflected in our app build and assets. However, the push notification icon is still displaying the old version for some users. ✅ We have verified that: All icon assets in Assets.xcassets match the new icon. The app icon has been updated in Info.plist. The app has been resubmitted and approved on the App Store. ❌ However, some users still see the old notification icon, even after reinstalling the app. Restarting the device does not always resolve the issue. Could you provide insights into how iOS caches notification icons and how we can force a refresh for all users?

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!

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

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

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

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

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

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

Posting here per DTS guidance (no reduced sample project available). Creating a CKQuerySubscription on the PUBLIC database in the Production environment always fails, on a production-signed TestFlight build. It works in the Development environment; only Production rejects it. Error: CKError 12 (invalidArguments); underlying "BadSyntax" (2006); server message = "attempting to create a subscription in a production container". The subscription: let sub = CKQuerySubscription( recordType: "PublicSolution", predicate: NSPredicate(format: "%K == %@", "challengeAuthorID", myUserRecordName), subscriptionID: "MyChallengeSolved-", options: [.firesOnRecordCreation]) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true sub.notificationInfo = info try await container.publicCloudDatabase.save(sub) Verified (all good): TestFlight build is distribution-signed: aps-environment = production (confirmed with codesign on the archive). APNs registration succeeds on device (valid token). CKContainer.accountStatus = .available; userRecordID resolves. Reads of PublicSolution succeed in Production. challengeAuthorID on PublicSolution is QUERYABLE in the deployed Production schema (verified in CloudKit Console). Dev and Production schemas are identical; deployed to Production multiple times (Console reports "no changes"). Removing notificationInfo.desiredKeys made no difference. Push Notifications capability present; entitlement aps-environment = production. Question: What makes Production reject this public-DB CKQuerySubscription create, and what container-side configuration allows it? Same code succeeds in Development. Container: iCloud.JCM.Contraptor

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'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.

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.

Two months ago we got approval for using the Notification Filtering entitlement. We rushed out to implement it in our app, only to find out that the permission was set for the wrong bundle identifier. We expected to get the permission for the notification extension's bundle identifier, yet it is added for the main app's bundle identifier. Per the official docs, the entitlement permission should be in the notification service extension target: After you receive permission to use the entitlement, add com.apple.developer.usernotifications.filtering to the entitlements file in the Notification Service Extension target. However, this fails to get signed when compiling for non-simulator targets because of the bundle mismatch issue. Simulator perfectly filters notifications. Adding the entitlement to the main app does compile, but filtering does not work (as expected). We reached out to Apple twice (Case-ID: 14330583) but we have yet to receive any response. Could there be something else wrong instead of the identifier mismatch?

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.

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

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

1. Does the "important" description for silent notification in the documentation still valid? (Pushing background updates to your App) The system treats background notifications as low priority: you can use them to refresh your app’s content, but the system doesn’t guarantee their delivery. In addition, the system may throttle the delivery of background notifications if the total number becomes excessive. The number of background notifications allowed by the system depends on current conditions, but don’t try to send more than two or three per hour. I would like to implement notification that would wake up my application in all state to perform AVSpeechSynthesizer, but I am confused with the availability of the silent notification. I attempted to send silent notification to my ipad to see the exact behaviour, but it seems like it has not been throttle even after a few tens attempts within the same hour. { "aps": { "content-available": 1, "alert": { "title": "Title", "body": "Content"}, "sound": "default" } } 2. I am also confused if mixing the "content-available" key pair with "alert" in the aps payload will make the Heads-up Notification been throttle as well?

I’m experiencing an issue with Apple Developer Support communication. On the page Apple Developer Support Cases I can see updates and messages indicating that Apple Support specialists supposedly replied to my case. However, I never receive those emails in my inbox. The only emails that actually arrive to my Gmail account are automatic messages with the subject: “Thanks for submitting your support request” I checked: Spam folder Promotions/Social tabs Gmail filters Blocked addresses But there are still no replies from support specialists. Because of this, I cannot continue communication with support. Has anyone experienced the same issue? Is there a specific Apple domain/email address that should be whitelisted? Apple Support team, please contact me directly.

We are working on a feature that uses geo-based local notifications to target users when they arrive at an airport. Our implementation uses UNLocationNotificationTrigger with CLCircularRegion. The local notification is scheduled after the user has granted notification permission and location permission. We are currently using “While Using the App” location permission and with enabled location updates in capabilities We have used CLMonitor as well for the same. However, we are seeing inconsistent accuracy and missed triggers, even after testing with users who have granted the required permissions. we did use CLMonitor as well but we are getting the trigger on the entry of specified region. Could you please help us understand the constraints and expected behavior for location-based notification triggers on iOS? Specifically, we would like guidance on the following: What parameters influence UNLocationNotificationTrigger accuracy and reliability? What is the recommended minimum radius for geofencing around large areas such as airports? Does “While Using the App” permission have any practical limitations for location-based local notification delivery? Are there system-level conditions that may prevent or delay the trigger, such as Precise Location being off, Low Power Mode, Focus mode, Background App Refresh, airplane mode, or poor GPS/network availability or any others? Are there recommended best practices for improving reliability for an airport-arrival use case?