Bluetooth Low Energy (BLE) in Mobile Development: What It Is, Protocols and How It Works

What is Bluetooth Low Energy (BLE) and How Does It Work?

Bluetooth Low Energy (BLE) operates on a client-server model with two roles: Central (mobile device) and Peripheral (device). Central scans the airwaves and initiates the connection, while the Peripheral transmits data. Unlike Classic Bluetooth, BLE is not designed for audio streams — its task is to transmit small packets with minimal power consumption. According to the Bluetooth SIG Core Specification 5.4 (2025), BLE supports speeds up to 2 Mbps with a current draw of less than 15 mA in active mode.

GATT Hierarchy: Service, Characteristic, Descriptor

GATT (Generic Attribute Profile) defines the data structure of Bluetooth Low Energy. Service is a logical group of characteristics (e.g., Heart Rate Service 0x180D). Characteristic is a data point with a specific value. Descriptor is characteristic metadata, including CCCD for notification management. Each element has a UUID — 16-bit for standard Bluetooth SIG profiles or 128-bit for custom ones.

Bluetooth Low Energy in mobile applications uses this hierarchy to organize data exchange between a smartphone and peripherals. A proper understanding of GATT is the foundation for developing BLE applications on both platforms. The developer must know the UUIDs of the device's services and characteristics, as well as the properties of each characteristic (read, write, notify, indicate).

Advertising Data and Scan Response

BLE devices transmit advertising packets for discovery. Advertising Data contains the device name, service UUIDs, RSSI and Manufacturer Specific Data. The advertising packet size is limited to 31 bytes. To transmit additional data, Scan Response is used — a second packet that the central device requests after discovery.

BLE on iOS: Core Bluetooth, CBCentralManager, CBPeripheral

On iOS, the Core Bluetooth framework handles Bluetooth Low Energy. CBCentralManager manages scanning and connection, CBPeripheral represents a remote BLE device. The process is standard: initializing CBCentralManager, checking the poweredOn state, starting scanForPeripherals, connecting and discovering services. Core Bluetooth automatically manages the radio module's power — if BLE is not in use, it turns off.

BLE in mobile development on iOS requires consideration of background modes. Core Bluetooth background mode is enabled through the project's Capabilities (Uses Bluetooth LE accessories). In the background, the app can receive notifications from characteristics, but scanning is limited — the system restarts it only when the device moves. For iBeacon, background scanning works more actively through CLLocationManager.

Example of BLE Scanning in Swift

import CoreBluetooth

class DeviceScanner: NSObject, CBCentralManagerDelegate {
    var centralManager: CBCentralManager!

    func start() {
        centralManager = CBCentralManager(delegate: self, queue: nil)
    }

    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        guard central.state == .poweredOn else { return }
        central.scanForPeripherals(withServices: nil, options: nil)
    }

    func centralManager(_ central: CBCentralManager,
                        didDiscover peripheral: CBPeripheral,
                        advertisementData: [String: Any],
                        rssi RSSI: NSNumber) {
        print("Found: \(peripheral.name ?? "unknown")")
    }
}

In this example, CBCentralManagerDelegate handles all BLE connection events. The centralManagerDidUpdateState method checks whether Bluetooth is enabled on the mobile device. After successful initialization, scanning starts. The didDiscover callback is invoked for each found device.

Connecting and Reading Characteristics in Core Bluetooth

After discovering a device, you need to call connect and discoverServices. CBPeripheralDelegate provides methods for handling each step: didDiscoverServices, didDiscoverCharacteristics, didUpdateValueFor. Each method is asynchronous — data arrives through delegate callbacks. RSSI (Received Signal Strength Indicator) shows the signal level: the closer the value is to 0, the stronger the signal.

BLE on Android: BluetoothAdapter, BluetoothGatt, BluetoothLeScanner

On Android, Bluetooth Low Energy is implemented through the android.bluetooth package. BluetoothAdapter is the entry point for all BLE operations. BluetoothLeScanner starts scanning with ScanCallback callbacks. After discovering a device, BluetoothGatt is created — a connection to the peripheral. BluetoothGattCallback handles events: connection, service discovery, characteristic reading, RSSI changes.

