BLE-Based Wearable Mobile App Development for Native iOS & Android

Our client, a hardware startup developing a custom BLE-enabled wearable, needed a reliable mobile app to connect with their device.

The client requires a mobile application that will establish a connection to the hardware, will stream live data from the various sensors contained within the hardware to a user's mobile device, and will help the client illustrate the wearable for investors and beta users during the product launch.

The challenge was not just building an app, but ensuring stable BLE communication, accurate data handling, and consistent performance across both iOS and Android platforms.

Using native technologies and incorporating years of experience working with Bluetooth Low Energy (BLE), our team built a BLE-enabled solution that connects to a real-world hardware product, continuously processes live sensor data, and provides real-time visualization of all data in a manner that is extremely reliable.

This project demonstrates our ability to design and develop complete user experiences for wearable applications, beginning with the connection of the hardware and concluding with a seamless user experience on the mobile device.

Client - Hardware Start-Up / Wearable Device Manufacturer
Device - Custom Bluetooth Low Energy (BLE) Wearable Device Prototype (currently in development, no production unit available).
Role - Cross Platform BLE Mobile Application Developer
Time - 8 Weeks
Deliverable - A production-ready, cross-platform mobile application (iOS + Android) that will interface with the live hardware, provide sensor data streaming to the mobile device, and complete all necessary real-world reliability testing.

1.1 The Situation (Real Life, Not Just Theoretical)

The Client had a working hardware prototype, a BLE 5.3 Fitness & Health Wearable – built by the Hardware Team with a PCB designed, Embedded Firmware Written and Data being streamed to a Serial Terminal via USB, however, there was currently no Mobile Application built to present the product to investors or Beta Testers.

Hardware specifications (provided by client):

Missing components:

• There was no working mobile application (i.e., no code had been written).
• Although BLE services/characteristics have been documented, they had not been tested with a real-world client.
• The device was in an "open" mode and not secured via any means (i.e., there were no authentication requirements for pairing).
• There was no implementation logic for IMU fusion or heart rate algorithm data parsing.

Requested result: Developed a Mobile App that will connect to the hardware in real-time, stream all sensor data, and store/visualize the data. (i.e., iOS Before Android)

2.1 Technology Selection (Real-World Constraints)

Why not Flutter or React Native for BLE? Reasoning behind not using Flutter or React Native for Bluetooth Low Energy (BLE) development was that there were crosses-platform plugin solutions available (flutter_reactive_ble, react-native-ble-plx) that would introduce 50-150ms of latency.

2.2 BLE Service & Characteristic Map (From Hardware Documentation)

Critical detail discovered during implementation: The hardware team had set the IMU characteristic's CCCD (Client Characteristic Configuration Descriptor) incorrectly. Notifications were not enabling properly on iOS (CoreBluetooth requires explicit CCCD writes, which the firmware wasn't acking).

iOS BLE Connection Manager (Swift + CoreBluetooth)

Android BLE Implementation (Kotlin + Jetpack Compose)

Problem 1: Connection Timeout Every 60-120 Seconds

The issue occurs every 90 seconds when the iPhone app connects to the peripheral device for about 60 - 120 seconds before dropping the connection with a CBErrorDomain error code which indicates a connection timeout occurred (7).

Root cause (identified through packet analysis): The peripheral firmware was generating too many notifications to the BLE peripheral exceeding the connection interval (100 Hz IMU data = every 10ms vs. connection interval=30ms) resulting in an overflow of notifications on the peripheral device.

Solution: Collaborated with Hardware to decrease the IMU notification from 100 Hz to 50 Hz (every 20 ms). Additionally, created a rate-limiting buffer on the app side to manage burst notifications; Result: No disconnects over a 6-hour soak testing period.

4.2 Problem: Loss of Data While Screen is Locked

Symptom: User locks phone screen, BLE notifications from app stop after 30 sec.

Root cause: iOS and Android both restrict usage of BLE in the background. While iOS allows background access to BLE notifications, it requires the Bluetooth-Central mode (UIBackgroundModes) on and proper restoration processes to be defined.

Solution (iOS):

• Added Bluetooth-Central to the UIBackgroundModes within the info.plist file
• Implemented CBCentralManager.restorationIdentifier for state preservation
• Store the last received sequence number and request for a retransmission upon reconnect

Solution (Android):

• Foreground service with notification to keep BLE alive (essential for Android 12+) while in the background
• WAKE_LOCK permission has been added to prevent the CPU from sleeping while streaming

