VisionOS 27 Custom Spatial Accessories ASA Host Version remains 0.0

Question

Created 3w

Replies 5

Boosts 0

Participants 2

I am implementing a custom generic spatial accessory according to Section 20 of the Accessory Design Guidelines dated 2026-06-08. Apple Vision Pro discovers the accessory, completes BLE pairing and encryption, reads the Apple Spatial Accessory Version and Uniform Type Identifiers characteristics, and recognizes the device in the accessory tracking debug view. However, visionOS writes ASA protocol version 00.00 to the Apple Spatial Accessory Host Version characteristic instead of selecting version 01.01.

Here is the log message when I connected my spatial accessory with apple vision pro with os27 beta 3. The error is the ASA part.

BLE advertising: ZemScannerASA15; BLE ATT MTU tx=23,rx=23; BLE conn timing connected: interval=30000; us,latency=0,timeout=72; TimeSync anchor report enabled: h=0x011f; BLE connected TimeSync anchor #1 ce=0,int=30000,delay=0 TimeSync anchor #2 ce=3,int=30000,delay=0 TimeSync anchor #3 ce=4,int=30000,delay=0 BLE ATT MTU tx=293,rx=65 BLE security level 2 BLE pairing complete, bonded ASA version read #1 off=0 req=64 hex=02 01 01 01 01 ASA UTI read #2 off=0 req=64 total=49 ASA host wr #3 o=0 l=4 f=00 hex=00 00 01 31 ASA host raw: off=0,write=4,total=4,hex=00 00 01 31 ASA host version: >len=4,ver=0.0,features_len=1,features=0x31 ASA host selected no common protocol HID direct input report sent HID notif #4 report=3 enabled HID IMU stream started HID notif #5 report=2 enabled HID IMU report sent BLE conn params updated: interval=7500 us,latency=4,timeout=100

Answer 1

Vision Pro Engineer OP

Apple

3w

Hi @ZemLi,

Your Versions payload (02 01 01 01 01) parses correctly and advertises a single ASA protocol version, 1.1. Current visionOS 27 builds appear to support only ASA protocol version 1.0, so there is no overlap with what your accessory advertises, and your log reflects this with "ASA host selected no common protocol." This looks like a gap between the current Accessory Design Guidelines (which specify 1.1) and what visionOS 27 beta 3 has implemented.

A workaround worth trying: advertise 1.0 (payload 02 01 00 01 01).

To help us investigate, please file this via Feedback Assistant with a sysdiagnose captured shortly after reproducing, and reply here with the feedback number.

Answer 2

ZemLi OP

2w

Filed as FB23870886.

I tested the suggested ASA 1.0 version (02 01 00 01 01). visionOS reads the it twice but still writes Host Version 00 00 01 89. I attached a visionOS-originated sysdiagnose captured immediately after reproduction, and the complete accessory serial log.

Answer 3

Vision Pro Engineer OP

Apple

1w

@ZemLi I can confirm this is a known issue, and there is no known workaround at this time. If I learn of one, I'll follow up on this thread.

Answer 4

Vision Pro Engineer OP

Apple

1w

Hi @ZemLi

One workaround worth trying: update your accessory firmware so it does not gate operation on the host-selected version. Continue serving TimeSync, LED fast-blink, and IMU even when the value written back is unexpected.

Please let me know if that works!

Answer 5

Vision Pro Engineer OP

Apple

4d

@ZemLi

Thanks for the reply. Can you confirm that when you view the accessory through the debug view (as explained in Explore enhancements to visionOS object tracking around 10:20) the LEDs are lit?

Also, could you describe what the sample app displays? Specifically, which of these three does the app window show?

"No accessory connected"
"Unable to resolve the reference accessory"
The settings form with Accessory locations, Tracking mode, and Metrics

Finally, two things would help a lot if you can attach them to your existing Feedback Assistant report:

A new sysdiagnose captured while the app is running. Please launch the app with the accessory connected, leave it in the foreground for about 30 seconds, then trigger the sysdiagnose without closing the app. It's useful regardless of which of the three screens above the app displays. The previous sysdiagnose was captured during pairing with the app closed, so they don't contain the app side of the pipeline, and the logs we need age out quickly.
Your .referenceaccessory file. If you'd prefer not to share the full asset, the metadata.json and assets/*objectClass*/asset.json files from inside it are enough (it's a zip archive, so unzip -p Your.referenceaccessory 'assets/*objectClass*/asset.json' will pull that file out).