I am using AccessorySetupKit on iOS 26 to set up a BLE accessory. My discovery descriptor includes .bluetoothPairingLE the bonding mechanism is LESC (Just Works without IO capability). let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = NordicServiceUUID.nus.toCBUUID() descriptor.supportedOptions = [.bluetoothPairingLE] My peripheral shows up in the picker and after selecting it ASK goes through a connection and disconnection cycle before calling .accessoryAdded event within my app. Logging on the peripheral side (nRF5 SDK 17) shows that the ASK picker connected, bonded successfully, and then triggered a remote terminated connection event (0x13). Prior implementation without .bluetoothPairingLE flag used did not disconnect from the peripheral before calling .accessoryAdded. The issue I found with this implementation is that the Pairing Modal would not always be presented and thus we are trying to leverage .bluetoothPairingLE flag for consistent behaviour across various iPhones / iOS combinations. My question, is it expected behaviour for AccessorySetupKit to connect, perform bonding, then disconnect from the peripheral prior to providing said accessory to the app via .accessoryAdded callback? I could find no documentation or community discussion discussing this behaviour or flow.

Environment iOS: 26.6 Xcode: 26.3 I’m encountering an issue migrating legacy Bluetooth peripherals using ASMigrationDisplayItem from AccessorySetupKit. I have verified that both bluetoothServiceUUID and peripheralIdentifier are correct. On the first‑time use of ASMigrationDisplayItem, the peripheral migrates successfully and shows up in iOS Settings. After deleting the app, the accessory authorization list is cleared. Upon reinstalling the app, migration attempts do nothing — no device appears in Settings. Occasionally I get this error: Error Domain=ASErrorDomain Code=500 "(null)" Picker already activated All subsequent migration attempts keep failing. The migration only works again after a full phone reboot. My hypothesis: When AccessorySetupKit is first used, a system daemon is spawned to handle AccessorySetupKit‑related tasks. After app deletion, this daemon is not properly terminated. Reinstalling the app later causes interference that breaks ASMigrationDisplayItem. This issue has blocked my development for a long time. I found a similar unresolved thread on Apple Developer Forums: https://developer.apple.com/forums/thread/839512 Questions: Is there any workaround I can adopt right now? Could Apple please investigate and fix this bug?

Dear Apple：I am developing an app and I would like to use Apple's AccessorySetupKit to complete the binding with an accessory. My accessory supports both Bluetooth and Wi-Fi Aware. I want to use AccessorySetupKit to complete both the Bluetooth pairing and the Wi-Fi Aware pairing with the accessory in one go. For Bluetooth, we also need to use the ANCS service, so the Bluetooth pairing requires a PIN code pop-up. However, we would like to skip this Bluetooth PIN code pairing, or combine it with the Wi-Fi Aware PIN code pairing into a single step. Is this possible under the current AccessorySetupKit framework? Because having the user confirm the PIN code twice does not seem like a great user experience. I would appreciate your help in answering this. Thank you.

We are seeing a cross-app session-isolation issue involving DeviceAccess / AccessorySetupKit and Accessory Notifications. Setup: Garmin Connect owns an authorized Forerunner 745. Our app owns an Amazfit Active 3 Premium and an Amazfit Bip Max. Both Amazfit devices have working NotificationsForwarding DAExtensionSession instances. Reproduction: Keep notification forwarding working for the Amazfit devices, then forget the Garmin Forerunner 745 in iOS Settings > Bluetooth. DeviceAccess correctly removes only the Garmin device and emits DeviceLost for Garmin DeviceID C175AA77-... (com.garmin.connect.mobile). In the same millisecond, usernotificationsd invalidates two unrelated NotificationsForwarding sessions: CID 0x2D07001D, DeviceID 13D01E46-..., BundleID com.huami.watch CID 0x2D07001C, DeviceID D86C37A0-..., BundleID com.huami.watch The second session belongs to Bip Max. About four seconds later, notifications fail with: post() failed: no connection hasExtensionSession: false Bip Max remains Authorized and BTPaired, and its DADevice and notification capability remain present. Only its usernotificationsd-held NotificationsForwarding DAExtensionSession is lost. usernotificationsd also logs AccessoryNotifications.AccessoryError Code=5 while clearing the Garmin accessory record. Should DeviceLost ever invalidate NotificationsForwarding sessions with a different DeviceID and owning app? Is there a supported way to rebuild the missing session without removing and re-authorizing the retained accessory? Timestamp: 2026-08-31 14:08:46.973 local time. Full identifiers, tokens, and logs are omitted; we can provide a sysdiagnose and log archive through Feedback Assistant.

