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.

Unlike Android, iOS restricts background processing in an effort to improve battery life and user experience. When your app enters background mode, developers lose direct control over it. How and when your app gets a chance to execute a task depends entirely on the system. At its core, iOS uses an internally complex algorithm to determine which apps are allowed to run in the background, based on factors such as user activity patterns, current battery state, and more.

In this tutorial, we will learn how to request periodic background execution time on iOS. After understanding how it works, we will apply this technique to a BLE-based app in some specific cases in the next tutorial.

Let’s get started!

Preface

When working with CoreBluetooth, have you ever wondered how a BLE app on iOS can survive when it is terminated by the system? How can we bring it back to the background? Is there anything like an Android service that can run indefinitely? You can find the answer to all these questions in this post. Read on!

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for constrained devices and unreliable networks. Originally developed by IBM in the late 1990s for monitoring oil pipelines over satellite links, it has since become the de-facto standard for IoT communication — powering everything from smart home sensors to industrial automation systems.

In this post, we’ll cover what MQTT is, how to set it up, practical examples, real-world use cases, its strengths and weaknesses, and the best practices you should follow.

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.

AccessorySetupKit, introduced in iOS 18, revolutionizes how third-party Bluetooth and Wi-Fi accessories integrate with iOS devices. This framework delivers a seamless setup experience, enhancing convenience for users and expanding capabilities for developers.
While AccessorySetupKit supports discovery for Bluetooth, Wi-Fi, and Local Network devices, this post will focus specifically on BLE (Bluetooth Low Energy). The setup process for Wi-Fi and Local Network devices follows a similar approach.

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.

Developing BLE-enabled Android apps is fraught with challenges, especially when it comes to managing concurrent operations. One of the most common pitfalls developers face is the unexpected behavior that occurs when trying to execute BLE operations in rapid succession. In this blog post, we’ll delve into why this happens and how you can overcome it by implementing a custom queuing mechanism for BLE operations.