Environment Xcode 26.5 beta iOS 26.5 beta Using AccessorySetupKit + AccessoryTransportExtension framework Three extensions: AccessoryTransportAppExtension, AccessoryTransportSecurityExtension, AccessoryDataProviderExtension Background Everything worked correctly on iOS 26.4 beta. All three extensions shared the entitlement com.apple.developer.accessory-transport-extension, and the system launched them as expected. After upgrading to iOS 26.5 beta (both Xcode and device), the app compiles and runs, the accessory pairs and connects successfully (state = authorized, BLE connected, notification forwarding = allow), but none of the extensions are launched by the system. Investigation Captured system Console logs from the device and found these errors from deviceaccessd: error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryDataProviderExtension' is missing entitlement: com.apple.developer.accessory-data-provider for com.apple.accessory-data-provider error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryTransportSecurityExtension' is missing entitlement: com.apple.developer.accessory-transport-security for com.apple.accessory-transport-security It appears that iOS 26.5 now requires per-extension-type entitlements instead of the shared one. On iOS 26.4, all three extensions used com.apple.developer.accessory-transport-extension and it worked. On iOS 26.5, deviceaccessd now expects com.apple.developer.accessory-transport-security for the security extension and com.apple.developer.accessory-data-provider for the data provider extension. The transport app extension did not report an error, so it may still accept the old entitlement. Attempted Fix Changed the entitlement keys in the .entitlements files to match what deviceaccessd expects. Xcode fails to build with: ▎ Entitlement com.apple.developer.accessory-data-provider not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. Root Cause Checked Apple Developer Portal — only one capability is available: "Accessory Transport Extension", which maps to com.apple.developer.accessory-transport-extension. There are no separate capability options for the new entitlements. The iOS 26.5 beta system requires new per-extension-type entitlements, but the provisioning system does not yet support them. This makes it impossible to build a working AccessoryTransport app on iOS 26.5 beta. Request Please either add the new entitlement capabilities (com.apple.developer.accessory-transport-security, com.apple.developer.accessory-data-provider) to the Apple Developer Portal, or restore backward compatibility with com.apple.developer.accessory-transport-extension in deviceaccessd.

Since upgrading to Xcode 26 beta 4 and using the iOS 26 simulator for testing our app, we've stopped being able to receive device tokens for the simulator from the development APNS environment. The APNS environment is able to return meta device information (e.g. model, type, manufacturer) but there are no device tokens present. When running the same app using the iOS 18.5 simulator, we are able to register the device with the same APNS environment and receive a valid device token.

In my Notification Service Extension I'm doing two things in parallel inside didReceive(_:withContentHandler:): Downloading and attaching a rich media image (the standard content modification work) Firing a separate analytics POST request (fire-and-forget I don't wait for its response) Once the image is ready, I call contentHandler(modifiedContent). The notification renders correctly. What I've observed (via Proxyman) is that the analytics POST request completes successfully after contentHandler has already been called. My question: Why does this network request complete? Is it because: (a) The extension process is guaranteed to stay alive for the full 30-second budget, even after contentHandler is called so my URLSession task continues executing during the remaining time? (b) The extension process loses CPU time after contentHandler but remains in memory for process reuse and the request completes at the socket/OS level without my completion handler ever firing? (c) Something else entirely? I'd like to understand the documented behaviour so I can decide whether it's safe to rely on fire-and-forget network requests completing after contentHandler, or whether I need to ensure the request finishes before calling contentHandler.

Issue: Push notifications are not being received for some users. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving success responses from APNS. Users have confirmed that notifications are enabled on their devices, and they report no network issues.

The following issue has occurred: Push notifications are not being received on certain devices. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving normal responses from APNs. Users have confirmed that notifications are enabled on their devices, and they report no network issues. This problem is occurring for multiple users.

Hello, I'm from Microsoft team maintaining push notification api behind Teams platform. We are experiencing strange and short error spikes towards APNS that seem to mostly correlate worldwide. We checked the networking and push request code but could not find what could be causing this. These error spikes are all timeouts or connection resets (by remote host, ie. APNS servers) and seem to come and go randomly: Would it be possible to check this for outages or some other metrics on your side or investigate why would it happen? Since it's worldwide it seems unlikely it's something broken on our side. We are using the standard APNS http2 endpoint with modern support for all RFC features (so everything should work normally). Mind you, our api might be in a unique position because of the volume of notifications (in the billions per day).

