BLE scanning on iPhone: what iOS shows you and what it hides
An iPhone has the same Bluetooth Low Energy radio as any other modern phone, and it receives every advertisement in range. What differs is how much of that iOS is willing to hand to an app. The answer is: most of it, minus the one field people most often go looking for.
This guide covers what you can actually do with a BLE scanner on iOS, the limits that trip people up, and when you need a different device.
The big one: iOS hides Bluetooth addresses
On Android, a scan result includes the device's Bluetooth address. On iOS, it never does. Apple's Core Bluetooth framework does not expose the hardware address of a peripheral to apps — not obscured, not permission-gated, simply absent.
What you get instead is a CBPeripheral identifier, a UUID that iOS generates to stand in for the device. It's a real, usable handle, but understand its properties:
- It's per-app. The same physical device shows a different identifier in every app on your phone. You cannot compare a UUID from one scanner against one from another.
- It's per-device. Your iPhone and your iPad see different identifiers for the same peripheral.
- It isn't permanent. It can change — after unpairing, or when the peripheral rotates its underlying private address in ways iOS can't resolve.
This is a deliberate privacy decision, and it's the single largest functional gap between iOS and Android for scanning work. Any workflow that depends on a stable hardware address — correlating a device across sessions, checking an OUI against the IEEE registry, exporting addresses for analysis — cannot be done from an iPhone.
What iOS does give you
Quite a lot, actually. Core Bluetooth passes through most of the advertisement:
- Local name, when the device broadcasts one.
- Service UUIDs, both the 16-bit SIG-assigned ones and 128-bit vendor UUIDs.
- Manufacturer-specific data, including the company identifier — so you can still identify the vendor and decode payloads.
- Service data keyed by UUID.
- TX power level, when advertised.
- RSSI, updated as the device is re-observed.
That's enough for a great deal of real work: identifying what a device is, decoding beacon payloads, checking whether your own firmware advertises correctly, and gauging proximity from signal strength. Everything in our advertisement format guide applies on iOS too — you're reading the same packets, just without the address field.
The other iOS restrictions worth knowing
Background scanning is limited. In the foreground an app can scan for everything. In the background, iOS requires the app to name the specific service UUIDs it's looking for — there's no wildcard "show me everything nearby" scanning while the app is backgrounded. Discovery rates also slow considerably. This is why iOS scanner apps generally want to stay open and on screen.
Duplicate advertisements are filtered by default. iOS coalesces repeat advertisements from the same device unless an app explicitly opts out, and that opt-out doesn't work in the background. It matters if you're trying to watch a payload change over time.
Classic Bluetooth is off-limits. Core Bluetooth is BLE only. Classic Bluetooth (BR/EDR) devices — most older audio gear — aren't visible to a scanner app at all. iOS reserves classic-device access for the MFi program.
No connection packet capture. Like Android, iOS gives apps no raw radio access, so no app can capture the traffic between two other devices. That needs dedicated hardware regardless of platform.
What the Settings app shows (and why it's not a scanner)
The Bluetooth pane in iOS Settings is not a scan of everything nearby. It lists paired devices and a filtered set of connectable ones that iOS thinks you might want to pair with. Beacons, sensors, trackers, and non-connectable broadcasters generally won't appear. If you want to see what's actually in the air, you need a scanner app, not Settings.
Scanner apps on iOS
Several apps expose Core Bluetooth's scan results directly — LightBlue and Nordic's nRF Connect are the long-standing ones, and both are free. They'll show you names, service UUIDs, manufacturer data, and RSSI, and let you connect to a peripheral and browse its GATT services.
Both are bound by the same platform limits above. No iOS app can show you a MAC address, because no iOS app is given one. If an app claims otherwise, it's showing you the CBPeripheral UUID with different labeling.
Capturing HCI logs from an iPhone
There is one way to get deeper on iOS, and it needs a Mac. Apple publishes a Bluetooth logging profile as part of the Additional Tools for Xcode; install it on the iPhone, reproduce the behavior you care about, and you can pull an HCI trace and open it in PacketLogger or Wireshark.
That gives you the packets your own iPhone sent and received, including connection traffic — the rough equivalent of Android's HCI snoop log. It's a developer workflow rather than a field tool, but for reverse-engineering how an iOS app talks to a gadget, it's the way.
iPhone vs. Android for BLE scanning
| iPhone | Android | |
|---|---|---|
| Bluetooth address | Hidden — per-app UUID only | Full address exposed |
| Manufacturer data | Yes | Yes |
| Service UUIDs | Yes | Yes |
| RSSI | Yes | Yes |
| Unrestricted background scan | No | Yes |
| Classic Bluetooth visibility | No | Yes |
| On-device HCI log without a computer | No | Yes (snoop log) |
| Connection packet capture | No | No |
Android is meaningfully better for this work, and the address field is the reason. If you're doing anything that involves tracking a device across sessions, exporting data for analysis, or looking up hardware manufacturers, an Android phone will do it and an iPhone will not.
BLE Sniffer for Android is our free Android scanner — addresses, manufacturer decoding, RSSI proximity radar, on-device session logging, and CSV export, with no ads and no telemetry. It's Android-only, and given the platform limits above, that's not an accident. If you're on iPhone, LightBlue or nRF Connect are the honest recommendations.
The takeaway
An iPhone is a capable BLE scanner for identifying devices, decoding advertisement payloads, and judging proximity — everything except the hardware address, which iOS withholds by design and substitutes with a per-app UUID. Add restricted background scanning and no classic-Bluetooth visibility, and iOS is the more constrained platform. For casual "what's broadcasting near me," it's fine. For analysis work that needs stable device identity, use Android.