Both CoreBluetooth (2011) and Android’s BluetoothGatt (2013) were designed in the age of delegates and callbacks. Every BLE operation — connect, discover, read, write, subscribe — fires its result into a different method, far away from where you started it. The result is the infamous “callback maze”: logic for a single user action smeared across half a dozen delegate methods, all coordinated by shared mutable state.

We already explored one way out in Callback vs Reactive Programming: reactive streams. But reactive frameworks bring a dependency and a learning curve. Today both platforms ship a native answer — Swift Concurrency (async/await) on iOS and Kotlin Coroutines (suspend + Flow) on Android — that turns the callback maze into linear, cancellable, testable code with zero third-party dependencies.

In this article we will build a small, modern BLE layer on both platforms from the ground up, and cover the sharp edges nobody warns you about: double-resume crashes, leaked continuations, timeouts, and cancellation.

Let’s get started!

Every connected product eventually needs a firmware update. A bug ships, a new feature lands, a security hole is found — and the only way to fix the device sitting in your customer’s pocket is to push new firmware over the air. In the BLE world this is called OTA (Over-The-Air) updating, or DFU (Device Firmware Update).

It sounds simple: send a binary to the device and tell it to reboot. In practice, OTA is one of the most failure-prone flows in any BLE product. A dropped packet, a corrupted image, or a power loss at the wrong moment can turn a $200 device into a brick.

In this article we will build a complete mental model of how BLE firmware updates work, walk through the Nordic DFU approach and a custom protocol, and cover the three things that separate a toy implementation from a production one: integrity verification, resumability, and safe rollback.

Let’s get started!

After years of shipping Bluetooth Low Energy applications, I kept hitting the same wall: the tools we use to talk to BLE devices — scan, connect, poke at characteristics, reproduce edge cases — are still stuck in the terminal-era. So I built Signal Hub, a Mac app for engineers who live in the BLE stack.

Signal Hub lets you manage concurrent BLE connections, design visual workflows that run on real hardware, simulate devices when the prototype hasn’t shipped yet, organize everything in workspaces, and export beautiful PNG / video documentation — all from one calm, elegant app.

→ Explore the full introduction

Sooner or later, every BLE developer runs into the same wall: you need to send more than 20 bytes at a time. Maybe it is a firmware image, a batch of sensor readings, or a configuration payload. You fire off a write and… only the first 20 bytes arrive. The rest is silently dropped.

The root of this problem is the MTU (Maximum Transmission Unit) — the maximum number of bytes a single BLE packet can carry. Understanding MTU, knowing how to negotiate it, and building a reliable chunking layer on top of it is essential for any real-world BLE application.

In this article we will cover everything you need to know: what MTU actually is, how to negotiate it on iOS and Android, the difference between write types, how to build a chunking protocol, and how to maximize throughput.

Let’s get started!

Flutter runs on a single main thread — the main isolate — responsible for rendering the UI at 60 or 120 fps and handling user input. Any heavy work you put on that thread shows immediately: dropped frames, stuttered animations, and an app that feels sluggish.

Dart’s answer is the isolate: a fully independent unit of execution with its own isolated memory and its own event loop. Offloading work to a background isolate frees the main thread to do the one thing it must do well — paint the interface.

In this article we’ll explore what background isolates are, how they work internally, when to use them, and how they fit into Bluetooth Low Energy apps.

Let’s get started!

If you have ever spent hours staring at raw HEX dumps trying to figure out why your BLE peripheral is not sending the right data, you know the pain. Debugging Bluetooth Low Energy devices is notoriously tricky — the protocol is powerful, but the tooling available on mobile has always felt lacking.

That is why I built Signal Hub — a professional BLE toolkit designed for developers, hardware engineers, and IoT makers who need reliable, feature-rich tools to interact with BLE devices directly from their phone.

Bluetooth Low Energy (BLE) is a core technology behind fitness trackers, smart home devices, medical equipment, and many other IoT products. When building a BLE-enabled app, you often face a choice: native iOS, Flutter, or React Native?

Rather than relying on third-party BLE libraries for Flutter or React Native, the approach I recommend — and practice — is to write all BLE logic in native Swift using CoreBluetooth, then expose it to each cross-platform framework via its native bridge mechanism. For React Native, that means Native Modules. For Flutter, that means Platform Channels.

This gives you full control of the BLE stack, consistent behavior across all your projects, and zero dependency on external BLE packages that may lag behind iOS SDK updates.

Building Bluetooth Low Energy applications involves handling numerous asynchronous operations: scanning, connecting, discovering services, reading/writing characteristics, and handling disconnections. The traditional callback-based approach can quickly become unwieldy, leading to what developers call “callback hell.” In this post, we’ll compare the callback approach with reactive programming using RxSwift and RxJava, and explore how reactive patterns can dramatically improve your BLE code.

Bluetooth has become the invisible thread connecting our devices, from smartwatches and health trackers to smart locks and industrial IoT systems. But with convenience comes risk: Bluetooth communication is wireless and easily intercepted, making it vulnerable to eavesdropping, unauthorized access, and replay attacks.
To defend against these threats, authentication and encryption are essential. In this post, I’ll introduce a robust Bluetooth security flow, explaining how authentication, key exchange, and encrypted transfer work together. We’ll also compare it to TLS/https since both share similar approach of layered security.

In modern times, Bluetooth plays a crucial role in connecting devices seamlessly. From fitness trackers to smart home devices, Bluetooth Low Energy (BLE) allows devices to communicate efficiently while reducing power consumption. However, with the rise of wireless communication, ensuring security has become a key concern. Two core concepts of Bluetooth security are Pairing and Bonding, which are often misunderstood in the context of BLE.