USB Bluetooth Adapter for Mac: The Allowlist in bluetoothd

I don't own a USB Bluetooth adapter, so nothing below comes from plugging one in. What I have is the program that decides whether macOS will use one. On macOS 26.4.1 that decision is not in a driver's Info.plist, where I found the answer for USB serial adapters and 10GbE adapters this week. It is compiled into /usr/sbin/bluetoothd. So I disassembled the function that logs Found_USB_Dongle and read the checks it makes on the dongle's USB IDs.

The machine is the Mac mini that runs this business (Mac16,10, M4), build 25E253. Its own radio is a Broadcom BCM_4388C2 on PCIe, per system_profiler SPBluetoothDataType. The binary is universal. I read the arm64e slice first, then confirmed the x86_64 slice makes the same checks.

The kernel no longer matches Bluetooth dongles

Up to Big Sur, macOS matched Bluetooth dongles by ID in kernel extensions like BroadcomBluetoothHostControllerUSBTransport, which is why Hackintosh users could add an ID with an injector kext. That stopped with macOS 12. In the Acidanthera tracker thread on Monterey Bluetooth, a contributor noted in June 2021 that the transport's provider class "has changed from IOUSBHostDevice to IOResources and doesn't have the list of devices in the Info.plist like it previously did."

On 26.4.1 that's still the case. IOBluetoothFamily.kext has three personalities. One tags Apple-vendor USB devices, one attaches to IOResources, and one merges properties into a 2013 Mac Pro's internal hub (0a5c:4500). None of them matches a USB Bluetooth controller by class or ID. The list moved into user space, and plists no longer show it.

What bluetoothd accepts

The dongle check sits at 0x1000e796c in the arm64e slice. It walks every IOUSBHostDevice and applies these tests in order:

The class test compares against 0xE0 and then a bitmask, 0x80008001, that lets through 0xE0 (wireless controller), 0xEF (miscellaneous, for composite devices) and 0xFF (vendor-specific). Two IDs are then skipped by name: Apple's USB-C to 3.5mm headphone adapter (05ac:110a) and a Texas Instruments part (0451:3410). After that comes the part that matters to a buyer.

Realtek (0bda) and Intel (8087) appear nowhere in the check, and neither do the cheap Jieli-based dongles. The one exception is a single Realtek-based product, and it passes because of its ASUS ID. Everything outside those three vendor codes and eight exact IDs gets a log line ending in Not in supported list.

Three findings that contradict the usual advice

ASUS says the BT500 doesn't support macOS. bluetoothd names it. On Best Buy's product Q&A, the answer from the ASUS Answers account is that the adapter "works with Windows and Linux, but it doesn't support macOS" (thread). Yet 0b05:190e is the only non-Broadcom, non-CSR ID in the gate, checked with its own pair of xor instructions in the x86_64 build. I can't tell you the BT500 works, because I didn't test one. What I can say is that on 26.4.1 it isn't turned away at the ID check, and every other Realtek dongle is.

The MediaTek entries are a dead end on a stock Mac. A dongle in the seven-entry table is accepted and handed to a MediaTek loader. The loader looks for BT_RAM_CODE_MT7922 under /etc/bluetool/ and otherwise logs please assign a rom patch(/etc/bluetool/%s). That directory doesn't exist on this Mac. /usr/share/firmware/bluetooth holds 141 files, and none are for the MT7922. Three are for an MT7932, which the table doesn't list. The table is labeled "BAM supported list" in the log string, which reads like internal test hardware rather than something meant for customers.

The vendor gate is the same one Hackintosh tools patch out. Acidanthera's BlueToolFixup, which its README says is "Required for macOS 12 or newer", looks for the bytes 81 FA 5C 0A 00 00 74 (compare with 0x0a5c, branch if equal) and rewrites the branch as an unconditional jump. Those exact bytes are at 0x1000e98e8 in my x86_64 slice. The patch skips the vendor check, so every class-E0 dongle gets through. On a Hackintosh, that patch is what "use any dongle" means. Its byte patterns are all x86_64 code, and its source has no arm64e counterpart, so on an Apple Silicon Mac the list above is the limit.

