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!