A phone that contains a Bluetooth radio is not automatically a reachable beacon client. The project still needs a receiving application or supported system API, permission handling, appropriate background execution and a backend that can interpret the identifiers. Treat each layer as a separate acceptance test.
Compatibility is a stack, not a yes-or-no feature
When a Bluetooth beacon broadcasts a packet, the mobile device receiving it must recognise the packet format, extract the identifiers and pass that data to an application or operating-system service. Whether that chain works depends on the beacon protocol, the device's operating system, the OS version and, in many cases, the presence of a specific app. "Protocol compatibility" is not a single yes-or-no question but a set of layered conditions that change between platforms and over time.
At the lowest level, modern beacon systems use Bluetooth Low Energy advertising, but a compatible radio does not by itself create a working visitor journey. Apple devices can use Core Location to monitor configured iBeacon regions, subject to permissions and operating-system behaviour. Eddystone is a legacy Google-originated frame family: compatible application code can still parse its packets, but Google Nearby Notifications and the former Physical Web discovery model are not current universal Android services. On iOS, non-iBeacon advertising frames normally require application-level Core Bluetooth handling and remain subject to foreground and background restrictions. The acceptance test must therefore cover the exact packet format, app or browser, operating-system versions, permissions and background state used by the project.
AltBeacon, an open specification maintained by the AltBeacon Alliance, has no native OS-level support on either platform. Detection always requires an app that includes an AltBeacon-compatible scanning library. This does not make AltBeacon inferior, but it does mean the deployment team must account for app adoption rates when estimating how many visitors' devices will actually detect the beacons.
Background detection is permission- and policy-dependent
The most consequential compatibility difference between iOS and Android is background scanning. iOS allows registered apps to monitor iBeacon regions in the background, but the OS throttles scan frequency to conserve battery and limits how often it wakes the app. The exact throttling behaviour has changed across iOS releases and is not publicly documented in detail, so assumptions made on one iOS version may not hold on the next. Android's background scanning behaviour depends on the manufacturer's battery optimisation settings, the Android version and whether Google Play Services is up to date. Some Android devices aggressively restrict background BLE scanning, which can reduce detection rates even when the protocol is technically supported.
Feature support matters more than version labels
Beacons themselves operate on specific BLE specification versions. A beacon advertising on BLE 5.0 with extended advertising or coded PHY will not be detected by a device whose radio only supports BLE 4.0 or 4.2. In practice, most commercial beacons default to legacy advertising modes that are backward-compatible, but if a deployment deliberately uses BLE 5.0 features for longer range or different PHYs, the compatible device pool shrinks. Check the beacon manufacturer's documentation for the default advertising mode and confirm whether changing it affects compatibility with older handsets.
Plan for iOS, Android and browser differences
Retail Environments With Mixed Device Populations
A UK retail deployment must assume a mixed population of iOS and Android devices, operating-system versions and permission states. An iBeacon journey still requires the retailer’s app or another supported receiver path, and Android detection depends on application code and background-execution behaviour. Do not use Eddystone-URL as a fallback for visitors without the app: the former Google notification journey is no longer a current general-purpose service. Use a clearly signed NFC or QR route when the experience must remain available without an installed app.
Museums and Visitor Attractions
Museums often want to minimise installation friction for occasional visitors. A controlled venue app may support beacon scanning, including legacy frames where the project has a reason to retain them, but a new app-free journey should not depend on Eddystone-URL notifications. Signed QR codes or NFC tags can provide an explicit fallback to the same mobile page. Test the full chain—including connectivity, destination security, readability and accessibility—rather than treating detection of a radio packet as completion of the visitor journey.
Events and Temporary Deployments
At conferences and exhibitions, attendees may be using corporate-managed devices with restricted BLE permissions or aggressive battery policies. If the event app relies on background beacon detection for session check-in or location-based alerts, compatibility testing should include devices with common mobile-device-management (MDM) profiles. It is not unusual for MDM policies to disable background BLE scanning entirely, which means the beacon protocol is compatible at the OS level but blocked by policy. Event organisers should clarify with their app developer whether the scanning implementation falls back gracefully when permissions are denied, rather than silently failing.
Web Bluetooth is opt-in and not a universal beacon scanner
Web Bluetooth allows a supporting browser to request access to selected Bluetooth devices, normally after a user gesture and permission prompt. It is experimental, unevenly supported and is not a universal passive scanner for beacon advertising packets. A proposed browser-based journey must be tested against the exact devices and browsers in scope, with NFC or QR available when the essential information cannot depend on that API.
Build and maintain a representative test matrix
Treating "Android" as a Single Platform
Android device fragmentation means that two phones running the same nominal Android version can behave differently depending on the manufacturer's firmware, battery optimisation layer and Google Play Services version. A beacon deployment tested on a Pixel device may show reliable background detection, while a Samsung or Huawei device with the same Android version may throttle scans more aggressively. Practical mitigation involves testing on a representative mix of devices commonly seen in the target visitor population, rather than relying on a single test handset.
Assuming iBeacon Works Identically on iOS and Android
iBeacon was designed by Apple and is deeply integrated into iOS region monitoring. On Android, iBeacon packets are visible to any BLE scanner, but there is no OS-level region-monitoring equivalent that works identically. An Android app using a beacon scanning library can detect iBeacon transmissions, but the background behaviour, wake-up frequency and battery impact will differ from the iOS implementation. If the project specification says "iBeacon compatible," confirm whether that means compatible with iOS region monitoring, compatible with Android app-based scanning, or both, because the engineering effort and expected detection rates are not the same.
Not Testing Against the OS Versions Visitors Actually Use
Development teams often test on the latest OS release, but visitor devices in real UK venues frequently run older versions. An iOS or Android update can change background scanning behaviour, permission defaults or BLE handling in ways that affect beacon detection. Before committing to a full deployment, check analytics from any existing app to identify the OS version distribution in the actual user base and include those versions in the compatibility test matrix.
Overlooking OS Update Risks
Both Apple and Google have altered BLE scanning behaviour in OS updates without prominent advance notice. A deployment that works reliably in March may show degraded detection after a September OS release. This is not a flaw in the beacon hardware but a consequence of relying on undocumented or semi-documented OS behaviour. The practical response is to include beacon detection rate as a monitored metric in ongoing operations, so that a post-update regression is detected quickly rather than discovered weeks later through declining campaign performance.
Key Checks Before Deployment
- Confirm which beacon protocol or protocols the deployment uses and whether each has native OS support or requires an app-based scanner on the target platforms.
- Verify the minimum BLE specification version required by the beacon's advertising mode and compare it against the oldest devices in the target visitor population.
- Test background detection on both iOS and Android, using multiple device manufacturers and the OS versions most common in your visitor analytics.
- If the plan mentions Eddystone-URL for app-free detection, replace that assumption with a tested application receiver or an explicit NFC/QR fallback; Google Nearby Notifications is not a current general-purpose discovery route.
- If Web Bluetooth is part of the architecture, verify browser support on each target platform and confirm that the user-interaction requirement is acceptable for the use case.
- Check whether any MDM policies or enterprise device configurations in your visitor or employee population could block BLE scanning.
- Document the exact OS versions, device models and app versions used in compatibility testing so that regressions can be attributed accurately.
Protocol compatibility is not a one-time checkbox. It is a conditional relationship between the beacon's broadcast format, the device's hardware and OS, the user's permission and battery settings, and the presence or absence of an app. Understanding those conditions before deployment prevents the common situation where beacons are installed and powered on, but a meaningful share of visitor devices never detect them.
Minimum release test
- Test current and older supported iOS and Android versions on representative low- and high-end devices.
- Test first launch, permission refusal, permission withdrawal, Bluetooth disabled, power-saving mode, app termination and device restart.
- Confirm what happens when the app is not installed or the browser does not expose Web Bluetooth.
- Retest after material operating-system and SDK updates.
