I tried to compile the latest mDNSResponder (2881.120.11) for linux and discovered that it simply doesn't build: ../mDNSShared/uds_daemon.c: In function ‘resolve_result_callback’: ../mDNSShared/uds_daemon.c:3629:46: error: ‘request_state’ has no member named ‘resolve_awdl’ 3629 | const mDNSBool is_split_awdl_query = (req->resolve_awdl && question->InterfaceID == AWDLInterfaceID); | ^~ ../mDNSShared/uds_daemon.c:3629:89: error: ‘AWDLInterfaceID’ undeclared (first use in this function); did you mean ‘mDNSInterfaceID’? 3629 | const mDNSBool is_split_awdl_query = (req->resolve_awdl && question->InterfaceID == AWDLInterfaceID); | ^~~~~~~~~~~~~~~ This line was introduced in release 2881.60.4 (Jan 5, 2026), and all of the AWDL-related changes made to uds_daemon in that version look like unfinished code: The line shown above which references a non-existent struct field and nowhere-defined identifier/constant. Two functions in uds_daemon.c define a variable mDNSBool has_split_awdl_query = mDNSfalse; which is unused apart from its (unconditionally false) value being logged. The max-size-check for struct request_state in uds_daemon.h is increased but the struct itself wasn't changed (nor does the release introduce any other changes that might indirectly change the size of the struct) This code is common to all supported targets, so that means all four mDNSResponder releases done this year fail to build on all platforms. I'm a bit astonished how this even happens and has gone unnoticed for this long. Unfortunately it's not clear how to properly report this, the github repo has no issue tracker and the feedback assistant doesn't seem to have applicable options for this.

I’m looking for clarification on what iOS currently allows third-party apps to do in these areas: Siri integration and background voice activation: Can an iOS app implement a custom voice assistant that responds to a wake phrase such as “Hey Nowa” and performs app tasks through voice commands? Could it listen while the app is terminated or the iPhone is locked, similar to Siri? Call recordings: Is there a supported way for an iOS app to access recordings of phone calls made on the user’s iPhone and make them available within the app? I couldn’t find documentation for an API that provides access to these recordings. SMS access: Is there a supported way for an iOS app to access and fetch all SMS and iMessage conversations stored in the user’s Messages app, so they can be viewed within our app? As far as I understand, iOS may not allow these capabilities for third-party apps, but I’d appreciate clarification. If any are supported, could you please point me to the relevant Apple documentation?

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

Hello all, Looking for guidance for my app. I run a workout studio and the time frames for classes are all in military time. I have tried extensively to have this turned off and I am just unsure what is left to do. Has anyone dealt with something like this?

I'm getting a persistent WeatherKit authentication failure that survives every standard troubleshooting step. Hoping someone from the WeatherKit team can check the backend sync for my Team ID. Team ID: 9CQUMUHB42 Bundle ID: com.martin.MinimalWidgets (app) Bundle ID: com.martin.MinimalWidgets.MinimalWidgetsWidget (widget extension) Error: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" What I've verified: WeatherKit capability is enabled in Xcode for BOTH the app and widget extension targets WeatherKit is enabled in the App ID configuration for both identifiers in the Developer Portal Confirmed with codesign -d --entitlements :- that com.apple.developer. weatherkit is correctly present and set to true in the signed binaries for both the app and the extension WeatherKit Usage dashboard shows 500,000 calls/month quota, 0 used Cleared the provisioning profile cache at ~/Library/Developer/Xcode/UserData/Provisioning Profiles, ran Download Manual Profiles again Clean Build Folder, deleted the app from device, reinstalled Restarted the test device Waited over 24 hours since first enabling the capability None of the above resolved it — the exact same error persists on every attempt, including today. This looks like a backend entitlement sync issue between the Developer Portal and the WeatherKit auth service rather than a local configuration problem, since the signed entitlements are confirmed correct on my end. Could someone from the WeatherKit team check the sync status for this Team ID / Bundle ID and confirm whether WeatherKit token generation is enabled server-side? Happy to provide any additional diagnostic info (sysdiagnose, device logs, etc.) if needed. Thanks in advance!