Title: Multi-accessory DeviceAccess bugs: wrong PeripheralID in Transport wake-up; cross-device NotificationsForwarding session invalidation Topic: App & System Services → Core OS Tags: Core Bluetooth, AccessorySetupKit, Notifications Body: Context: our app uses AccessorySetupKit and a DeviceAccess-based accessory Transport + DataProvider extension pair (one shared extension bundle serves all accessories). Everything works with a single bound accessory, but with two or more ASK accessories on the same app we consistently hit two independent system-level failures. Both fail BEFORE any app callback runs (no DataProvider addNotification, no Transport messageReceived), so this is not app-side parsing or business logic. Tested on iPhone 11 Pro, current iOS 26 release; full logarchives available and can be attached to a Feedback Assistant case. Problem 1 — Transport wake-up requests use the wrong PeripheralID (uplink: watch reply → iPhone) Reproducible timeline from bluetoothd/deviceaccessd logs: Device A's GATT indication reaches bluetoothd; CoreBluetooth routes it to device A's CoreBluetooth session (its Transport PID). ~8 ms later, the DAExtensionRuntimeAssertion that bluetoothd sends to deviceaccessd carries device B's PeripheralID instead of device A's. deviceaccessd then resumes/updates device B's Transport. Device A's Transport stays suspended and never receives the data; the reply is lost. Two outcomes depending on whether the wrongly-used PeripheralID still resolves: Belongs to another still-bound accessory: the assertion "succeeds" and the wrong Transport instance is resumed — no error at all. Belongs to an already-removed accessory: DAErrorDomain 350002 "device not found". So the absence of error 350002 does not mean the mapping is correct. Re-authorizing the affected accessory via ASK does NOT repair the mapping: after re-ASK, notification delivery works again, but once the new Transport suspends, subsequent wake-ups still carry the other accessory's PeripheralID. Problem 2 — NotificationsForwarding DAExtensionSession lifecycle is not isolated per DeviceID (downlink: iPhone notification → watch) Expected: usernotificationsd holds one NotificationsForwarding DAExtensionSession per authorized accessory with notification forwarding enabled, strictly isolated by DeviceID. Observed instead: A session is "activated and stored" and then immediately invalidated by usernotificationsd itself, with no user action (four-accessory setup, three forwarding-capable). Any accessory's DeviceLost invalidates OTHER accessories' sessions. Logs show the event DeviceID differs from the invalidated session's DeviceID. This also happens when the removed accessory does not support notification forwarding at all (so there was no session of its own to clean up). After such mass invalidation, usernotificationsd may rebuild only some sessions or none — even when BLE, Transport, and DataProvider capability fully recover (e.g. after toggling Bluetooth). Notifications then stop at "post() failed: no connection (hasExtensionSession: false)". A new accessory's ASK DeviceFound triggers a rescan that rebuilds missing sessions for the older devices (consistent across our samples, but we don't know whether this is a stable contract). What we ruled out on our side: ASAccessorySession.removeAccessory is called with the correct target; nothing in the app touches other accessories' sessions or permissions. The failures happen inside system daemons before app callbacks; single-accessory flows work fine with identical code. Multiple DataProvider DAExtension records sharing one host PID behaved normally — expected ExtensionKit hosting, not the issue. Questions: Is the PeripheralID substitution in the bluetoothd → deviceaccessd DAExtensionRuntimeAssertion a known issue when one transport extension bundle serves multiple accessories? Any supported workaround? Should usernotificationsd session maintenance be strictly isolated by DeviceID? Is there a supported way to force-rebuild all NotificationsForwarding DAExtensionSessions without unbinding accessories? Is the DeviceFound-triggered full session rescan/rebuild a contract we may rely on? Happy to provide logarchives and detailed timelines via Feedback Assistant. Thanks!

