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!

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.

Introduction

As I mentioned in the previous post, CoreBluetooth allows us to create applications that can communicate with BLE devices such as heart rate monitors, body sensors, trackers, or hybrid devices.
There are two roles to play in the CoreBluetooth concepts: Central and peripheral.

• Central: Obtain data from peripherals.
• Peripheral: Publish data to be accessed by a central. We can make a Bluetooth device plays as a peripheral from either firmware-side or software-side.

In this post, I will show you how to create a peripheral by using our own identifiers. Also using another device, as a central, to connect and explore our services. Let’s get it started.

The Core Bluetooth (CB) framework allows iOS and MacOS apps communicate with BLE devices. Your apps can discover, explore, and control the BLE devices, such as heart rate monitors, trackers or hybrid watches.

Image 1. BLE devices (Source from Google)