We are currently verifying the functionality of CXSetTranslatingCallAction. We tested its implementation in a VoIP app—using Apple's Translate app by default—and confirmed that it works correctly in some instances. However, we have encountered an issue where, under certain conditions, the real-time translation feature becomes unavailable until the device is rebooted. The issue manifests as follows: When the real-time translation feature is enabled in CallKit, a beep sounds accompanied by the announcement "Starting translation," but the translation fails to proceed and terminates immediately. This behavior persists upon repeated attempts. Restarting the app does not resolve the issue; once this occurs, the feature remains unusable until the device itself is rebooted. Since the feature works normally after a device reboot, it does not appear to be a fundamental implementation error; I would like to investigate the root cause of this behavior. What information or steps are required to investigate this? I conducted the test using an iPhone 16 Pro running OS version 26.5. It is the same for both CallKit and LCK.

Hi team, I’m working on an ActivityKit use case where a Live Activity is useful on the Lock Screen, but not in the Dynamic Island. Today, Live Activities appear to be treated as a unified presentation across system surfaces: Lock Screen, Dynamic Island, StandBy, etc. For our app, the Lock Screen presentation is the right user experience, but showing the same activity in the Dynamic Island creates unnecessary persistent foreground UI while the user is actively using the device. Is there any supported way to create a Live Activity that appears on the Lock Screen but opts out of Dynamic Island presentation on supported iPhones? If not, I’d love to request an ActivityKit enhancement that lets developers specify supported presentation destinations for a Live Activity, for example something like: Lock Screen only or Lock Screen + StandBy, but not Dynamic Island This would be useful for apps where the Live Activity is meant to act as a passive lock-screen status/reminder, rather than an ongoing foreground indicator. Thanks!

I’m developing a macOS app that reads a wired controller and publishes a generic BLE HID gamepad for an iPhone. BLE communication works, but iOS does not expose the device through GameController. I’m looking for guidance on supported device-identity publication and controller-admission requirements. Environment Apple Silicon MacBookPro17,1: macOS 27.0, build 26A428 iPhone 15 Pro Max: iOS 27.0, build 24A437 Xcode 27 Peripheral implemented using CBPeripheralManager What works The iPhone can connect, perform dynamic characteristic reads, and read encryption-required characteristics using the retained pairing. It discovers the application’s HID service and reads its Report Map, HID Information, Report Reference, and Input Report. The descriptor in the iPhone’s system HID record matches the application’s remotely read report map byte-for-byte. The peripheral also receives an input subscription, although I cannot independently identify the subscribing consumer. What fails An independent GCController.controllers() observer remains empty. During the recorded HID initialization, the iPhone logs: Un-authenticated game controller device attached Start failed: 0xe00002bc IOHIDEventDriver start failed. For the same registry device, gamecontrollerd records: vendorID = 0 productID = 0 version = 0 manufacturer = 'Apple Inc.' product = '[Mac device name]' transport = 'BluetoothLowEnergy' I am not assuming that “Un-authenticated” identifies a specific authentication requirement. I would like to understand which supported admission requirement is unmet. Device Information observations The iPhone’s CoreBluetooth discovery exposes two distinct Device Information service instances: System service Observed UUID: 180A Manufacturer: Apple Inc. Model: MacBookPro17,1 No PnP characteristic exposed by successful all-characteristic discovery Application service Observed UUID: 0000180A-0000-1000-8000-00805F9B34FB Manufacturer: PS3 Bridge Model: BLE Gamepad Prototype PnP bytes: 02 00 00 01 00 00 01 The application publishes expanded Bluetooth-base UUIDs. I understand these represent the same assigned UUIDs; I am preserving the observed representations because I have not established whether every host component handles them identically. The application PnP value represents vendor-ID source 2, vendor 0, product 1, and version 0x0100. The system HID record therefore does not simply reflect that value unchanged. The duplicate-DIS layout also appears inconsistent with the unique primary DIS expected by HOGP. I have not established that this causes the driver rejection. Questions Is there a supported macOS API or architecture for publishing a coherent BLE HID device identity when macOS already exposes its own Device Information service? How does iOS select DIS/PnP information when constructing a system HID device in this arrangement? Is a generic BLE HID gamepad published through macOS CoreBluetooth a supported path to iOS GameController recognition? If so, what additional profile, identity, or authentication requirements apply? What supported diagnostics would distinguish an identity-selection problem from a separate controller-admission requirement? Available evidence I have diagnostic source, corrected per-service-instance inventories, and redacted phone logs available. I also have a small standalone CoreBluetooth publication reproducer. It is reduced and has not been validated as independently reproducing the full bridge’s controller rejection. A later connection-only observation reused an existing shared Bluetooth link and still showed zero controllers. I am not treating that as a fresh HID initialization or admission attempt. I’m seeking a supported implementation path without private APIs, Bluetooth daemon modifications, or changes to system security.