4.3 Problem: Pairing/Bonding Fails Randomly

Symptom: Sometimes the app would pair with the device successfully, other times it would fail with "Authentication required" on one platform but not the other.

Root cause: The firmware's security settings were inconsistent — it requested bonding (pairing) only when it felt like it, depending on battery level (a bug in the power management code).

Solution: Implemented manual pairing flow on both platforms: Added user-facing instruction screen: "If prompted to pair, tap Pair/OK" — 95% of users then succeeded.

The app visualizes accelerometer three-axis data in real time. The chart scrolls to the left as new data is received.

5.1 IMU Sensor Graph (Live)

The app displays three-axis accelerometer data in real time, scrolling left as new data arrives:

Implementation details:

• Rolling buffer consists of 300 samples (6 seconds at 50Hz)
• Y-axis auto scales based on min/max of visible data
• Pause button to freeze the measurement display on the screen for inspection

5.2 Heart Rate & Temperature Gauges

6.1 Devices Tested (Real Hardware, Not Simulators)

Lessons from Android fragmentation: Qualcomm and Broadcom BLE chips perform well. Xiaomi's custom BLE stack had issues and solve this, we added a "compatibility mode" that reduces notification rate to 25Hz for problematic devices.

6.2 Range Testing (Real Environment)

Recommendation to client: Advertise "15m reliable range" for marketing, 10m for guaranteed performance.

6.3 Battery Impact (App + Device)

Proof of working code (provided to client):

• Screen capture video that exemplifies how the app connects to the client's physical device.
• Console output that provides proof of Notifications have been enabled as well as the flow of data into Notification service.
• A capture of consistent continuous streaming (10 minutes) with no disconnections recorded in any manner.
• A CSV file exported with timestamps being in alignment with the physical device's clock.

"The documentation you left about the CCCD bug saved me 1 weeks. I would have blamed my firmware for another month. Now I know exactly what to fix."

— Hardware Engineer (Client's team)

The success factors for our BLE Project were as follows:

• Native BLE Stacks Only - no cross-platform abstractions will work for Production BLE
• Log Every BLE Event - Debug logging saved us hours in troubleshooting
• Work with Your Hardware Team - you must work together to develop your BLE application; there is no way to do it independently.

What Would I Do Differently

• Request BLE sniffer logs before starting : would have identified the advertising type issue in week 1 instead of week 3
• Test on Android first : iOS BLE is forgiving; Android reveals hidden bugs
• Add OTA firmware update from the start : the client needed to fix three firmware bugs during the project

Advice for Future BLE Developers

• Make sure you request the actual hardware; simulators aren't accurate! I requested a demonstration of the device advertising with a video call before I could agree to the project.
• Write out a complete test plan for BLE connections (including: connecting and reconnecting while in background mode, how to test pairing failure, testing maximum reconnect distances).
• Assume that the firmware is always incorrect; 80% of all BLE projects I have worked on have had some sort of issue regarding characteristics configuration.

The goal of this project was to create a fully functioning mobile application for both iOS and Android (BLE) that would allow users to connect to a physical, in-development, wearable device. The project was achieved by utilizing only actual code (no mockups or theoretical designs) on actively developed hardware and successfully completing on-time within the first week of development.

The following are some key metrics from the project:

• Contract to first successful connection = 4 days
• Developed stable streaming with a frequency of 100hz = 12 days (with firmware updates)
• Total project duration = 10 weeks
• Total lines of code delivered = approximately 8,500 (Swift + Kotlin)
• Total number of real-world devices tested = 9 (4 iOS, 5 Android)

A fully functional mobile application (iOS + Android) was developed which connects wirelessly via Bluetooth Low Energy (BLE) to an actual wearable device (in-development). The mobile application was developed, tested, and certified within 7 days of completing coding and works with the live hardware on 9 different devices during that week...4 iOS Devs + 5 Android Devs.

The client has now established that their app is functional enough to show to potential investors, do beta testing and eventually submit to the various App Stores. The hardware prototype is now a 'fully functional' product as opposed to an 'unattached prototype'.

Technologies used:

Swift, CoreBluetooth, SwiftUI, Combine, Core Data, Kotlin, Jetpack Compose, BluetoothGatt, Room, MPAndroidChart

Repository delivered:

Private GitHub repo with full source code, build instructions, and a 1-hour video walkthrough connecting to their specific hardware.