I'm trying to explore accessory setup kit and migrate an existing CoreBluetooth-paired BLE device into AccessorySetupKit using ASMigrationDisplayItem. The regular ASPickerDisplayItem discovery picker works perfectly on the same device/session/Info.plist. But ASMigrationDisplayItem consistently fails. Code let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "0xFDEE") let migrationItem = ASMigrationDisplayItem( name: "HUAWEI FreeClip 2", productImage: productImage, descriptor: descriptor ) migrationItem.peripheralIdentifier = peripheralIdentifier // peripheralIdentifier is a valid CBPeripheral.identifier UUID // CBCentralManager is suspended before this call (suspendForASK) session?.showPicker(for: [migrationItem]) { error in // Completion is either called with error 500, or NEVER called (silent no-op) } Test Results (8 rounds) # Approach Result 1 suspendForASK → immediate showPicker Silent no-op 2 suspendForASK → 0.6s delay → showPicker Silent no-op 3 .activated event → showPicker (no CBManager exists yet) Silent no-op 4 viewDidAppear → 0.5s delay → showPicker Silent no-op 5 User taps alert button (explicit gesture context) → showPicker Silent no-op 6 Clear pickerDisplaySettings before migration showPicker Error 500 (pickerAlreadyActive) 7 invalidate() → activate() → immediate showPicker (fresh session) Silent no-op 8 invalidate() → activate() → wait for .activated → showPicker Silent no-op Round 6 logs (Error 500): [ASK] Starting migration for peripheral: D0F13212-**** Picker already activated ← System message [ASK] Migration picker failed: ASErrorDomain error 500. Round 8 logs (Silent no-op, cleanest test): XPC connection invalid ← System message [ASK] Session invalidated: no error [ASK] Session activated ← New session .activated [ASK] Executing pending migration showPicker after .activated // → NO pickerDidPresent, NO migrationComplete, NO completion callback, NO error, NO UI Ruled Out Info.plist — regular ASPickerDisplayItem works with identical config Session state — .activated confirmed, session non-nil CBManager conflict — suspended before migration; round 3 ran before any CBManager existed User gesture — round 5 inside button tap handler (same context as working picker) Timing — delayed to viewDidAppear, waited for .activated event peripheralIdentifier — valid UUID, device is actively connected via CoreBluetooth Questions Is ASMigrationDisplayItem fully functional on iOS 26.x? Across 8 different invocation patterns, it either returns error 500 or silently no-ops — no UI ever appears. What causes the residual "Picker already activated" state (error 500), and how do we properly reset it? The XPC connection invalid system message appears consistently. Does this indicate the daemon is rejecting the migration request? Are there prerequisites we're missing? E.g., must the device be disconnected from CB? Must NSBluetoothAlwaysUsageDescription be removed? Is there a different descriptor requirement for migration vs discovery?

Hello everyone, I need help about ASK. AccessorySetupKit: removeAccessory confirmation dialog displayed in English while device, app and ASK picker are localized in French. Area: AccessorySetupKit / Bluetooth Type: Incorrect/Unexpected Behavior iOS version: iOS 26.6 When calling ASAccessorySession.removeAccessory(_:completionHandler:), the system confirmation dialog ("Remove paired accessory? "MyAppXXX" is attempting to remove MyDevice.") is displayed in English, even though: The device language is French Locale.current.identifier = fr_FR The app's effective localization resolves to French Bundle.main.preferredLocalizations = ["fr"] The app bundle declares French Bundle.main.localizations = ["en", "es", "it", "fr", "nl"] developmentLocalization = "en" All other AccessorySetupKit UI is correctly localized: the ASK picker shown by showPicker(for:) and the pairing dialogs appear in French as expected. Only the remove-accessory confirmation dialog falls back to English. Issue is already open with Apple feedback Assistant: FB24306024 And also by Apple technical support 21587044 Thank you

When using AccessorySetupKit to remove accessories, a pop-up window appears when calling removeAccessory. However, the text in the pop-up window does not change according to my iPhone's language settings and remains only in English. Has anyone encountered this issue? Does Apple have any plans to address this compatibility issue?