I am evaluating a local diagnostic design before implementation or deployment and need to identify a public, supported macOS confinement mechanism. Proposed arrangement: A privileged custodian remains outside a separate privileged guardian's process group. The guardian launches a fixed diagnostic parent under a dedicated unprivileged identity. That parent sequentially launches three fixed sandboxed Python workloads, one child at a time. The current termination design targets the guardian's process group. It must not rely on whole-host process scans or indiscriminate killing. The proposed sandbox profiles are allow-default with file/network restrictions; the test-child profiles deny process-fork. We have not established that these restrictions prevent an existing process from changing its own group or session. Is there a public, supported interface or configuration that keeps all workload descendants within the supervisor's termination boundary from the initial child transition through final cleanup, while still allowing the parent to launch its authorized sequential children? In particular, please clarify: Escape through setsid/setpgid, spawn attributes, exec or native-library paths. When enforcement begins and whether descendants can relax it. Behavior when the diagnostic parent or guardian exits. Required privileges, entitlements, and supported OS/SDK versions. If the described sandbox categories do not establish that property, please identify the supported alternative boundary, if one exists. A different boundary would require an explicit design change on our side. I am requesting documented interface behavior and limitations—not private sandbox internals, a review of project code, or an absolute termination guarantee during kernel failure. No experiment has been performed to establish this property.

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?

Hello, I develped underground GNSS solution. The goal of this is to achieve seamless GNSS for navigation and autonomous driving. The solution we developed has been installed in tunnel in Korea. We tested it using an Android phone and iPhone. We check the Android phone's response using the GNSSLogger App. however, there is not one for the iPhone. I want to make PERFECT solution in tunnel. So, how can I get GNSS log from and iPhone? Thanks.

iOS Background Location / Geofencing for Automatic Attendance — App Not Triggering Reliably We are developing an enterprise attendance application called Attendo, which uses location-based geofencing for automatic employee check-in/check-out. Business requirement The application needs to work as follows: An employee is assigned an office/work location with a defined radius. When the employee enters the configured radius, the application should automatically record a Check-In. When the employee leaves the radius, the application should automatically record a Check-Out. This should happen without the employee having to open the application. The functionality needs to work even when the application is in the background and, where supported by iOS, after the application has been terminated. For example: «Office geofence = 200 meters Employee enters the 200 m radius → automatic Check-In Employee leaves the 200 m radius → automatic Check-Out» Current iOS implementation We are using iOS location services with: Location permission: Always Precise Location: enabled Background Location capability enabled Background location updates enabled Geofencing / region monitoring The application is intended to respond to location/geofence events without requiring the user to open the app. However, we are seeing cases where the application does not reliably receive/process the required location/geofence event when the application has been in the background for an extended period. The same business workflow works more reliably while the application is active. Our concern Our understanding is that iOS does not allow an application to maintain a continuously running background service in the same way that Android can. However, our requirement does not necessarily require continuous GPS polling if there is an Apple-supported mechanism that can reliably wake/relaunch the application when a user crosses a geofence. We would therefore like to understand the recommended architecture for this use case. Questions Is Core Location Region Monitoring the recommended mechanism for an enterprise geofencing application that needs to detect entry/exit while the app is not running? Can iOS relaunch the application after it has been terminated by the user/system when a monitored region is entered or exited? Is there any supported way to guarantee that an application will continue receiving location/geofence events after it has been in the background for a long period? Does enabling: "UIBackgroundModes = location" "allowsBackgroundLocationUpdates" "CLLocationManager" Region Monitoring provide the expected behavior, or are there additional requirements/configurations we should consider? Are there known limitations regarding: Low Power Mode device movement speed GPS/location accuracy stationary devices iOS terminating/suspending the application force-quitting the application from the App Switcher large/small geofence radius multiple monitored regions Is it possible to use significant-change location updates + region monitoring together for this type of attendance workflow? For an enterprise application where the user explicitly grants Always Allow Location permission and Precise Location is enabled, what level of reliability can realistically be expected from iOS geofencing? Important business constraint We cannot require employees to manually open the application every time they arrive at or leave the workplace. The objective is an automatic attendance system, where the employee's entry and exit from the workplace geofence is detected by iOS and the application records the corresponding attendance event. We understand that iOS is designed to protect battery life and user privacy and that continuous background execution may not be permitted. We are therefore looking for the Apple-recommended architecture for achieving this requirement using supported iOS APIs, rather than trying to circumvent iOS background execution policies. Any guidance from Apple engineers or developers who have implemented reliable enterprise geofencing would be greatly appreciated.

