Healthcare & Fitness Wearable App Development Using Flutter

Target Audience: Smart Wearable Owner

Key Capabilities: Display of Immediate Health Data (steps, heart rate, blood oxygen level, and sleep), Notifications On Multiple Devices (calls, SMS messages, app notifications), Setting and Dismissing Alarms, Integrations with Apple Health/Google Fit, Support for Multiple Devices

Tool & Tech Stack: Mobile App Built With Flutter, Django Rest Framework (Backend API), Amazon Web Services (Cloud Infrastructure), BLE (Bluetooth LE) Device Communication

A manufacturer of consumer smart wearable's (including Force, Pigeon, Eagle, Lark Pro, Lark 2 and Parrot) wanted a new cross-platform mobile application that could keep up with its increasing number of fitness bands and smart rings.

The current app was difficult to maintain, required too many development resources to create for multiple platforms, and did not allow for easy synchronization with the cloud.

Our engineering team built app from the ground up using Flutter for a single, consistent codebase on both Android and iOS, Django REST Framework for a secure and scalable backend API, and AWS for global cloud infrastructure.

Benio Devices use Bluetooth Low Energy (BLE) to communicate with their application, allowing them to sync health information from their phones to Apple Health and Google Fit in real-time and receive notifications delivered directly from the user's/phone to their Benio Device.

The finished app is a very user-friendly and easily maintained application which is currently in use worldwide (with support for 5 languages: English, Simplified Chinese, Russian, Thai, and Vietnamese) and was downloaded by users in every region of the world.

Key Functional Requirements

Display of Health Data

Activity (steps), heart rate, blood oxygen saturation (SpO2) level, and sleep patterns will be displayed in graphical and textual format within the App

Pair and Control Benio Device

Discovery of BLE Devices, the ability to connect using the Bonding option and switch between several (Benio) Devices

Sending notifications in real time

Reminder of Incoming Calls, SMS Messages, and Notifications from Apps such as WhatsApp, WeChat, etc., sent from Smartphone to Wearable Device

Setting Smart Alarm

Creation, Modification and Removal of Smart Alarms (Vibrating Only) on the Wearable Device

Synchronizing Data with Health Platform

Bidirectional Sync with Apple Health (Available on iOS), Google Fit (Available on Android)

Language Options

English, Simplified Chinese, Russian, Thai and Vietnamese (as Shown on App Store)

Non-Functional Requirements

Performance:

The BLE data will get to the app within 5 seconds when measuring health metrics for a full 24 hour period.

Battery Awareness:

The app should minimize background BLE scanning and location services as much as possible (note: "may still use your location even when the app is not open, thereby depleting the battery on your device").

Offline Capable:

The health data from the health device should be stored on the device itself until the internet connection is established and after which every time it has been connected to the internet, it should sync that data as well.

Scalability:

The app must support millions of concurrent users from around the world (including China, Southeast Asia, Russia, and the United States).

Maintainability:

The app's two platforms (iPhone/iPad) should be built from a single code base, which will reduce bug fixing and feature enhancement efforts by about 40%.

Technology Stack Justification

Layer	Technology Choice	Rationale
Mobile Frontend	Flutter	Single codebase for iOS and Android; excellent BLE plugin ecosystem; fast UI rendering for real-time charts; hot reload for rapid iteration
Backend API	Django REST Framework (DRF)	Robust ORM for user-device mapping; built-in admin for customer support; mature security features; easy integration with AWS services
Database	Amazon RDS for PostgreSQL	Reliable ACID compliance for user accounts and device associations; support for JSON fields (flexible health data schemas); automated backups
File Storage	Amazon S3	Store user profile images, firmware update files (for OTA updates), and aggregated health report PDFs
Authentication	Amazon Cognito + JWT	Managed user pools with social sign-in options; secure token-based authentication for API calls
Push Notifications	Firebase Cloud Messaging (FCM) + Apple Push Notification Service (APNS)	Deliver call/SMS/app notifications from phone to wearable (via app as a relay)
BLE Communication	FlutterBlue Plus plugin	Cross-platform Bluetooth Low Energy library; handles device discovery, connection, characteristic read/write/notify
Monitoring	AWS CloudWatch + Sentry	Real-time error tracking; API performance monitoring; BLE connection failure analytics
CI/CD	GitHub Actions + CodeMagic	Automated builds for both platforms, deployment to TestFlight and Google Play Internal Track

BLE Architecture and Project Structure

The Flutter codebase is set up using a feature-driven modular architecture. Each of the core features will have its own directory structure (device pairing, health data synchronization, notification, and alarm). Each of these features will have their own BLoCs (Business Logic Components) for managing state.

BLE Communication Layer:

The BLE abstraction layer was the most important part of the project, and it was built upon the existing flutter_blue_plus plugin. This layer was responsible for:

Device Discovery:

Scanning for Benio devices based on their respective manufacturer advertising data (custom UUIDs) that represent the respective product line (Pigeon, Eagle, Lark Pro, etc.) in order to omit any unnecessary BLE devices from being discovered.

Connection/Bonding:

When a user selects a specific device, the app establishes a secure connection to the selected device. In doing this, bonding (aka pairing) is also done to allow the selected device to remember the phone and automatically reconnect without the user having to repeat the bonding process.

Data Synchronization:

Benio wearables store health data (steps, heart rate, sleep) in onboard flash memory. The app reads this data using custom characteristics (standard BLE concept: readable/writable data endpoints). The sync process involves:

