DEV Community

Todd Sullivan
Todd Sullivan

Posted on

Building Personalised On-Device ML for Women's Health: No Cloud, No Population Averages

Most health AI is built on population data. Your symptoms are averaged against thousands of other people, and you get a generalised prediction that fits nobody perfectly.

I took a different approach with Menopause Intelligence — an iOS app I've been building that predicts high-symptom days for women in perimenopause and menopause.

The entire model runs on-device, trained on the individual user's own data. No cloud, no population averages, no third-party data sharing.

The problem with cloud-based health AI

Population models work when you want average answers. But perimenopause is deeply individual. Two women with identical ages and similar symptom profiles can have completely different biometric triggers.

The app's job is to tell a user her patterns — not what typically happens to women like her.

The ML pipeline

Features: Seven signals per day, all from HealthKit/Apple Watch:

  • Basal body temperature delta vs 7-day mean
  • HRV (raw + delta from personal rolling average)
  • Sleep efficiency and deep sleep %
  • REM sleep %
  • Resting heart rate
  • Cycle day (if logged)

Key design decision: We use deltas from the user's personal baseline, not absolute values. A resting HR of 62 bpm means different things for different people. What matters is whether it's elevated for you.

Label: Composite symptom severity score for day D+1 (hot flashes, brain fog, fatigue, mood)

Model: CoreML + CreateML Components. Runs via a silent weekly background task (BGProcessingTask). The app retriggers training automatically as new data accumulates.

Cold start: The first 30 days use a rule-based weighted scorer as a fallback. Not as accurate, but keeps the app useful while data accumulates.

The data architecture

Everything is local:

HealthKit → DailyLog (SwiftData) → Feature engineering → CoreML inference
Enter fullscreen mode Exit fullscreen mode

No backend. No analytics SDK. CloudKit sync between devices uses end-to-end encryption. Health data never touches our servers — because we don't have any.

This isn't just a privacy stance. It's architecturally simpler and removes a whole category of compliance risk. For a health app in this category, "no backend" is a feature you can market.

The feedback loop

User-reported symptoms feed back into the next training cycle. Every hot flash logged, every mood entry — they sharpen the model for that specific user.

This is the same feedback pattern I've used in other on-device vision work: user corrections become training data. The model gets more accurate over time for the individual, not just better at the general case.

What I've learned building personalised on-device ML

Minimum data is a real UX problem. 30 days before predictions activate feels long to a user who downloaded the app because she's struggling now. You have to be honest about why, and give her something useful in the meantime.

Baseline drift matters. A user's "normal" changes over the course of perimenopause. The rolling average window needs to adapt — a fixed 7-day mean becomes stale if someone's baseline HRV is trending down over months.

Privacy is the product. In women's health, trust is everything. "Your data never leaves your device" isn't a footnote — it's the headline. It changes the conversation with users who've been burned by other health apps.

The stack

  • UI: SwiftUI (iOS 17+)
  • Data: SwiftData + CloudKit
  • Biometrics: HealthKit
  • Prediction: CoreML + CreateML Components
  • Subscriptions: StoreKit 2
  • Watch: watchOS companion + WidgetKit

More on this as it gets closer to launch.

Top comments (0)