Dear Apple Developer Support, I am developing HushRise, an iPhone alarm application intended to help people in Ukraine manage sleep disrupted by wartime air-raid alerts. Nighttime alerts can force people to interrupt their sleep and seek shelter, sometimes repeatedly. Families must then plan work, school, and other responsibilities around these disruptions. Educational institutions and other services may suspend in-person activities during alerts, making a fixed wake-up time less useful than a wake-up signal that takes the current alert status into account. The purpose of HushRise is to support rest and daily routines under these conditions. It is not an official emergency-warning service and must not replace civil-defence alerts or encourage people to ignore them. The intended behavior is: A user sets a wake-up time and selects their region. At that time, the alarm starts only after a fresh server response confirms that no air-raid alert is active. If an alert is active, the application waits for the reported all-clear. Multiple alarms postponed during the same alert should produce one wake-up signal after the all-clear. A snoozed alarm must also obtain fresh confirmation before starting again. An alarm that has already started may continue until the user stops or snoozes it. We have tested a native AlarmKit integration on a physical iPhone. The system alarm, Lock Screen controls, Apple Watch presentation, and Stop action work. However, without ongoing background audio, iOS suspends our application’s status checks. In one test, an alarm due at 20:09 was not scheduled until the application returned to the foreground at 20:11. Audible background playback helped in experiments, but requiring continuous sound is not appropriate for the intended quiet sleep experience. Could your technical team please advise: What supported architecture should we use for an AlarmKit alarm whose trigger depends on a server event occurring at an unknown time? Can a server notification initiate the necessary validation and alarm scheduling while the iPhone is locked, and what execution guarantees or limitations apply? Is there an entitlement or approval process appropriate to this use case? Would Critical Alerts be applicable, or would another mechanism be more suitable? Which capabilities require Apple Developer Program membership? Our current prototype is installed through a free Personal Team. We understand that an offline device cannot receive new server information and that notification delivery may be delayed. We want to communicate these limitations honestly and build within Apple’s supported APIs. We can provide a minimal reproducible project, sanitized device logs, and a description of our physical-device tests. Thank you for helping us identify a reliable and appropriate approach for people whose sleep and daily lives are affected by the war in Ukraine. Kind regards, HushRise developer

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

I've been working on an app. It uses iCloud syncing. 48 hours ago everything was working 100%. Make a change on the iPhone it immediately changed on the Mac. Change on the Mac, it immediately changed on the iPhone. I didn't work on it yesterday. I updated to iOS26.4 on the iPhone and 26.4 on the Mac yesterday instead. Today, I pull up the project again. I made NO changes to the code or settings. Make a change on the iPhone it immediately updates on the Mac. Make a change on the Mac, nothing happens on the iPhone. I've waited an hour, and the change never happens. If you leave the iPhone app, then return, it updates as it should. It appears that iCloud's silent notification is to being received by the iPhone. Anyone else having the issue? Is there something new with iOS 26.4 that needs to be adjusted to get this to work? Again, works flawlessly with the Mac, just not with the iPhone.

While attempting to read a user’s daily step history spanning backward to the last 7 days, a small but consistent subset of users encounter Error Code 3 with the underlying error description: Error Code 3 "Unable to invalidate interval: no data source available." When this error occurs, we are entirely unable to read their step history. We have received ~10 direct user reports of this within the last couple of weeks.

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