I have an accessory which uses both Bluetooth and WiFi to communicate with the app. I am trying to migrate to Accessory Setup Kit. However, the API expects both the bluetooth identifiers and WIFI SSID or SSID prefix in the ASDiscoveryDescriptor. The problem is we only have the WIFI SSID after BLE pairing. Our current flow looks like this: Pair via BLE Connect via BLE Send a BLE command to request WIFI settings (SSID and password) (Each device has a different SSID and password) Connect to WI-FI hotspot by calling NEHotspotConfigurationManager applyConfiguration with the retrieved credentials. Is there a way to set the Wi-Fi SSID of an ASAccessory object after the initial setup? To use Accessory Setup Kit we would need something like this: Call Accessory Setup Kit with bluetooth identifiers in the descriptor, finish the setup and get ASAccessory object. Connect via BLE Send a BLE command to request WIFI settings (SSID and password) Set the SSID of the ASAccessory to the retrieved value. Connect to WI-FI hotspot by calling `NEHotspotConfigurationManager joinAccessoryHotspot. Thanks!

Dear Apple: 1、We want to create a socket application using the C language interface on the WiFi Aware channel, utilizing native socket APIs such as socket, connect, bind, etc., to transmit data through the established WiFi Aware channel. However, we wrote a demo and tested it. On the iOS side, when initiating a socket connect, we received error code 65. We also used the IPv6 protocol. We would like to ask for help: Is it impossible to use native socket APIs for programming on the WiFi Aware channel? 2、If native sockets are not available, which interfaces are recommended for WiFi Aware communication on iOS? Thanks.

1、I want to use AccessorySetupKit for Wi-Fi Aware pairing and connection, but on iOS 26.5, it prompts that this device does not support Wi-Fi Aware. However, it works normally after upgrading to iOS 27. I would like to confirm whether using Wi-Fi Aware with AccessorySetupKit requires iOS 27 or later? 2、When using AccessorySetupKit to perform PIN code pairing with an accessory via Wi-Fi Aware, is the PIN code only required for the first pairing, and not needed for subsequent connections? Does this PIN code have an expiration time?

We are currently investigating a serious issue related to Wi-Fi Aware and AccessorySetupKit. We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. After this happens, calling the following API fails: ASAccessorySession.showPicker(for:completionHandler:) API documentation: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession/showpicker(for:completionhandler:) The error returned is: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable.” Related logs: error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." 21:27:33.116061+0800 deviceaccessd Activating DASession: CID 0x7FC70001, BundleID xxxx, PID 542, WiFiAwareSupported: no 2026-05-26 21:27:33.118<103>21:27:33.118[E][WiFiAware::WA]@"":[ASK] showPicker callback error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." UserInfo={ NSDebugDescription=Current device is not Wi-Fi Aware capable., cuErrorMsg=Current device is not Wi-Fi Aware capable., NSLocalizedFailureReason=Current device is not Wi-Fi Aware capable. } Device information: Device: iPhone 16 Pro OS Version: 26.5 The device was previously able to use Wi-Fi Aware successfully. However, after the issue occurs, the system reports: WiFiAwareSupported: no The only known way to recover so far is to erase all content and settings / factory reset the device. This is not an acceptable workaround for end users and may cause a severe user experience issue. We would like to ask for your help with the following questions: Under what conditions would an iPhone that supports Wi-Fi Aware suddenly be reported as not Wi-Fi Aware capable? Is WiFiAwareSupported: no determined by hardware capability, system configuration, region setting, privacy/security policy, entitlement state, or some cached system state? Is there any known issue in AccessorySetupKit or Wi-Fi Aware on iOS 26.5 that could cause this behavior? Is there a way to recover the Wi-Fi Aware capability without requiring a factory reset? Are there any additional logs, sysdiagnose profiles, or diagnostic commands you recommend us to collect when this issue occurs? This issue is critical for us because users who encounter it will no longer be able to proceed with accessory setup, even though their device should support Wi-Fi Aware. Please let us know if you need a sysdiagnose, sample project, full device logs, or additional reproduction information. We would appreciate any guidance on the root cause and possible workaround.

Hello, I'm still investigating, so I could be mistaken. But as far as I can tell, if we create a CBCentralManager, and use it to scan for devices advertising Ranging Service, connect to them, and call the CoreBluetooth startChannelSounding() API, it does not work. I get a 'Operation not permitted' type of error. Instead, if I set up the device at least once using AccessorySetupKit, it does work. Will the need for AccessorySetupKit be removed? The thing is, AccessorySetupKit is not easy to play with. It seems to require no other part of the app to have an existing initialised CBCentralManager for it to do any kind of work, as the Channel Sounding code sample you provided attests to.

Summary We are observing that Wi-Fi Aware data transfer throughput on iPhone is heavily impacted by the device's Wi-Fi association state and by surrounding RF interference. When Wi-Fi is turned off from Control Center, Wi-Fi Aware throughput increases to roughly 2x (or higher) compared to when the device remains associated to a Wi-Fi network. We would like to confirm whether this is expected behavior or a system-level bug. Log Feedback ID: FB23454477 Environment Device: iPhone Feature under test: Wi-Fi Aware (NAN) data path transfer Steps to Reproduce Connect the iPhone to a Wi-Fi network (associate to an AP). Establish a Wi-Fi Aware (NAN) data-path session with a peer device. Start a sustained data transfer and measure the steady-state throughput. Repeat the measurement in two RF conditions: a. Clean RF environment (no other surrounding Wi-Fi/BLE devices nearby). b. Congested / high-interference RF environment. Turn Wi-Fi off from the Control Center pull-down menu (leave the peer/session as before). Repeat the same Wi-Fi Aware transfer and measure throughput again. Observed Behavior Scenario 1 — Wi-Fi connected (associated to an AP) Clean RF environment (Wi-Fi connected, no other surrounding Wi-Fi/BLE devices nearby): Wi-Fi Aware transfer throughput is approximately 20 MB/s. Congested / high-interference RF environment: Wi-Fi Aware transfer throughput drops to approximately 8 MB/s. Reference log: sysdiagnose_2026.06.28_21-05-09+0800_iPhone-OS_iPhone_23F81.tar.gz Scenario 2 — Wi-Fi turned off via Control Center After turning Wi-Fi off from the Control Center pull-down menu, the Wi-Fi Aware transfer throughput increases to 2x or higher compared to Scenario 1. Reference log: sysdiagnose_2026.06.28_21-15-00+0800_iPhone-OS_iPhone_23F81.tar.gz Expected Behavior Wi-Fi Aware throughput should not be significantly constrained by the device's Wi-Fi association state. We expect comparable Wi-Fi Aware performance regardless of whether the device is associated to a Wi-Fi network, since disabling Wi-Fi should not be required to achieve full Wi-Fi Aware data-path throughput. Questions for Apple Is the throughput reduction while associated to a Wi-Fi network expected behavior (e.g., due to time-sharing/channel scheduling between the infrastructure connection and the Wi-Fi Aware data path)? If this is by design, are there recommended APIs, configurations, or best practices to maintain higher Wi-Fi Aware throughput while the device remains connected to Wi-Fi? If this is not expected, we believe this is a system-level bug and would appreciate guidance on a fix or workaround.

Hi! I'm using AccessorySetupKit with CoreBluetooth state restoration. My understanding is that using AccessorySetupKit is a now pre-requisite to enabling the state restoration/preservation apis, so I went that route — and pairing, handoff, and restoration on search discovery or connection completion seem to be working Where I'm stuck: my accessory is poll-based. I read it by writing a request and reading the response. Then I send a new request. the BLE accessory never pushes data on its own. Since restoration only seems to wake my app on an inbound BLE event, if the app gets terminated mid-session while the connection's still healthy, nothing wakes the app and polling just quietly stops. Is there a recommended way to handle this for a request/response device? Thanks!

We noticed that in older OS versions the accessory picker would consistently display a peripheral's advertised friendly name on top of displaying information from the matching display item. While in newer OS versions we would mostly only see the name from the display item. Is there a way to configure this?

Hi there, we deploy upwards of 12-15 accessories (containing BLE) at a time, in a single system instal. Can AccessorySetupKit be used to streamline the pairing process for all of these accessories at once, so that the user isn't required to step through the process for each individual accessory?

Hi there, we deploy upwards of 12-15 hardware accessories containing BLE at a time, in a single system instal. Can AccessorySetupKit be used to streamline the pairing process for all of these accessories at once, so that the user isn't required to step through the process of pairing with each individual accessory?

I forget which extension type it is, but there is one that can discover the devices in a sandbox. Xcode 26 shows me Media Device Discovery, Xcode 27 doesn't. It could be a different one. Which ever one it is, do you know off hand if the new StateReporting framework would report performance and usage privately to MetricKit? I know that some frameworks report data to Apple's analytics reports, I'd potentially want to capture some performance metrics and app state changes that are happening in supporting extensions.

Hello, Currently we have the sample project from WWDC2024 as an example on how to do it as a live example but only as a simulated project on the Accessory end. The example is good but being implemented a rich platform like iOS or iPadOS, the rich stack of APIs are provided. Embedded devices such as the ESP32/RaspberryPI do not have this rich API stack, such as CoreBluetooth and so on, so a mirror stack of API/functions must be implemented to give the equal experience. Are there any examples or design/technical guidelines for the Accessory end to implement AccessorySetupKit on embedded devices. (Like a list of technical requirements or checklist of functions/implementations/services we can go through on a ESP32/RapberryPI) to ensure that the Accessory has all the needed code/technical implementations with AccessorySetupKit for both Bluetooth and WiFi support, especially on the Bluetooth end. Best to have an ESP32 project, implemented in Embedded Swift but at least a checklist (of items/situations/error handling) to confirm that it works.