I have a messaging app that has been working successfully for several years. It still works for most users, but about one month ago one of my users started experiencing issues receiving notifications. From my investigation, the user's Notification Service Extension (NSE) has not been triggered since they started reporting the issue. I was able to access the user's phone and connected it to the console to check for any logs related to the NSE being triggered or a push notification being received, but there were no relevant logs. I have already verified that notifications are enabled for the app and that Do Not Disturb is not active. I also tried sending a test notification using the CloudKit Console. The notification was successfully delivered to other push notification tokens, but it did not work for this specific device’s token. I have also confirmed that the push token on the server matches the one on the device and that it is being used with the APNs production environment. The issue for this user started in iOS version 26.2 and are still ongoing in version 26.3.1 . Has anyone encountered a similar issue or have suggestions on how to further diagnose this?

We recently developed the provisional permission for our app, but we have noticed that is not working as expected in iOS 16 (We have tested only there). Currently we request the permissions like this: UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound, .provisional]) { [weak self] _, _ in // here we register for pushes in case authorizationStatus is provisional or authorised } What happens is we do get the 1st notification with the keep CTA - once tapped we see that there pops an action: "Deliver Immediately", but even though the user selects that, we still see under setting the pushes are marked as "Deliver Quietly". In addition to this the sound and bage still stay as toggled off - and the lock screen and banner as well stay off. Basically, nothing changes after the user selects "Deliver Immediately"

I'm working on an app that syncs with Apple Health events. Every time an event occurs, the app should send a notification. The problem occurs when the app is backgrounded or force-closed; it can no longer send local notifications, and because these events can occur at any time, scheduled notifications can't be used. I'm just wondering if anyone's found a creative way around this. I know we can't override system behaviour, I'm just thinking of other alternative solutions for the matter.

The APP was not awakened by system after start a liveactivity and the liveactivity has showed on lock screen.so the updatetoken wont send to our inner server and the liveactivity can not update,often like this,but sometimes it can work. it makes me confuse,and i don't know how should i can do,because the liveactivity like a black box,i can not analyse the data link.for example ,inner server send a start liveactivity,but it can not accept a updatetoken unless the user lanuch APP. i hope the liveactivity can start and update on background. And i have developed it as described in the document. Hope to get your help，thank you very much.

I am developing an application that uses NetworkExtension (Local PUSH function) And VoIP(APNs) PUSH. Nowadays, I found a problem on this app doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an APNs PUSH. My confimation result of my app and server log is below. 11:00 AM: my server(PBX) requests a VoIP(APNs) PUSH notification to the APNs. But my app does not receive the VoIP(APNs) PUSH. At this time, my app is running on LAN (Wi-Fi without internet connection), as a result, NetworkExtension was running. so I think this is normal behaviour. 14:55:11 PM: There is an incoming call from the my server(PBX) via local net, and NetworkExtension calls iOS API(API name is reportIncomingCall). However, iOS does not call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall. 14:55:11 PM: At almost the same time, iOS calls the delegate cdidReceiveIncomingPushWithPayload of VoIP PUSH. (instead of call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall?) And the content of this VoIP(APNs) PUSH was the incoming call at "11:00 AM". In other words, the VoIP(APNs) PUSH at 11:00 AM is stuck inside iOS, and at 14:55:11 PM, from NetworkExtension reports it. I feel there is a problem on iOS doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an VoIP(APNs) PUSH. Would you tell me Apple's opioion about this? If this is known problem, Please tell me about it.

My team is developing an enterprise VPN application that needs to respond to Mobile Device Management (MDM) profile installations and removals in real-time. Our app uses the NetworkExtension framework and needs to update the UI immediately when VPN configurations are added or removed via MDM. We are currently observing NEVPNConfigurationChangeNotification to detect VPN configuration changes: While NEVPNConfigurationChangeNotification fires reliably when users manually remove VPN profiles through Settings > General > VPN & Device Management, it appears to have inconsistent behavior when MDM profiles containing VPN configurations are installed programmatically via MDM systems. STEPS TO REPRODUCE From MDM Admin Console: Deploy a new VPN profile to the test device On Device: Wait for MDM profile installation (usually silent, no user interaction required) Check Device Settings: Go to Settings > General > VPN & Device Management to confirm profile is installed Return to App: Check if the UI shows the new VPN profile

In didFinishLaunchingWithOptions I have this setup for getting the token to send to my server for notifications. The issue is that the delegate callback didRegisterForRemoteNotificationsWithDeviceToken gets called twice when also initializing a CKSyncEngine object. This confuses me. Is this expected behavior? Why is the delegate callback only called twice when both are called, but not at all when only using CKSyncEngine. See code and comments below. /// Calling just this triggers `didRegisterForRemoteNotificationsWithDeviceToken` once. UIApplication.shared.registerForRemoteNotifications() /// When triggering the above function plus initializing a CKSyncEngine, `didRegisterForRemoteNotificationsWithDeviceToken` gets called twice. /// This somewhat make sense, because CloudKit likely also registers for remote notifications itself, but why is the delegate not triggered when *only* initializing CKSyncEngine and removing the `registerForRemoteNotifications` call above? let syncManager = SyncManager() /// Further more, if calling `registerForRemoteNotifications` with a delay instead of directly, the delegate is only called once, as expected. For some reason, the delegate is only triggered when two entities call `registerForRemoteNotifications` at the same time? DispatchQueue.main.asyncAfter(deadline: .now() + 4) { UIApplication.shared.registerForRemoteNotifications() } func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { print("didRegisterForRemoteNotificationsWithDeviceToken") }

Hello! We've had reports of iOS devices 'waking up' and vibrating in response to the push notifications arriving but the notification itself is not being displayed to the user, despite having been granted the correct permissions. Is this a known issue?

Hello, I am developing a driver-based application targeting iOS 14+, where users receive time-sensitive trip offers (approximately 10–15 seconds to respond). We would like to implement behavior similar to approval-based apps (e.g., MyGate-style interaction), with the following requirements: When the device is locked: A highly visible notification that allows quick Accept / Decline action. When the device is unlocked (foreground or background): A notification that remains prominently visible (sticky-style) at the top of the screen until the user takes action (Accept / Decline) or the offer expires. Our goal is to ensure the offer remains noticeable and actionable within the short response window. I would appreciate clarification on the following: On iOS 14, is there any supported mechanism to present a true full-screen blocking interface while the device is locked (without using CallKit or Critical Alerts entitlement)? Is there a supported way to make a notification persistent or non-dismissible until the user takes action or the offer expires? Are there any App Review concerns with presenting a blocking modal immediately after the user interacts with a notification? We want to ensure full compliance with Apple’s platform guidelines and avoid unsupported or discouraged patterns. Thank you for your guidance.

Device: iPhone (real device) iOS: 17.x Permission: Granted Notifications are scheduled using UNCalendarNotificationTrigger. The function runs and prints "SCHEDULING STARTED". However, notifications never appear at 8:00 AM, even the next day. Here is my DailyNotifications file code: import Foundation import UserNotifications enum DailyNotifications { // CHANGE THESE TWO FOR TESTING / PRODUCTION // For testing set to a few minutes ahead static let hour: Int = 8 static let minute: Int = 0 // For production use: // static let hour: Int = 9 // static let minute: Int = 0 static let daysToSchedule: Int = 30 private static let idPrefix = "daily-thought-" private static let categoryId = "DAILY_THOUGHT" // MARK: - Permission static func requestPermission(completion: @escaping (Bool) -> Void) { let center = UNUserNotificationCenter.current() center.requestAuthorization(options: [.alert, .sound]) { granted, _ in DispatchQueue.main.async { completion(granted) } } } // MARK: - Schedule static func scheduleNext30Days(isPro: Bool) { print("SCHEDULING STARTED") let center = UNUserNotificationCenter.current() center.getNotificationSettings { settings in guard settings.authorizationStatus == .authorized else { requestPermission { granted in if granted { scheduleNext30Days(isPro: isPro) } } return } // Remove old scheduled notifications center.getPendingNotificationRequests { pending in let idsToRemove = pending .map { $0.identifier } .filter { $0.hasPrefix(idPrefix) } center.removePendingNotificationRequests(withIdentifiers: idsToRemove) let calendar = Calendar.current let now = Date() for offset in 0..<daysToSchedule { guard let date = calendar.date(byAdding: .day, value: offset, to: now) else { continue } var comps = calendar.dateComponents([.year, .month, .day], from: date) comps.hour = hour comps.minute = minute guard let scheduleDate = calendar.date(from: comps) else { continue } if scheduleDate <= now { continue } let content = UNMutableNotificationContent() content.title = "Just One Thought" content.sound = .default content.categoryIdentifier = categoryId if isPro { content.body = thoughtForDate(scheduleDate) } else { content.body = "Your new thought is ready. Go Pro to reveal it." } let triggerComps = calendar.dateComponents( [.year, .month, .day, .hour, .minute], from: scheduleDate ) let trigger = UNCalendarNotificationTrigger( dateMatching: triggerComps, repeats: false ) let identifier = idPrefix + isoDay(scheduleDate) let request = UNNotificationRequest( identifier: identifier, content: content, trigger: trigger ) center.add(request) } } } } // MARK: - Cancel static func cancelAllScheduledDailyThoughts() { let center = UNUserNotificationCenter.current() center.getPendingNotificationRequests { pending in let idsToRemove = pending .map { $0.identifier } .filter { $0.hasPrefix(idPrefix) } center.removePendingNotificationRequests(withIdentifiers: idsToRemove) } } // MARK: - Helpers private static func isoDay(_ date: Date) -> String { let formatter = DateFormatter() formatter.locale = Locale(identifier: "en_US_POSIX") formatter.dateFormat = "yyyy-MM-dd" return formatter.string(from: date) } private static func thoughtForDate(_ date: Date) -> String { guard let url = Bundle.main.url(forResource: "thoughts", withExtension: "json"), let data = try? Data(contentsOf: url), let quotes = try? JSONDecoder().decode([String].self, from: data), !quotes.isEmpty else { return "Stay steady. Your growth is happening." } let calendar = Calendar.current let comps = calendar.dateComponents([.year, .month, .day], from: date) let seed = (comps.year ?? 0) * 10000 + (comps.month ?? 0) * 100 + (comps.day ?? 0) let index = abs(seed) % quotes.count return quotes[index] } } Then here is my Justonethoughtapp code: import SwiftUI import UserNotifications @main struct JustOneThoughtApp: App { @StateObject private var thoughtStore = ThoughtStore() // MUST match App Store Connect EXACTLY @StateObject private var subManager = SubscriptionManager(productIDs: ["Justonethought.monthly"]) var body: some Scene { WindowGroup { ContentView() .environmentObject(thoughtStore) .environmentObject(subManager) .onAppear { // Ask for notification permission NotificationManager.shared.requestPermission() // Schedule notifications using PRO status DailyNotifications.scheduleNext30Days( isPro: subManager.isPro ) } } } } final class NotificationManager { static let shared = NotificationManager() private init() {} func requestPermission() { UNUserNotificationCenter.current().requestAuthorization( options: [.alert, .sound, .badge] ) { _, _ in } } }

I submitted the form for the critical alert entitlement but have not received any response for already 2 weeks. How long does it normally take to review such requests? Is there any way I can contact a certain department directly?

Problem Description Location-based notifications added with UNLocationNotificationTrigger and CLCircularRegion do not fire consistently when the user enters the monitored region. Sometimes they work, sometimes they do not. In tests where the user physically enters the region and waits several days, the notification often never triggers. What we’ve confirmed Notification permission is granted Location permission is set to “Always” The notification request is successfully added (no error from UNUserNotificationCenter.add) Pending notification requests are present when checked with getPendingNotificationRequests CLLocationManager didEnterRegion / didExitRegion work when we monitor the same region via startMonitoring(for:) UNLocationNotificationTrigger behavior is inconsistent and unreliable in our tests Reproduction Steps Launch the app and grant notification permission and “Always” location permission Add a region notification (either by current GPS location or by selecting a point from MKLocalSearch) Leave the monitored region Later, physically return into the region Expected: a notification is delivered when entering the region Actual: the notification often does not appear, even after waiting days Our Hypothesis: Coordinate System Mismatch in China We suspect the issue may be related to coordinate systems in mainland China. In China, Apple MapKit and MKLocalSearch use GCJ-02 (the “Mars” coordinate system required by local regulations). Device GPS and CLCircularRegion / Core Location use WGS-84. If an app supplies GCJ-02 coordinates to CLCircularRegion (e.g. from MapKit or search), the region center may be offset by hundreds of meters from the actual WGS-84 position. That could make the system’s “inside region” check fail, even when the user is physically inside the intended area. Questions for Apple Does CLCircularRegion (and therefore UNLocationNotificationTrigger) expect coordinates in WGS-84? If so, should apps in China convert GCJ-02 to WGS-84 before passing coordinates to CLCircularRegion? Is there any official guidance or documentation for handling coordinate systems when using location-based notifications in mainland China? Are there known limitations or special requirements for UNLocationNotificationTrigger in China (e.g. coordinate system, accuracy, or system behavior) that could explain intermittent or missing triggers?

Why can I use background delivery to realize background notifications when I run the app for the first time, but when I delete the app running in the background, and then reopen the app to run it in the background, there will be no background notification when the data changes?

I'm having a reproducible problem receiving push notifications on macOS 26.2. The pattern is that the push is received and then discarded almost immediately (there is a 60s expiration date) when on battery power and then when I plug in pushes start working and even if I unplug again it works for hours until breaking again. These are alert notifications with priority 10. Other team members have had similar problems but less reliably broken and even get a "stored for device power considerations" message followed by discarded (see apns-unique-id c29250a3-abbf-008a-96f9-a5384e32d1df). An example from my machine with the apns-unique-id 6b2dfe3d-af99-182a-0e1e-6b811d3ec486 which fails immediately. iOS is working fine however so this seems to be confined to macOS only.