I am seeing a repeatable interaction between audio activity or audio-device discovery and a Bluetooth LE HID mouse on a Mac mini M2 Pro. Opening the detailed Sound panel in Control Center, or changing the HDMI audio output, makes the pointer stutter. Opening Apple’s Music.app has also caused a temporary complete loss of the mouse. In the worst cases, the mouse becomes completely unavailable and does not recover without Bluetooth troubleshooting or re-pairing. Configuration Mac mini Mac14,12, Apple M2 Pro, 32 GB RAM macOS Tahoe 26.7 (25G229) Also reproduced on macOS Tahoe 26.1 (25B78) Logitech MX Anywhere 3 Mac over Bluetooth LE VID 0x046D, PID 0xB025 Firmware MPM24.01_0015 Logitech MX Keys M Mac over Bluetooth LE PL4071UH display and audio output over HDMI Logi Options+ installed Trigger Connect the MX Anywhere 3 Mac and MX Keys over Bluetooth. Open Control Center from the menu bar. Open the detailed Sound panel, or change the HDMI audio output. Move the Bluetooth mouse continuously while audio-output discovery is taking place. The issue is intermittent, but it has been reproduced several times on both macOS 26.1 and 26.7. Pointer stuttering can continue after the Sound panel is closed. A later incident occurred when I opened Apple’s Music.app. The Bluetooth mouse became unavailable again, but this time it recovered automatically after approximately ten seconds. The Sony WH-1000XM6 headset was connected over Bluetooth, while the 512 GB USB flash drive was not connected. This shows that the USB drive is not required for a temporary mouse loss and makes concurrent Bluetooth audio activity a more relevant condition to investigate. The additional trigger suggests that the problem may not be limited to the Control Center interface itself and may also be associated with audio-subsystem initialization or audio-device activity. This is an observation, not yet a confirmed causal link. Additional condition in the permanent-loss cases In every incident where the mouse did not recover on its own and became effectively unusable, the following two devices were also present: a Sony WH-1000XM6 wireless headset connected over Bluetooth; a 512 GB SanDisk USB flash drive connected to the Mac. I am reporting this as a correlation, not as a confirmed cause. The headset adds simultaneous Bluetooth audio activity. The USB drive may or may not be relevant depending on its USB mode, activity, shielding, physical location, and possible 2.4 GHz interference. The 512 GB capacity is included only to identify the device. Less severe cursor stuttering has also been observed around Sound-panel discovery; the two devices above are specifically the common condition I recorded during the permanent mouse-loss incidents. Observed result The pointer starts stuttering and raw mouse HID reports develop multi-second gaps. In severe incidents, the Bluetooth mouse stops working entirely. Opening Music.app has also caused a temporary complete loss of the mouse; during that incident the Sony WH-1000XM6 was connected over Bluetooth, the USB flash drive was not connected, and the mouse recovered automatically after approximately ten seconds. Logi Options+ then displays the mouse as inactive. The mouse disappears from the IOHID tree, while the Bluetooth keyboard can remain present. A wired USB mouse remains responsive, so the Mac and pointer rendering are not completely frozen. The failure can persist after the Sound panel is closed. Relevant logs On macOS 26.7, bluetoothd repeatedly recorded the following sequence for the MX Anywhere 3 Mac: MX Anywhere 3 Mac needs low latency current connection parameters: interval 30.00 ms, latency 0 connection changed to: interval 7.50 ms, latency 44 Device "MX Anywhere 3 Mac" is Incompatible LE HID Device "MX Anywhere 3 Mac" does not have _HID_SERVICE_ Connection timed out disconnect result: 307 BLEPaired HIDBadBehavior Central The sequence repeated during automatic reconnection attempts. The mouse later recovered on some occasions, but other incidents required turning Bluetooth off for about 15 seconds, turning it back on, forgetting the mouse, and pairing it again. Instrumented reproduction During a monitored reproduction on macOS 26.1: detailed audio discovery started at +21.333 s; a 2.400 s gap in raw HID reports from the mouse occurred 0.899 s before that event; bluetoothd then reported a HID lag issue for VID 0x046D, PID 0xB025 at +1.897 s; no display-frame gaps were detected; there was no sustained CPU saturation. This indicates that the interruption is already present in the raw HID input stream. It does not appear to be only a cursor animation or WindowServer rendering delay. Expected result Discovering or switching audio outputs should not alter a separate BLE HID mouse connection, cause multi-second HID report gaps, remove _HID_SERVICE_, or disconnect the mouse. Technical points for investigation Could this be a macOS Bluetooth/HID connection-parameter or service-discovery problem triggered by concurrent audio discovery? In particular, why does macOS change the mouse from 30 ms / latency 0 to 7.5 ms / latency 44, then classify it as Incompatible LE HID, lose _HID_SERVICE_, and eventually disconnect it with result 307? Has anyone reproduced the same sequence with a Logitech BLE mouse, a Bluetooth audio headset, or a USB 3 storage device connected? The issue was also submitted through Apple’s public macOS feedback form on 24 September 2026. That form confirmed receipt but did not provide an FB case number. Possibly related report Another Developer Forums report describes a different BLE HID device with Incompatible LE HID and disconnect result 307 on macOS 27. The hardware and trigger are different, but the Bluetooth/HID failure signature may be related: https://developer.apple.com/forums/thread/845857

If you submitted a request for a Critical Alert Notifications entitlement and did not receive a response, please resubmit your request.

