BLE Sniffer on Android vs. iOS: why the two apps differ
Both phones in your pocket have the same kind of Bluetooth Low Energy radio, and both receive every advertisement in range. The packets in the air are identical no matter what you're holding. What changes between Android and iOS is how much of each packet the operating system is willing to hand to an app — and on that question, the two platforms disagree sharply.
If you've used BLE Sniffer on Android and then opened it on an iPhone, you'll notice the iOS version is missing a couple of things. This guide explains exactly what differs, and why. The short version: every gap is a decision Apple made about Core Bluetooth, not a corner the app cut.
The differences at a glance
| Feature | Android | iOS |
|---|---|---|
| Bluetooth (MAC) address | Shown in full | Never available — per-app UUID only |
| Background scanning | Optional "keep scanning in background" | Foreground only for general scanning |
| Vendor identification | Company ID from manufacturer data | Company ID from manufacturer data |
| Manufacturer & service data | Yes | Yes |
| RSSI / proximity radar | Yes | Yes |
| GPS location tagging | Yes | Yes |
| Classic Bluetooth (BR/EDR) | Out of scope — BLE only | Out of scope — BLE only |
| Raw connection capture | No | No |
Two rows carry almost all the practical weight: the address and background scanning. The rest is identical across platforms, and the last two rows are the same "no" on both. Those two are worth explaining properly rather than waving at.
Why iOS hides the Bluetooth address
On Android, a scan result includes the device's Bluetooth address — the 48-bit hardware identifier, the same kind of thing as an Ethernet MAC. On iOS, it is never present. Apple's Core Bluetooth framework does not expose a peripheral's hardware address to apps at all: not obscured, not gated behind a permission, simply absent from the data an app receives.
What iOS gives you instead is a CBPeripheral identifier — a UUID that iOS generates to stand in for the device. It's a usable handle for talking to that peripheral, but it has three properties that make it a poor substitute for an address:
- It's per-app. The same physical device shows a different identifier in every app on the phone. A UUID from BLE Sniffer means nothing to any other scanner.
- It's per-device. Your iPhone and your iPad generate 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 a way iOS can't resolve.
This is a deliberate privacy design, and it's the same instinct behind address randomization: a permanent, broadcast hardware identifier is a tracking beacon, so Apple refuses to give apps a stable one. The consequence for scanning work is concrete. On iOS you cannot correlate a device across apps or sessions, you cannot look up a vendor by MAC OUI, and you cannot export a list of addresses. Android can do all three; iOS structurally cannot.
How the app identifies vendors without a MAC
Because iOS has no MAC address, the usual OUI lookup — matching the first three bytes of the address against the IEEE registry — is impossible there. So BLE Sniffer doesn't use it on either platform. Instead it reads the 2-byte Bluetooth SIG company identifier from the start of the manufacturer-specific data, which the device firmware sets itself and every scanner receives regardless of OS. That's why the vendor name shows up the same on both platforms even though only one of them has a MAC to work from. The mechanics of that field are in how BLE advertising works.
Why iOS won't scan in the background
On Android, BLE Sniffer offers a "keep scanning in the background" toggle. Turn it on and the scan keeps running when you switch apps or lock the screen; it does this by running a Bluetooth foreground service, which is why a persistent notification stays up while it's active. That notification isn't decoration — it's Android's requirement for letting an app hold the radio open in the background, and the app is being an honest citizen by showing it.
iOS does not allow the equivalent. Core Bluetooth permits background operation, but on terms that make a general "see everything nearby" scan impossible once the app leaves the foreground:
- No wildcard scan. A foreground app can scan for every advertiser in range. A backgrounded one must name the specific service UUIDs it's interested in — there is no "show me everything" mode in the background.
- Duplicates are filtered. iOS coalesces repeat advertisements from the same device, and the opt-out that a foreground app can use to see every packet doesn't apply in the background.
- Discovery slows down. iOS throttles background scanning to save power, so even the devices you did name for come in far more slowly.
Put together, that means a passive "log everything around me" scan is effectively a foreground activity on iOS. This is the single biggest day-to-day difference between the two versions of the app: on Android you can start a scan and put the phone in your pocket; on iOS you keep the app open and on screen. It's not a missing feature — it's a platform iOS doesn't offer.
What's identical on both
It's easy to read the two sections above and conclude iOS is crippled. It isn't. Everything that makes a device identifiable and its payload readable is present on both platforms, because it all lives in the advertisement itself rather than in OS-added metadata:
- Local name, when the device broadcasts one.
- Service UUIDs, both 16-bit SIG-assigned and 128-bit vendor UUIDs.
- Manufacturer-specific data, including the company identifier for vendor lookup and whatever payload the vendor packs after it.
- Service data keyed by UUID.
- TX power level, when advertised.
- RSSI, updated as the device is re-observed.
That's enough to identify what a device is, decode a beacon or sensor payload byte by byte, verify your own firmware advertises correctly, and gauge proximity from signal strength. The proximity radar and GPS location tagging both work on iOS exactly as they do on Android — the only condition is that the app is open, which the background limit above already requires. Anything in the iPhone scanning guide applies here too: you're reading the same packets, just without the address field.
What neither phone can do
A couple of limits aren't about Android versus iOS at all — they're true of any phone.
Classic Bluetooth is out of scope. BLE Sniffer is a BLE tool on both platforms. Classic Bluetooth (BR/EDR) devices — most older audio gear — aren't part of what it scans for.
No raw connection capture. Neither Android nor iOS gives an app raw radio access, so no phone app can capture the traffic flowing between two other devices. Watching a live connection at the packet level needs dedicated hardware regardless of which phone you own.
Which one should you use?
If you only have one phone, use it — the iOS app is fully capable for the most common jobs: identifying what's broadcasting near you, decoding advertisement payloads, and judging proximity on the radar. Nothing about "iOS hides the address" stops any of that.
If you have a choice and your work involves the address — tracking a device across sessions, exporting addresses for analysis, or looking up hardware vendors by OUI — reach for Android, because iOS structurally cannot provide it. Likewise if you want a scan to keep running while the phone's in your pocket.
Neither version is broken or half-finished. They differ because Android and iOS made different calls about what a BLE app is allowed to see, and BLE Sniffer surfaces exactly what each platform provides — no more, and no less.