Wearable Health App Development Case Study:
Smart Biometric Ring Platform
A full-stack digital health platform development programme spanning sensor firmware, Bluetooth Low Energy transport, iOS and Android applications, and a cloud health data analytics platform engineered so that a ring worn 24 hours a day produces data a clinician would trust.
Continuous biometric capture from a ring worn around the clock
Biometric signals modelled across cardiac, respiratory and thermal domains
Native-quality iOS and Android applications on one shared data contract
Application modules delivered from authentication to health reporting
A ring the size of a wedding band, carrying a hospital-grade sensing brief.
Movano Health set out to build a wearable that women would actually wear every day and that regulators, clinicians and data scientists could take seriously. That combination jewellery on the outside, instrumentation on the inside defined every engineering decision in this biometric wearable development programme.
The platform we delivered has four coupled parts: the ring itself, iOS and Android companion applications, a set of backend services, and the cloud infrastructure beneath them. The ring senses continuously and holds data locally. The mobile application collects it over Bluetooth Low Energy, decodes and visualises it, and synchronises the results upward. The cloud stores the longitudinal record, runs analytics, and returns insight the wearer can act on.
Where most healthcare mobile app development projects begin at the screen, this one began at the sensor. Sampling strategy, packet structure, clock drift and battery budget were settled before a single dashboard was drawn — because in connected health solutions, the interface can only ever be as honest as the signal behind it.
Power measured in microamps
A ring has no room for a large cell. Continuous photoplethysmography, temperature and motion sensing had to fit inside a budget that still delivered multi-day wear between charges.
Data that cannot be lost
Sleep happens away from the phone. The ring buffers overnight and reconciles later, so a night out of range never becomes a gap in the wearer's record.
Signals that must hold up
Heart rate, SpO₂, HRV, respiration and skin temperature had to remain defensible under motion, cold hands and varying finger sizes not just in a lab.
Four tiers, one contract, no silent data loss.
The architecture is deliberately conservative. Every tier assumes the tier below it may disappear at any moment and is designed to recover without the wearer noticing.
Evie Ring
PPG · IMU · THERMAL
ON-DEVICE BUFFER
Mobile Applications
BLE STACK · REALM DB
OFFLINE-FIRST QUEUE
Backend Services
OAUTH 2.0 · JWT
SYNC & ANALYTICS API
Cloud
S3 · CLOUDWATCH
POSTGRES · REDIS
The phone is a courier, not a source of truth
The ring owns the raw record until it is acknowledged upstream. The application never deletes a buffer it has not confirmed as persisted, which removes the most common cause of silent loss in IoT wearable device development.
Every write carries a timestamp and an origin
Ring clock, device clock and server clock disagree constantly. Records carry both device time and monotonic sequence, so conflict resolution is deterministic rather than best-effort.
Fourteen modules, delivered as one coherent product.
The companion application is where wearable health app development either earns daily use or loses it. Each module below shipped with its own offline behaviour, its own empty state and its own failure copy because a health app is judged on the days it does not work perfectly.
User Authentication
Secure registration and sign-in by email or social provider, with profile management and API protection through OAuth 2.0 and short-lived JWTs.
Device Pairing
Discovery, secure bonding, firmware updates, battery monitoring and background synchronisation the connective tissue of the whole product.
Health Dashboard
Heart rate, SpO₂, HRV, respiratory rate, skin temperature and readiness, presented against the wearer's own baseline rather than a population average.
Sleep Tracking
Duration, staged architecture, overnight biometrics and long-range trends assembled from data captured while the phone was in another room.
Activity Tracking
Steps, calories, active minutes, distance, workout history and goal progress, reconciled with platform health stores where the wearer permits it.
Women's Health
Cycle tracking, symptom and mood logging, energy patterns and historical insight a first-class module, not an afterthought tab.
Spot Check
On-demand measurement when the wearer wants a reading now, with current and historical results held side by side.
Health Journal
Mood, symptoms, medication, hydration and free-text notes, timestamped so subjective entries can be correlated against objective signal.
Insights & Analytics
Personalised weekly and monthly narratives generated from the wearer's own longitudinal data on the health data analytics platform.
Notifications & Reports
Reminders, battery alerts and wellness prompts, plus PDF and CSV export for wearers who want to bring their record to a clinician.
Settings & Ring Management
Account, privacy, notification, Bluetooth and device controls, including consent withdrawal and full data deletion.
The layer where wearable products quietly fail.
Bluetooth Low Energy (BLE) app development is rarely the headline feature and is almost always the reason a wearable gets returned. Our transport layer assumes disconnection is the normal state and connection is the exception.
Explicit states, not implicit hope
Scanning, bonding, connected, syncing, degraded and recovering are modelled as discrete states with defined transitions, so the interface can always tell the wearer the truth about their ring.
Backoff, retry, resume
Reconnection uses exponential backoff with jitter. Interrupted transfers resume from the last acknowledged chunk rather than restarting, which matters when a night's data is being moved.
Resumable OTA updates
Firmware images transfer in verified chunks with rollback protection, so an update interrupted by a lift or a lost phone never bricks a ring.
Platform-honest sync
iOS and Android grant background execution on very different terms. Sync windows were tuned per platform rather than written once and hoped for.
Checksums on every packet
Corrupted frames are rejected and re-requested. A biometric record either arrives intact or does not arrive — it never arrives subtly wrong.
Nine signals, one screen, no false confidence.
The dashboard is the product's daily contract with the wearer. It presents cardiac, respiratory and thermal signals against a personal baseline, and it says plainly when confidence in a reading is low.
Heart rate & HRV
Continuous resting and active heart rate with heart-rate variability trended over days and weeks, not just displayed as a moment-in-time figure.
SpO₂ & respiration rate
Overnight blood-oxygen saturation and breathing rate captured during the quietest signal window of the day.
Skin temperature deviation
Reported as deviation from the wearer's own established baseline, which is the only form in which the number is useful.
A composite the wearer can interrogate
Readiness combines sleep, recovery and cardiovascular signal and every score can be opened to show which inputs moved it. Composite metrics lose trust the moment they become unexplainable.
Honest gaps beat invented data
Where motion or fit degraded a measurement, the interface shows a gap rather than interpolating. In biometric wearable development, a missing hour is recoverable; a fabricated one is not.
Eight hours of data collected with nobody watching.
Sleep is the hardest data to capture and the most valuable to own. The ring records all night regardless of phone proximity, then reconstructs architecture, duration and overnight biometrics once the two devices meet again.
Phone-independent recording
The ring stores a full night locally. Wearers charge their phone in the kitchen and still wake up to a complete record.
Staged architecture
Awake, REM, light and deep segments derived from combined motion, cardiac and thermal signal rather than movement alone.
Weeks, not nights
Single-night data is noise. Wellness analytics surface the rolling patterns that actually indicate change.
Designed for the wearer this product was built for.
Movano Health built Evie for women. Women's health tracking is therefore a primary surface in the application, combining logged cycle data with continuously sensed temperature, heart rate and HRV to give a fuller picture than either source alone.
Cycle, symptoms, mood, energy
Structured entry that takes seconds, with symptom and mood vocabularies designed with clinical input rather than assembled from guesswork.
Logged data meets sensed data
Subjective entries sit on the same timeline as temperature deviation and cardiac signal, letting the platform surface patterns across cycles instead of within a single one.
The sensor records what happened. The journal records why.
A ring cannot know about a long flight, a new medication or a stressful week. The health journal captures that context, and the insights engine uses it to explain the numbers rather than merely report them.
Journal entries
Mood, symptoms, medication, hydration and free-text notes, all timestamped and attributable to a moment in the biometric record.
Personal baselines
Insight is computed against the individual's own history. Population averages are a starting point, never the reference.
Weekly and monthly narratives
Plain-language summaries and exportable PDF and CSV reports for wearers who want to share their record with a clinician.
Insight that cannot be traced back to a measurement is decoration. Every statement the platform makes can be opened to the data underneath it.
Synchronisation is the product. Everything else is presentation.
Three clocks, two operating systems, one intermittent radio link and a wearer who expects their data to simply be there. The synchronisation model is the single most consequential piece of engineering in the platform.
Incremental, not wholesale
Only deltas since the last acknowledged watermark move upward. Full reconciliation runs rarely and in the background.
Deterministic resolution
Timestamp plus monotonic sequence plus origin decides every conflict the same way on every device no last-writer-wins surprises.
Durable offline queue
Realm-backed local persistence means a flight, a dead zone or a background kill costs the wearer nothing but latency.
Auto-scaling ingestion
Queued ingestion with Redis caching absorbs the morning spike when millions of overnight buffers upload within the same hour.
Time-series meets relational
PostgreSQL for the relational record, S3 for bulk raw signal, Redis for the hot path each store doing only what it is good at.
Instrumented end to end
CloudWatch, Sentry, Firebase Crashlytics and Instabug give one view from firmware anomaly through to a wearer's bug report.
Chosen for longevity, not for novelty.
Every choice below had to survive a decade of firmware revisions, OS releases and regulatory change and had to be maintainable by the client's own team long after we handed it over.
| Layer | Technology | Why it was chosen |
|---|---|---|
| Mobile | Flutter (Android), SwiftUI (iOS) | Shared product velocity on Android with native fidelity and background behaviour on iOS. |
| Firmware | C / C++ with Zephyr RTOS | Deterministic scheduling and a power profile appropriate to a device measured in milliamp-hours. |
| Communication | Bluetooth Low Energy (BLE) | The only transport that meets the ring's energy budget for continuous, all-day synchronisation. |
| Backend | NestJS (TypeScript) | Structured, testable service architecture with type safety shared across the API contract. |
| Database | PostgreSQL, Redis | Relational integrity for the health record; Redis for the hot path and ingestion smoothing. |
| Cloud | AWS EC2, RDS, S3, CloudWatch | Mature managed services with the compliance tooling a health platform requires. |
| Authentication | OAuth 2.0, JWT | Standards-based access control with scoped, revocable, short-lived credentials. |
| Offline storage | Realm DB | Fast local persistence with a reactive query model suited to an offline-first sync queue. |
| Monitoring | Sentry, Firebase Crashlytics | Crash and error visibility across two mobile platforms and the service tier. |
| Bug reporting | Instabug | In-app reporting with session context, shortening the loop between wearer and engineer. |
Six problems that decided the shape of the platform.
Each of these surfaced in real-world wear, not in the lab. The solutions below are the ones that survived contact with production.
BLE connectivity
Connections dropped during ordinary daily use — pockets, lifts, showers, background app termination.
Automatic reconnection with exponential backoff, retry logic keyed to connection state, and on-device buffering so no measurement depends on the link being up.
Battery optimisation
Continuous multi-sensor capture consumed more energy than a ring-sized cell could sustain.
Adaptive sampling that varies rate by context and activity, combined with low-power BLE connection parameters and batched transfer windows.
Data synchronisation
Keeping ring, application and cloud consistent across three clocks and intermittent connectivity.
Incremental synchronisation with watermarks, timestamp and sequence-based conflict resolution, and acknowledged deletion of local buffers only after confirmed persistence.
Privacy & security
Highly sensitive health information moving across consumer devices and public networks.
TLS 1.3 in transit, AES-256 at rest, standards-based authentication, separation of identity from signal, and granular consent with a full audit trail.
Scalability
Overnight buffers from a large installed base upload within a narrow morning window.
Queue-based ingestion, Redis caching and auto-scaling infrastructure sized for peak concurrency rather than daily average.
User experience
A health app is abandoned quickly if it feels slow, uncertain or opaque about its own state.
Optimised rendering against cached local data, background synchronisation that never blocks the interface, honest connection status, and insights tied to visible evidence.
A wearable platform ready for the next decade of health products.
The programme delivered a shipping consumer product and, underneath it, a reusable digital health platform the client can extend into new devices, new markets and new clinical use cases without rebuilding the foundations.
Synchronisation completeness
Overnight and daytime records reconcile reliably even after extended periods out of range, with buffering removing the most common source of data loss.
Platform reach from one contract
iOS and Android applications built against a single data and synchronisation contract, keeping feature parity achievable release after release.
Production modules delivered
From authentication and pairing through to reporting and export, each shipped with defined offline behaviour and failure states.
Fabricated data points
Where signal confidence was insufficient, the platform reports a gap. Trust in a health product is built on what it refuses to claim.
A foundation, not a one-off build
The service layer, sync engine and analytics pipeline are device-agnostic. New form factors and new sensor types attach to the existing spine rather than starting a new programme.
A credible path to clinical
Security posture, audit trails and data governance were built to a standard that supports the move from consumer wellness towards regulated remote patient monitoring.
A production-grade platform typically reaches clinical-quality beta in seven to ten months, covering firmware integration, BLE transport, iOS and Android applications, backend services and analytics. Sensor count, regulatory posture and the depth of the insight layer are the main variables. We usually recommend a four-to-six week discovery to size the transport and data model before committing to a full build.
BLE behaves differently across operating system versions, chipsets and background execution states, and none of those differences are visible in a simulator. Reliable BLE engineering requires explicit connection state machines, retry and backoff logic, on-device buffering, chunked transfer with integrity checks, and resumable firmware updates. Most wearable products that feel unreliable are failing at this layer rather than in the interface.
Yes. Continuous sensing, secure synchronisation and a longitudinal data store are the same primitives a remote patient monitoring platform needs. Extending into clinical use adds clinician-facing dashboards, alerting thresholds, consent and delegation models, and the audit and validation evidence a regulator expects.
TLS 1.3 in transit, AES-256 at rest, OAuth 2.0 with short-lived and revocable JWTs, separation of personally identifiable information from biometric time series, granular per-category consent, and an immutable audit trail covering exports, access and deletion. Our full approach is documented under security and compliance.
Yes. This programme spanned embedded firmware in C and C++ on Zephyr RTOS through to the cloud analytics tier. Wearable platforms fail at the seams between layers, so we prefer to own or co-own the full path from sensor to insight.
Frequently. We start with a transport and data-integrity audit — the two areas where inherited wearable codebases most often carry hidden defects — then stabilise synchronisation before adding features. Talk to our team about an assessment.
Bring us the hardest layer of your wearable programme.
Most teams arrive with the interface designed and the transport unsolved. That is the right time to talk. Send us your sensor spec, your sync problem or your half-finished build, and we will tell you plainly what it will take.