To whomever this may concern, We are investigating a BLE firmware-update compatibility issue affecting a legacy Nordic nRF51 DFU bootloader on a subset of iPads. We are seeking guidance on whether there are known CoreBluetooth or Bluetooth-controller differences across recent iPad hardware that could affect reconnection to Bluetooth LE connectable directed advertisements. Background Our accessory uses a legacy Nordic nRF51 DFU flow: The iPad is connected to the accessory’s normal application firmware. The app requests entry into DFU mode. The accessory disconnects normally. The accessory restarts into its bootloader. The bootloader sends connectable directed advertisements targeted at the iPad that initiated DFU. The iPad is expected to reconnect, after which the firmware transfer begins. Observed behavior On working iPads, the BLE trace shows: Application disconnect → accessory begins connectable directed advertising → iPad sends BLE connection indication → bootloader connection succeeds → DFU begins On affected iPads, the trace shows: Application disconnect → accessory begins the same connectable directed advertising → no connection indication from the iPad → DFU cannot proceed The accessory is advertising to the current resolvable address of the connected iPad. The bootloader starts directed advertising at nearly identical timing in both working and failing traces, approximately 456 ms after disconnect. The initial disconnect is normal in both cases: LL_TERMINATE_IND / Remote User Terminated Connection / reason 0x13 The problem occurs only after the accessory begins directed advertising. It seems like the iPad might be able to receive and listen to directed advertisement, however it seems to be unable to send back a connection indication. Hardware correlation observed so far We observed a correlation with Bluetooth controller vendor information visible in our BLE captures: FORMAT FOR FOLLOWING LINES Result -> Example device -> Observed controller vendor DFU succeeds -> iPad Air, 5th generation -> Broadcom DFU succeeds -> Other tested iPads, including one iPad with an A16-class platform -> Broadcom DFU fails -> One affected iPad with an A16-class platform -> MediaTek We want to be careful not to overstate this result: We have tested only one affected MediaTek-based iPad so far. The model string is MD3Y4LL/A and its current iOS version 26.6.1. The functioning Broadcomm iPads A16 we have tested that did not fail DFU process have model string MD7F4KN/A. The other iPad models we tested DFU on (which were all successful, albeit none of them were MediaTek chips, they were all Broadcomm) were: MRJN2KN/A, MM9C3KN/A, MQ6J3KN/A, MM6T3KN/A (the latter with iOS 26.6.1 as well, suggesting it is not necessarily an iPad OS version issue) We have not found a second MediaTek-based iPad to determine whether the behavior reproduces across that hardware. We initially suspected that recent non-cellular iPads might consistently use MediaTek, but this was disproved by the iPad Air, 5th generation we tested (MM9C3KN/A): it had no cellular connection and used Broadcom, and DFU worked normally. Therefore, we do not conclude that the issue is caused by MediaTek hardware. We only see a correlation worth investigating. What we have ruled out The target firmware image is not involved; failure occurs before any firmware data is transferred. The accessory reaches bootloader mode and sends directed advertisements at the expected time. The iOS Nordic DFU library already calls CoreBluetooth’s normal reconnect API: centralManager.connect(peripheral, options: nil) iOS does not expose an API allowing an app to create or send a raw Link Layer CONNECT_IND; therefore the application cannot directly work around controller-level connection behavior. The affected iPad does not provide a normal scanner/discovery callback for this directed bootloader advertisement, so matching by name or service UUID is not available as an application-layer workaround. Questions . Are there known CoreBluetooth, iPadOS, or Bluetooth-controller differences that can affect handling of BLE connectable directed advertisements, particularly when an accessory directs advertisements to a central using a resolvable private address? . Is there a recommended CoreBluetooth pattern for reconnecting to a known peripheral after it restarts into a legacy bootloader that uses directed advertising? . Does CBCentralManager.connect(_:options:) queue a pending connection request that should be serviced when a matching directed advertisement is received? If so, are there circumstances in which this behavior differs by iPad hardware or controller implementation? . Is there any public diagnostic information, entitlement, or supported API that could help us determine why a pending CoreBluetooth connection request does not result in a connection attempt in this scenario? . Does Apple recommend a specific compatibility approach for legacy BLE DFU bootloaders that use directed advertising, beyond updating the accessory firmware to use ordinary undirected advertising? . We can provide packet captures from both the working and failing cases, including timestamps, directed-advertisement target addresses, and the absence/presence of the subsequent connection indication. Thank you for any guidance on whether this is expected behavior, a known compatibility limitation, or if there is anything we could try on our end to hopefully resolve this issue.