In a recent presentation at the /dev/world conference in Australia, I showcased the potential of Bluetooth Low Energy (BLE) for peer-to-peer communication in mobile and cross-platform apps. Let’s look at how partnering BLE with a local-first app architecture can create something truly revolutionary.
Local-First Apps and BLE
Local-first apps can perform all or a critical subset of their functionality without an active internet connection. This isn’t always enough, though—if your work requires sending messages to a colleague or sharing data, you remain stuck until the server is available.
With Bluetooth Low Energy, we can do better than that. BLE enables devices physically near each other to communicate directly, ensuring seamless data sharing and real-time collaboration even when disconnected from Wi-Fi, local servers, or the cloud.
At Ditto, we see many examples: flight attendants messaging and taking meal orders from passengers; maintenance workers in warehouses with poor WiFi coverage; outdoor hospitality venues; and restaurant employees who need to share orders with the kitchen display system when the internet goes down.
Core Concepts of BLE
BLE operates differently from regular WiFi networks, and understanding the differences is essential to using it effectively. There are two roles called central and peripheral, like clients and servers. The peripheral broadcasts advertisements on its radio. The central scans for those advertisements and initiates connections to peripherals.
A traditional BLE device performs only one of these roles, which can limit its usefulness. Modern phones and computers, however, can do both at once. This means any device can connect to any other device without relying on “leaders” or a single point of failure, like a WiFi access point. This can be extremely powerful for local-first applications, but it has to be implemented correctly.
Practical Tips for Implementing BLE
BLE is very capable, but achieving good performance, reliability, and security can be finicky. I briefly explored six tricky areas, all of which are built into Ditto’s SDK.
1. Advertisement Content: Choose service UUIDs and local names wisely to track devices running your app. You also need to use the manufacturer data field for cross-compatibility with Android.
2. Device Tracking: Since devices often rotate their MAC addresses for privacy, incorporate unique, app-generated identifiers for reliable tracking.
3. Security: BLE’s built-in security mechanisms are inconvenient. Implement application-level encryption using Mutual TLS or Noise Protocol for secure authentication and data transmission.
4. Handling L2CAP Channels: Dynamically allocated PSM values must be communicated to the central to create a channel via a characteristic or advertisement.
5. Connection Policies: Develop intelligent algorithms for determining which peers to connect with, considering advertisement frequency and avoiding duplication.
6. Background Modes: Switch on background modes to communicate while phones are locked, but be mindful of the limitations, such as reduced advertisement frequency and scanning intervals.
Cross-Platform Implementation
I shared insights on maintaining BLE support across various platforms (iOS, Android, Windows, and Linux) in the Ditto SDK. Developers can minimize code duplication across different operating systems by centralizing logic in a common core (ours is written in Rust) and using platform-specific drivers.
Conclusion
BLE offers a robust framework for building resilient, local-first apps with enhanced peer-to-peer communication capabilities. With the right strategies and understanding of BLE’s quirks, developers can create innovative applications that provide a seamless user experience, even without internet connectivity.
For more details and the complete presentation slides, watch the full presentation here.