From simple integration to real-world complexity
When Blue-bike initially set out to modernize their bike platform, the goal was clear: replace mechanical locks with smart locks using Bluetooth Low Energy (BLE), a wireless technology designed for short-range communication with minimal battery impact. The aim was to create a seamless mobile experience: scan, connect, unlock.
At first glance, this looked like a standard Bluetooth integration. Scan, connect, unlock. However, while the basics seemed standard, the specific requirements for Blue-bike and the integration with AXA BLE ERL2 smart locks were anything but.
When integrating with AXA, we didn’t settle for the standard software implementation. We fine-tuned the communication protocols of the hardware and the app so that the connection remains stable even in an environment with high levels of interference.
The challenge most apps underestimate
Once the platform scaled, new needs emerged:
Reliable location detection: To ensure users could always end their rides, even in GPS-poor environments like underground stations, we implemented Beacon technology as a vital fallback.
Maintenance access: Service teams needed dedicated BLE access to battery locks for maintenance purposes.
Suddenly, the app wasn’t talking to one device anymore. It was juggling multiple Bluetooth interactions at the same time.
And that’s where things started to break.
One BLE radio, multiple demands
Smartphones only have one Bluetooth radio. Yet many apps treat it like an unlimited resource.
In practice, this leads to:
Silent scan interruptions (especially on Android)
Features interfering with each other
Device-specific bugs that are hard to reproduce
“Works most of the time” experiences that frustrate users
For platforms like Blue-bike, this directly impacts both user experience and operations. To solve this, we leveraged our partnership to build a robust architecture that treats Bluetooth as a shared system resource.
Our approach: treat BLE as a shared resource
At icapps, we’ve seen this pattern before across multiple projects. When apps evolve, Bluetooth complexity grows with them.
Instead of patching issues later, we design for it upfront.
The key insight is simple: Bluetooth should be managed like any shared system resource.
Meaning: just as a processor decides which app gets processing power, there needs to be a system that determines which function is allowed to use the Bluetooth antenna at any given moment. Without this central management, different parts of the app (such as unlocking the lock versus searching for beacons) will compete with each other for the connection, leading to failed actions and a frustrated user.
The solution: a scan coordinator
To prevent conflicts between BLE features, we implemented a centralized scan coordinator.
In short, it:
Controls who can scan at any given time
Assigns priorities (user actions over background processes)
Temporarily pauses lower-priority scans
Applies rate limiting to avoid OS restrictions
Ensures consistent behavior across devices
This creates a predictable and stable Bluetooth layer, even as new features are added.
Why this matters for your product
If your app connects to just one device, you might never notice this problem.
But if you’re building:
A connected product ecosystem
A mobility or IoT platform
A feature roadmap with future integrations
…this challenge will surface sooner or later.
And when it does, it won’t show up in testing. It will show up in production.
Designing for scale from day one
What we built for Blue-bike is not a workaround. It’s a scalable foundation.
By centralizing BLE coordination:
User interactions become reliable
Background processes stay invisible but effective
New integrations don’t introduce new risks
Most importantly, it allows teams to keep innovating without breaking existing functionality.
What this says about how we work
This project reflects how we approach digital products at icapps.
We don’t just build what’s needed today.
We anticipate what your product will need tomorrow.
Because in connected ecosystems, small technical decisions can have a big impact on user experience.
If you’re working on a product with Bluetooth, IoT or multiple device integrations, it’s worth asking: Are we building for today’s use case… or tomorrow’s complexity?
FAQ: Bluetooth and multi-device BLE
What is multi-device BLE?
It refers to apps interacting with multiple Bluetooth Low Energy devices, common in IoT, mobility, and connected products.
Why does Bluetooth fail with multiple devices?
Because smartphones only have one BLE radio. Multiple scans or connections can interfere, causing unreliable behavior.
How do you manage multiple BLE interactions?
By using a centralized approach, like a scan coordinator, to control access, prioritize actions, and prevent conflicts.
What are common BLE issues in mobile apps?
Unstable connections, background limitations, Android restrictions, and conflicts between multiple Bluetooth processes.
When do you need a scan coordinator?
As soon as your app connects to multiple devices or combines background and foreground BLE features
