Hi Apple Developer Support, I have performed additional experiments to investigate whether AccessoryControlDevice.current(for:) and update(_:) can be used from a custom ExtensionFoundation extension. The results have helped narrow down the issue. 1. Host app registration succeeds The host app successfully obtains the accessory from its AccessorySetupKit session and registers the placement capability: try await AccessoryControlDevice.register( accessory, capabilities: [.placement] )Log: [ASK] AAK 步骤0 ASK配件 id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568 name=Buds Pro 2 inSession=true sessionCount=1 placement=inEar state=authorized source=session.accessories sessionActivated=true caps=placement [ASK] AAK 步骤1(主App) register 成功 placement=inEar id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568The registration call completes successfully. 2. Custom ExtensionFoundation extension launches successfully I created a custom extension point using: AppExtensionPoint.Definition AppExtensionPoint.Bind AppExtensionPoint.Monitor AppExtensionProcess The host app successfully discovers the extension and launches it. Logs: [ASK][PLC] 扩展点构造成功 id=com.nothing.smartcenter.placement [ASK][PLC] Monitor 结果 identities=1 stateIdentities=1 unapproved=0 disabled=0 [ASK][PLC] 发现扩展 bundle=com.nothing.smartcenter.placement point=com.nothing.smartcenter.placement [ASK][PLC] AppExtensionProcess 创建成功 [ASK][PLC] XPCSession 创建成功 [ASK][PLC] XPCSession activate 成功 [ASK][PLC] sendSync 成功 —— 扩展已响应，进程确实起来了Therefore, the custom extension is installed, discovered, launched, and able to communicate with the host app through XPC. 3. AccessoryControlDevice.current(for:) still fails inside the extension Inside the running extension, I obtain the accessory from its AccessorySetupKit session. The session contains one accessory. However, calling: let device = try await AccessoryControlDevice.current( for: accessory )consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedLogs: [ASK][PLC] 实验3-current 请求已送达 op=probe worn=false [ASK][PLC] e3 扩展回传： ask-session 复用 count=1 [ASK][PLC] e3 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe same result occurs when attempting the placement update experiment: [ASK][PLC] 实验4-offHead 请求已送达 [ASK][PLC] e4off 扩展回传： ask-session 复用 count=1 [ASK][PLC] e4off 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedBecause current(for:) fails, I have not yet been able to verify whether update(_:) itself works. 4. Questions for Apple I would appreciate clarification on the following points: Does AudioAccessoryKit support custom ExtensionFoundation extensions? Specifically, are extensions created using AppExtensionPoint.Definition and AppExtensionPoint.Bind, and launched through AppExtensionPoint.Monitor and AppExtensionProcess, considered valid app extensions for AudioAccessoryKit? Does AccessoryControlDevice.current(for:) require a specific system-defined extension point or extension type, rather than a custom extension point? Does AudioAccessoryKit require any additional entitlement, capability, extension configuration, or authorization for current(for:) to succeed? Is the ASAccessory instance required by current(for:) expected to be obtained from the same ASK session used by the host app during register(), or can the extension obtain the accessory from its own ASK session? What does AccessoryControlDevice.Error.invalidated / Request invalidated specifically indicate in this situation? Is there a way to obtain more diagnostic information about why the request was invalidated? Is there an official sample project demonstrating the complete integration of AccessorySetupKit, AudioAccessoryKit placement updates, and the required app extension? Environment iOS: 26.4 Accessory: Nothing Ear / Buds Pro 2 (internal model B172) Frameworks: AccessorySetupKit, AudioAccessoryKit, ExtensionFoundation, CoreBluetooth Host app bundle ID: com.nothing.smartcenter Custom extension point: com.nothing.smartcenter.placement At this point, BLE communication, AccessorySetupKit pairing, host-side AudioAccessoryKit registration, extension discovery, extension process launch, and XPC communication are all working. The remaining blocker is that AccessoryControlDevice.current(for:) returns Request invalidated even when called inside the successfully running custom extension. Could you please clarify whether this custom ExtensionFoundation architecture is supported by AudioAccessoryKit, or whether a specific Apple-defined extension type is required? Thank you for your help.