Checking a dongle before you rely on it

Plug it in and read its IDs. On macOS 26 the System Information data type is SPUSBHostDataType, and ioreg gives the numbers in decimal:

system_profiler SPUSBHostDataType | grep -E "Vendor ID|Product ID"
ioreg -p IOUSB -l -w0 | grep -E '"idVendor"|"idProduct"|"USB Product Name"'
# 0a5c = 2652, 0a12 = 2578, 0b05 = 2821

If the vendor is Broadcom or CSR, the dongle clears the ID check. Getting macOS to use it instead of the internal radio is a separate step, and the same binary names the switch: an NVRAM variable, bluetoothHostControllerSwitchBehavior, with values always and never (anything else is logged as default). The usual command is sudo nvram bluetoothHostControllerSwitchBehavior=always followed by a restart.

Owners report two failure modes. In an Apple Community thread from July 2020, a 2018 Mac mini owner set always for an IOGEAR GBU521, a Broadcom dongle with ID 0a5c:21e8 per a BrcmPatchRAM issue. After unplugging it, they couldn't get their devices back on the internal radio. The fix offered was sudo nvram -d bluetoothHostControllerSwitchBehavior, since the variable stays set until it's deleted. In another thread, a Leoxsys LB4 showed up in System Report as "JL AC60" but never appeared as a controller, and nobody posted a fix. That fits the gate, since Jieli's vendor ID isn't on it. The gate isn't new in spirit. A 2014 Hacker News comment about Continuity put it as "Apple chose to not support third-party Bluetooth LE dongles."

One more thing on my own machine is worth knowing. nvram -p on this M4 shows bluetoothExternalDongleFailed set to 00 and a bluetoothInternalControllerInfo entry. Those are the same two variables the BrcmPatchRAM README tells Hackintosh users to create by hand, and bluetoothd contains the code that writes them. The external-dongle logic exists on Apple Silicon and has recorded state on this Mac. Whether always actually switches an M4 over to a Broadcom dongle is the one thing a dongle would settle, and I haven't tested it.

What this means if you're buying one

A USB Bluetooth adapter for a Mac is a narrower purchase than a "Mac compatible" line on a listing suggests. Dongles built on Realtek, Intel or Jieli chips are turned away at the ID check, whatever the box says. What gets through is Broadcom and CSR silicon, plus one ASUS model that ASUS itself says doesn't support macOS. The check reads only the ID, so a dongle reporting 0a12 passes it whether or not the chip inside is a genuine CSR part. Read the IDs after it arrives, and return it if they're wrong.

For a headless machine like this one, the reason people want a dongle is usually range or a dead internal radio. Setting up a Mac mini without a monitor covers running one with no local keyboard or display at all. If the dongle is going into a hub, powered vs unpowered USB hubs covers the 150 mA per port catch. The 2.5GbE USB adapter allowlist is the same kind of check done on Ethernet.

Method: I read /usr/sbin/bluetoothd (23,589,488 bytes, universal x86_64 and arm64e) from macOS 26.4.1 (25E253) on a Mac mini (Mac16,10) on 2026-09-19. I found the dongle function by locating the ADRP/ADD pair that loads the string "in BAM supported list", disassembled it with the system objdump, and read the seven-entry table from __DATA. The x86_64 slice was checked for the same constants and table. The disassembly excerpt, string excerpt and binary hash are in our research folder. Chip names come from the ID tables in Linux's drivers/bluetooth/btusb.c on the master branch, fetched the same day. The BlueToolFixup byte pattern comes from its source in the BrcmPatchRAM repository. Owner reports are two Apple Community threads, a Best Buy Q&A answer and one Hacker News comment. A tonymacx86 thread on the BT500 returned 403, so it isn't cited. I own no USB Bluetooth adapter. Nothing here was tested with hardware, and this post has no product links.