Integration with Hardware: BLE, NFC, IoT and HomeKit in Mobile Applications
When the goal is to connect a smartphone with a physical device, half of the problems are not in the code, but in the firmware, BLE service characteristics, and protocol delays. A mobile developer works here at the intersection with the firmware team, and without understanding the stack from bottom to top, the result is unpredictable.
BLE: Where Everything Usually Breaks
Bluetooth Low Energy is the primary protocol for wearables, medical devices, smart locks, and industrial sensors. Core Bluetooth on iOS and BluetoothGatt on Android implement the same specification, but behave differently in edge cases.
The most painful point is connection management. On iOS, CBCentralManager requires holding a strong reference throughout the session; if the object is destroyed, the connection closes silently. On Android, BluetoothGatt requires explicitly calling gatt.disconnect() and gatt.close() separately — only calling close() without disconnect() leaves the device in a "busy" state and the next connection fails with error 133 (GATT_ERROR). Error 133 is the most common in Android BLE development, and it's not "something went wrong" but a specific case of GATT queue overflow or incorrect closure of the previous session.
Scanning is also non-trivial. On Android 12+, BLUETOOTH_SCAN requires the neverForLocation flag if you don't need geolocation — without it, the user sees a location permission request when connecting to a lock, which is confusing. On iOS since iOS 13, NSBluetoothAlwaysUsageDescription is mandatory in Info.plist, and the application silently won't scan without it — no crash, no log.
For reliable production operation, use an operation queue over GATT: write, read, notification subscribe — strictly sequentially through the operation queue, otherwise concurrent requests cause characteristics to return ATT_INSUFFICIENT_RESOURCES error.
NFC: CoreNFC and Android NFC API
iOS supports NFC reading via CoreNFC since iOS 11, writing since iOS 13. Important limitation: the scanning session is only active while the NFCNDEFReaderSession object is alive and shows system UI. Background scanning is only available for applications with the com.apple.developer.nfc.readersession.formats entitlement and only for ISO 14443 (bank cards, passports) — and this entitlement is not given to everyone.
On Android everything is simpler: NfcAdapter.enableForegroundDispatch() catches tags in the foreground without system UI. Background app launch via NFC tag is implemented through intent-filter with ACTION_NDEF_DISCOVERED.
HomeKit and Matter
HomeKit is Apple's ecosystem for smart homes. For integration, the device must have MFi certification (or work through Software Authentication for Matter). The mobile application uses the HomeKit framework: HMHomeManager → HMHome → HMRoom → HMAccessory → HMService → HMCharacteristic.
Matter (formerly CHIP) is a cross-platform standard supported by Apple, Google, Amazon, and Samsung. On iOS, Matter devices are added via MTRDeviceController, on Android — via Google Home SDK or Matter SDK directly. Matter's advantage: one device works with HomeKit, Google Home, and Alexa without reflashing.
For Flutter and React Native, use flutter_blue_plus and react-native-ble-plx respectively — both are actively maintained and cover 90% of scenarios, but for GATT notifications in background on Android, you still need a foreground service.
How We Structure the Work
The process begins with obtaining the BLE GATT specification (list of services, characteristics, data formats) or HCI log from the firmware team. Without this, development turns into reverse engineering via nRF Connect or Wireshark over HCI.
Test on real devices from day one — BLE emulator in simulators doesn't reproduce edge cases of reconnection, signal loss, MTU changes.
Timeline: simple integration with one BLE peripheral device (readings + control commands) — 2-4 weeks. Full-fledged IoT application with multiple device types, firmware OTA updates, and HomeKit support — from 2 months.