• Reading the last sync timestamp stored on the device
• Requesting all health records after that timestamp
• Writing the new sync timestamp back to the device
• Parsing the binary data into structured Dart objects

Notification Relay:

The application registers for phone notifications from the system (i.e., phone calls, text messages, application notifications). When a notification comes into the application, it sends a small payload using Bluetooth Low Energy (BLE) to the wearable device so that the device may vibrate or show an icon related to the incoming notification. BLE GATT notifications enable a notifications characteristic that the wearable device subscribes to in order for the app to send BLE notifications.

Alarm Management:

Alarms are stored in flash memory on the wearable device, and will be read from the wearable by the app providing a list of alarms (maximum 10) with the ability to add/modify/delete alarms, and the updated list of alarms will be written back to the wearable device.

Health Data Visualization

Health metrics will be drawn from the local SQLite database (which was previously synced/cached), and will be immediately shown to the user, while newer data will be updated in the background.

The visualization of health metrics is accomplished using the fl_chart library which is capable of providing customized, animated charts (for example, line charts to indicate heart rate over time, bar charts to indicate stages of sleep, and circular progress bars to indicate the goal of daily steps).

Platform Integrations

Apple Health (iOS)

The app requests permission to read and write health data using the health_kit flutter plugin. When the user syncs their Benio device, the app logs steps, heart rate and sleep analysis to Apple Health. Alternatively, the app can take in activity data from Apple Health to fill in gaps when the wearable was not worn.

Google Fit (Android):

The google_fit_plugin provides similar functionality and reads and writes fitness data via the REST APIs of Google Fit (through the user's Google account). Both integrations are meant to be optional – the app works perfectly without them based on user preference and privacy choices.

Data Strategy: Offline First

The app uses SQLite for local database storage (via the sqflite plugin). The wearable immediately stores every health data point it reads locally. A background service uploads the data to the Django backend in batches when the app has an internet connection. This means that health records are never lost, even by users in areas of poor connectivity.

Django REST API Design Framework

The backend API (/api/v1/, versioned) is kept lightweight because the majority of user interactions are directly between the Flutter app and the Benio wearable over BLE. The API manages:

Cloud Backup (Optional):

Health data can also be backed up to the cloud by users. The API accepts encrypted health data (steps, heart rate, etc) and stores it in a time-series compatible format in PostgreSQL. This enables to recover data when switching phones.

Firmware Over the Air (OTA) updates:

The API is serving firmware binary files from S3. The app checks the device's current firmware version with the latest version available and downloads updates when available.

Anonymous Usage Analytics:

It is gathered for product improvement. It is aggregated and anonymized data (e.g. "average step count of Benio users in Thailand"). There is no personally identifiable information.

Test Type	Approach	Target
Flutter Widget Tests	Test each health chart, device list, and settings screen in isolation	80% coverage
Flutter Integration Tests	Simulate full BLE pairing and sync cycle using a hardware emulator (custom Bluetooth simulator)	Critical path only
BLE Protocol Tests	Automated tests for characteristic reading/writing, notification subscriptions, and error recovery (e.g., sudden disconnection)	All defined protocol commands
Django Unit Tests	Test all API endpoints (authentication, device registration, firmware metadata)	90% coverage
End-to-End (E2E)	Run on real devices (iPhone 12, Pixel 6) with actual Benio hardware (Pigeon, Force)	3 full user journeys
Battery Impact	Measure background BLE scan time and location usage over 24 hours	<5% additional battery drain per day
Performance	Sync 30 days of health data (approx. 5,000 records)	<8 seconds from connection to completion

Key Bug Found:

While testing the BLE protocol, the app sometimes crashed if a device disconnected during a firmware update. The fix was to implement a state machine with retry logic and a 'resume from where left off' capability.

Improvements to sleep tracking:

Nap detection was added in version 2.1, responding to user feedback (App Store review: "My only complaint is to track naps in sleep data"). The algorithm now detects sleep periods longer than 30 minutes, even if they do not occur within the user's typical bedtime.

Battery Optimization:

CloudWatch metrics showed that background location usage (required for BLE scanning on Android) was draining batteries faster than expected. The team implemented a smarter scanning strategy: only scan for known bonded devices, and use Android's ScanSettings.Builder().setLegacy(false) for lower power consumption.

Multi-language Expansion:

Multi-language expansion has been achieved by seeing high volumes of users from Vietnam and Thailand after launching the app. Due to this, we have added Vietnamese and Thai localizations which are now reflected in the app store ingles.

Firmware OTA Success Rate:

The initial over-the air (OTA) success rate for firmware was only 88% because of issues with Bluetooth Low Energy (BLE) connections dropping while transferring large files, which resulted in many users not having their devices successfully update firmware after launching the app. To improve this result, we implemented chunked transfer with CRC verification and resume capability to raise the success rate to 98%.

The project successfully delivered a modern, cross-platform companion BLE app for the client's growing lineup of smart wearables and having 25k+ download conbines ios+nadriod.

By choosing Flutter, the team reduced development time by approximately 40% compared to building two separate native apps.

The Django + AWS backend provides a secure, scalable cloud infrastructure for device registration, firmware updates, and optional health data backup.

The app meets all store requirements: no third party data sharing, encrypted transmission, user data deletion available, and proper disclosures for non-medical use. Positive user reviews confirm the accuracy of step, heart rate and sleep tracking.

Live App

Google Play App Store