Bluetooth Low Energy in mobile applications on Android requires explicit BLUETOOTH_SCAN, BLUETOOTH_CONNECT and ACCESS_FINE_LOCATION permissions. Since Android 12, permissions are separated: BLUETOOTH_SCAN for scanning, BLUETOOTH_CONNECT for connecting. ACCESS_FINE_LOCATION is only required for scanning certain types of devices. Without these permissions, the app cannot work with BLE.

Example of BLE Scanning in Kotlin

class BLEScanner(private val bluetoothAdapter: BluetoothAdapter) {

    fun startScan() {
        val scanner = bluetoothAdapter.bluetoothLeScanner
        val settings = ScanSettings.Builder()
            .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
            .build()
        scanner.startScan(null, settings, scanCallback)
    }

    private val scanCallback = object : ScanCallback() {
        override fun onScanResult(callbackType: Int, result: ScanResult) {
            val device = result.device
            val rssi = result.rssi
            Log.d("BLE", "Device: ${device.name}, RSSI: $rssi")
        }
    }
}

ScanSettings allows you to configure the scanning mode: LOW_POWER for battery saving, BALANCED for standard tasks, LOW_LATENCY for maximum discovery speed. ScanFilter narrows the search by service UUID, device name or MAC address. Filtering reduces power consumption and accelerates discovery of the desired device.

BluetoothGatt: Reading and Notifications on Android

After creating BluetoothGatt via connectGatt, the app calls discoverServices. BluetoothGattCallback contains onServicesDiscovered, onCharacteristicRead, onCharacteristicChanged. To receive notifications about characteristic changes, you need to call setCharacteristicNotification. The process requires attention: each GATT operation is asynchronous, and the result arrives in a separate callback.

iBeacon, Bonding and Advertising Data in the BLE Ecosystem

iBeacon is Apple's technology for BLE beacons that transmit UUID, Major and Minor. The beacon device broadcasts an advertising packet, and the mobile application determines location and distance based on this data. On iOS, iBeacon is natively supported through CLLocationManager. On Android, a third-party library is required (e.g., AltBeacon or Android iBeacon Library).

Bonding is the procedure for creating a permanent secure connection between BLE devices. After Bonding, encryption keys are saved, and devices connect automatically when they come within range again. On iOS, bonding is managed automatically by the system. On Android — via BluetoothDevice.createBond(). Bonding is important for wearable devices and fitness trackers that require quick reconnection.

Advertising Packets and Manufacturer Specific Data

Advertising Data is a key discovery mechanism in Bluetooth Low Energy. Device manufacturers can add Manufacturer Specific Data to the advertising packet to transmit custom data. The packet format includes a Company Identifier (2 bytes) and arbitrary data. On iOS, CBCentralManager accepts an array of service UUIDs for filtering — this saves battery. On Android, ScanFilter works on the same principle.

Comparison of iOS and Android for BLE Development

BLE Optimization: MTU, Connection Interval and Background Mode

MTU (Maximum Transmission Unit) is the maximum size of a single Bluetooth Low Energy data packet. By default, MTU is 23 bytes (3 bytes header + 20 bytes data). Increasing the MTU to 512 bytes significantly speeds up transmission when exchanging configurations or logs. On iOS, maximumWriteValueLength shows the available MTU. On Android, requestMtu() is used to increase the MTU.

Connection Interval is the frequency at which the central device polls the peripheral. The shorter the interval, the higher the transmission speed, but also the power consumption. Typical values range from 7.5 ms to 4 seconds. For fitness trackers, 100 ms is sufficient; for audio — 7.5 ms. BLE in mobile development requires a balance between transmission speed and device battery life.

Background Mode on iOS and Android

iOS supports BLE in background mode through Background Modes, but with limitations. An app in the background receives notifications from characteristics but cannot actively scan. The system restarts scanning when the device's location changes. On Android, background scanning requires a Foreground Service with a persistent notification. Without it, the mobile system will kill the process when the app is minimized.

Practical Optimization Recommendations

For reliable BLE operation in mobile applications, follow these rules. Use notify instead of polling — a characteristic with notifications sends data when it changes, saving battery. Set the optimal MTU at the start of the connection. Filter devices by service UUID when scanning. Check BLE stack compatibility across different models — manufacturers (Xiaomi, Huawei, Samsung) make changes that affect Bluetooth behavior.