Hi everyone, I'm developing a third-party Bluetooth audio accessory and investigating AudioAccessoryKit placement updates on iOS 26.4. My goal is to update the accessory's wearing state (for example, .inEar / .offHead) based on BLE notifications from the accessory. Implementation flow Pair the Bluetooth accessory using AccessorySetupKit. Obtain the paired ASAccessory. Register the accessory in the host app: try await AccessoryControlDevice.register( accessory, capabilities: [.audioSwitching, .placement] )Attempt to retrieve the registered device: let device = try await AccessoryControlDevice.current(for: accessory)However, current(for:) consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedBLE communication status The BLE communication itself appears to be successful. The following logs show that the command was sent and the accessory returned a response: [ASK] cmd didWrite ok 68745353-1810-4B13-83A2-C1B21B652C9B notifying=false [ASK] cmd toSend mac=2a:e6:e7:eb:be:2c model=B172 bytes=5560014FC000000F status=connected shaking=false [ASK] cmd write direct mac=2a:e6:e7:eb:be:2c bytes=5560014FC000000F chars=10 peripheral=2 delegate=Optional<CBPeripheralDelegate> connected=connected [ASK] cmd reply ok uuid=CA235943-1810-45E6-8326-FC8CA3BC45CE bytes=5560014F4001000F [ASK][PLC] Experiment 4 - inEar request delivered, op=update worn=true [ASK][PLC] Experiment 4 - inEar current baseline: current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe BLE command is successfully delivered to the accessory, and the accessory responds. However, the AudioAccessoryKit API still returns invalidated. Questions Does AccessoryControlDevice.current(for:) require a specific app extension context, entitlement, or authorization? Is it expected to call current(for:) from the host app, or must it be called from an app extension? Does registering .placement and .audioSwitching in the host app guarantee that the accessory can subsequently be retrieved using current(for:)? Are there any additional requirements for the accessory, firmware, or system-side registration before current(for:) can succeed? Is there a known issue with AccessoryControlDevice.current(for:) returning Error.invalidated on iOS 26.4? I understand that AccessoryControlDevice.update(_:) is documented as an API that must only be called from an app extension. I'm trying to determine whether the failure of current(for:) in the host app is expected behavior or indicates a registration/configuration problem. Any sample code, implementation guidance, or clarification from Apple engineers would be greatly appreciated. Thanks!

Hello Apple Developer Forums, We are developing an iOS companion app that supports multiple Bluetooth earbud products, and we are evaluating AccessorySetupKit for one specific product family. Our current product situation is: EU: Earbud A → AccessorySetupKit Earbud B → legacy CoreBluetooth discovery Earbud C → legacy CoreBluetooth discovery Earbud D → legacy CoreBluetooth discovery Earbud E → legacy CoreBluetooth discovery Non-EU: Earbud A → legacy CoreBluetooth discovery Earbud B → legacy CoreBluetooth discovery Earbud C → legacy CoreBluetooth discovery Earbud D → legacy CoreBluetooth discovery Earbud E → legacy CoreBluetooth discovery Only Earbud A needs to adopt AccessorySetupKit. The other four products are existing products and need to keep their current CoreBluetooth discovery and authentication flow. According to Apple's AccessorySetupKit documentation, an app using AccessorySetupKit needs to declare: <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> Apple's documentation also describes AccessorySetupKit as the mechanism for discovering and configuring Bluetooth accessories: https://developer.apple.com/documentation/accessorysetupkit/discovering-and-configuring-accessories Our concern is the interaction between this declaration and the existing CoreBluetooth discovery flow. For the AccessorySetupKit-managed product, the intended flow is: ASAccessorySession ↓ Accessory Picker ↓ User authorization ↓ CoreBluetooth communication For the other existing products, we need to retain: CBCentralManager ↓ scanForPeripherals() ↓ Discover nearby peripheral ↓ User selects device ↓ Existing authentication / binding flow We understand from Apple's WWDC24 AccessorySetupKit session that once AccessorySetupKit is involved, CoreBluetooth scanning is subject to the AccessorySetupKit authorization model. This raises an important compatibility question for us. If the application declares: <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> but only one product family is intended to use AccessorySetupKit, can the same application continue to perform unrestricted CoreBluetooth discovery for the other four legacy Bluetooth products? For example: Nearby: Earbud A → ASK-managed Earbud B → legacy Earbud C → legacy Expected: ASK Picker → Earbud A CBCentralManager.scanForPeripherals() → Earbud B → Earbud C Or does declaring NSAccessorySetupKitSupports = Bluetooth cause CoreBluetooth discovery to be restricted to accessories that have already been authorized through AccessorySetupKit? We are particularly concerned about first-time discovery of a legacy accessory: User upgrades the app ↓ Earbud B has never been authorized through AccessorySetupKit ↓ Earbud B is nearby ↓ The app needs to discover Earbud B for the first time ↓ Existing CBCentralManager discovery flow If CoreBluetooth discovery is restricted after AccessorySetupKit is enabled, we don't see how the app can discover this new legacy accessory in order to continue using the existing flow. We are aware of ASMigrationDisplayItem and the AccessorySetupKit migration mechanism for existing Bluetooth accessories. However, migration appears to require an already-known peripheral identifier, so we are unsure how this applies to a new legacy accessory that has never been discovered or authorized through AccessorySetupKit. Questions Is it officially supported for one application to use AccessorySetupKit for only one Bluetooth product family while continuing unrestricted CoreBluetooth discovery for other Bluetooth product families? If yes, what is the recommended architecture/API configuration? Does NSAccessorySetupKitSupports = Bluetooth affect CoreBluetooth discovery globally for the application, or can its effect be limited to specific accessory families through ASDiscoveryDescriptor? How should an application discover a new, previously unauthorized legacy Bluetooth accessory after AccessorySetupKit has been enabled? Is there an Apple-recommended migration strategy for an application that has multiple existing Bluetooth product families, where only one product family is required to adopt AccessorySetupKit? Any clarification from Apple on the officially supported architecture would be greatly appreciated. Thank you.