Purpose

Some customers want to use a mobile app on iOS or Android to receive Bluetooth beacon broadcasts in the background, instead of deploying a dedicated Bluetooth gateway. In this paper, we evaluate whether that approach is technically feasible for Lansitec beacon-based monitoring, especially for devices such as the B002 Bluetooth Label and B005 Bluetooth Beacon. The question is not whether a phone can detect a beacon at all. It can. The real question is whether a phone app can do it reliably in the background, over time, and with enough consistency to replace a gateway.

Our view is simple: it is feasible in some cases, but only under the right conditions. For ordinary consumer phones and casually used apps, the approach is usually not reliable enough to be considered a full substitute for a dedicated gateway.

The target use case

The requested architecture is straightforward on paper. A B002 or B005 beacon advertises BLE data at a configured interval. A phone running the customer’s app scans for those advertisements, reads the beacon ID and signal strength, and uploads the detection event to the server.

That fits the capabilities of Lansitec beacons. The B002 is an ultra-thin BLE label based on iBeacon, with configurable advertisement intervals from 100 ms to 10 s and a line-of-sight transmission distance listed as 150 m. The B005 is a more rugged IP68 beacon with configurable intervals, optional AoA support, and the same listed 150 m line-of-sight range.

So the problem lies not in the beacon side but the phone side.

Why is this different from the normal Lansitec model

In Lansitec’s B-Mobile solution, Bluetooth gateways are deployed at fixed locations. Beacons advertise periodically, gateways receive the data, and the server calculates or interprets the location based on the known positions of those gateways. The same documents also note that gateway reception is effectively always on in the intended deployment model, and that RSSI can vary because of walls, interference, and multipath effects.

Having the app in this place changes the whole solution design.

A fixed gateway gives you three things a normal phone does not:

• a known physical position
• stable power behavior
• predictable receive availability

This is the first caveat we would put in front of any customer. Even if the app hears the beacon, a moving phone is not functionally equivalent to a mounted gateway.

iOS feasibility

On iOS, Bluetooth work in the background is possible, but constrained. Apple states that foreground-only apps cannot scan for and discover advertising peripherals while in the background or while suspended. Apps that declare the Bluetooth-central background mode can still discover and connect to peripherals in the background, but background scanning behaves differently: duplicate discoveries are coalesced, and scanning intervals may increase, which means discovery can take longer. Apple also says apps woken for Bluetooth events should finish quickly, and notes roughly 10 seconds for background work before suspension pressure becomes a problem. ⁽¹⁾

There is one useful iOS workaround: beacon region monitoring. Apple’s Core Location framework can monitor iBeacon regions and wake the app on entry or exit events. But there are tradeoffs. Apple limits region monitoring to 20 regions per app, and explicitly recommends beacon ranging only while the app is in the foreground. ⁽²⁾

So what does that mean in practice?

For iOS, an app can support beacon-related background behavior, especially coarse “entered region / exited region” workflows. But it is not a good platform for continuous, gateway-like passive scanning across a broad deployment. If the customer wants an always-listening phone that silently acts like infrastructure, iOS is the weak option.

Android feasibility

Android is more flexible, but it is not magic. Google’s current developer guidance says background BLE communication is possible, yet the app process needs to stay alive. If the process is killed, connections are closed. Google also notes that unfiltered scans are stopped when the screen turns off, and resumed when the screen turns on, unless filtered scanning is used.

For background use, Android documents several paths: scanning with a PendingIntent, using CompanionDeviceService, using WorkManager, or running a foreground service with the connectedDevice type. Google also discourages periodic scans as a general solution because they are inefficient and may still be interrupted. Starting with Android 14, foreground services must declare the appropriate service type explicitly. ⁽³⁾

This is the key point: Android can do this better than iOS, but reliability depends heavily on deployment discipline.

A normal consumer Android phone may still stop the app because of OEM battery optimization, user settings, background restrictions, or memory pressure. One might need a customized industrial grade Android device in order to make sure the process is not killed in the background. A managed device with whitelisting, high-priority app handling, controlled power settings, and a role-specific workflow has a much better chance.

When the app approach can work

We’ve seen three situations where the app-based idea is reasonable.

First, when the app is effectively in continuous operational use

Тhis could work in cases where the user keeps the app open during a shift, or the phone is mounted and used as part of a work process, beacon reception becomes much more realistic. An example would if it is mounted in a vehicle or construction equipment. Like an Uber Driver app.

Second, when the hardware is controlled

A rugged or customized Android phone, especially one managed by the enterprise, is far better than a random personal handset. Here, the phone is not a casual mobile app platform, it is a semi-dedicated terminal. As such a greater degree of customization is expected and it would be reasonable for the software to be customized in a way that is going to make the process feasible.

Third, when the requirement is event detection, not infrastructure-grade location

If the customer only needs “beacon seen,” “beacon near phone,” or “worker entered a zone with a managed handset,” then the app may be good enough. If they need stable room-level or site-level monitoring independent of user behavior, then no, that is gateway territory.

Main limitations that should be stated clearly

The app approach has these core limitations:

• Background execution is controlled by the OS. iOS and Android both optimize aggressively for battery life. 
• A phone is not a fixed infrastructure. In B-Mobile, fixed gateway position is part of the tracking logic.
• RSSI is unstable. Lansitec’s own documents note weak cross-room reception, RSSI swings, and multipath effects.
• User behavior matters. If the user swipes the app away, disables permissions, turns off Bluetooth, or lets the phone enter aggressive power-saving mode, performance drops.
• Platform variance is real. Especially on Android, behavior differs across manufacturers, as it is not uncommon to have heavy brand based customization unlike iOS where Apple has centralized control.

Practical recommendations

For a customer who insists on the app approach, we would recommend the following.

Use Android, not iOS, for the primary proof of concept. Build around filtered BLE scans, foreground service behavior where permitted, and enterprise device management. Use rugged/customized devices if possible. Keep the app tied to an operational workflow, not occasional use. Treat the app as a managed terminal, not a casual install from an app store.

For iOS, position the solution more narrowly. It may support alerting, presence hints, or controlled beacon-region workflows, but not full gateway replacement across demanding deployments.

And for customers who need consistent site coverage, minimal dependency on user behavior, and a stable reference point for tracking, keep the dedicated Bluetooth gateway architecture. That is still the best solution from an engineering and stable functionality perspective.

Conclusion

Yes, a mobile app can receive beacon broadcasts in the background. But, that does not automatically make it a good substitute for a Bluetooth gateway.

On iOS, the approach is limited and should be treated as conditional at best. On standard Android, it is possible but fragile. On customized or industrial Android devices, especially in a managed operational environment, it becomes much more realistic.

So the final conclusion is this:

An app-only background monitoring solution is feasible for selected Android deployments with controlled devices and continuous app use. It is not a reliable general replacement for fixed Bluetooth gateways, especially on iOS or on unmanaged consumer phones.

References and further reading:

1. Apple: Core Bluetooth Programming Guide
2. Apple: Location and Maps Programming Guide
3. Android: BLE communication in the background