The first real architectural decision we made on Haea was this: no server. Your health data stays on your iPhone, full stop. No cloud sync to Purplelink's infrastructure, no processing on our end, no data stored anywhere we control.
It's a hard constraint. It rules out features that would be straightforward with a server — cross-device sync that works instantly, personalized recommendations trained on aggregate data, collaborative features. We gave those up deliberately. Here's why.
Health data is different
Most apps treat your data as an asset. It's used to personalize ads, train models, improve the product, or sometimes sold outright. For lifestyle data — what music you listen to, what articles you read — that tradeoff might be reasonable. For health data, it isn't.
Sleep patterns, menstrual cycles, medication adherence, weight trends, biometric readings — this is data that can affect your insurance rates, your employment, your relationships. It's data that people have been discriminated against for. It belongs to you, and only you.
Putting health data on a server means creating a target. Servers get breached. Companies get acquired. Business models change. Any health data we stored could eventually end up somewhere we didn't intend. The only reliable way to prevent that is to never have it in the first place.
On-device ML is genuinely viable now
The practical reason on-device health analytics wasn't common five years ago is that the compute wasn't there. Running Kalman filtering on a week of biometric data in real time, or computing Granger causality between health variables, required server-side processing.
Apple Silicon changed that. The Neural Engine on a current iPhone does machine learning inference at a speed that would have required a server cluster a few years ago. The models we run in Haea — Kalman-filtered recovery state, circadian rhythm phase tracking, TDEE calculation, VO₂ max estimation — all run in milliseconds on-device.
This isn't a compromise. On-device computation is faster than a round trip to a server. Haea's analytics are available instantly, offline, without latency. The privacy constraint turned out to be the performance-optimal choice too.
What we gave up
We want to be honest about the tradeoffs. Cross-device sync for Haea uses iCloud via HealthKit — Apple's own infrastructure, not ours — which means it's reliable but has the constraints Apple imposes. Some features that are easy with a server are genuinely hard without one.
We also can't build certain types of population-level intelligence. A server-side health app can tell you "users with your sleep pattern tend to have lower recovery scores on Tuesdays." We can't — we don't see any user data at all. That's a real limitation we accepted.
Why it's worth it
The health apps people stick with long-term are the ones they trust. Trust is hard to rebuild once it's lost, and health data breaches are the ones people remember. By making the on-device architecture a core constraint rather than an afterthought, we can make a promise to users that most apps can't: we literally cannot access your health data, because we never receive it.
That's not just a privacy policy. It's an architecture decision. And it's the decision that makes Haea worth building.
Haea is coming to the App Store in 2026. Join the waitlist to be notified at launch.