Your health and fitness data should never leave your iPhone.

79% of health apps share user data with third parties. Here's what a genuinely private fitness app looks like — and why on-device AI produces better recommendations.

What Actually Happens When You Tap “Log Session”

The deal most fitness apps offer goes something like this: you give them your workout history, your GPS routes, your heart rate data, and your behavioral patterns, and they give you a place to log your sets. Most people don’t know they’ve agreed to this. The terms are in the privacy policy.

A 2019 cross-sectional study published in the BMJ analyzed popular health and fitness apps and found that 79% shared user data with third parties, and most collected data categories beyond what was required for the app’s stated function.1 Fitness apps consistently collected location, device identifiers, and behavioral data — often without clear disclosure.

Your workout data is more sensitive than it looks. And most apps aren’t treating it that way.


“I Have Nothing to Hide” Is the Wrong Frame

The common response to fitness data privacy concerns is “I have nothing to hide.” This conflates privacy with secrecy. Privacy isn’t about hiding. It’s about control — specifically, the right to decide what happens to information about you.

Your training data, combined with the other information fitness platforms hold — age, weight, health goals, location, behavioral patterns — forms a detailed portrait of your physical capabilities, health status, schedule, and habits. Health insurers, life insurers, employers, and data brokers have demonstrated clear interest in exactly this kind of information.

The data broker ecosystem is not hypothetical. Companies routinely purchase behavioral and health-adjacent data from apps and aggregate it into profiles used for underwriting, targeting, and risk assessment. The average fitness app user has no visibility into where their data goes after it leaves the app. “I trust this company” is not a durable guarantee. Companies get acquired. Servers get breached. Privacy policies change.2


What a Genuinely Private Architecture Looks Like

Understand the architectural difference that actually matters

Most fitness apps are server-first: the app on your phone is a front-end, and the actual processing — recommendations, analysis, AI — happens in the cloud. This architecture requires your data to leave your device. It’s not a policy choice. It’s a structural requirement. On-device processing inverts this. The computation happens on your iPhone. The AI reads your training history, generates a recommendation, and delivers it — all without any data transmission. Not because the company promises to protect it, but because it was never sent anywhere to begin with.3

Require no-account architecture from your fitness apps

An account creates a persistent identity that can be tracked, linked to other data sources, and retained indefinitely. No account means no credentials to compromise, no profile to build, no email address to harvest, and no persistent identifier linking your workout data to your real-world identity. The friction of account creation is not just an onboarding inconvenience. It is the creation of a data relationship that most users don’t fully consider at signup.

Read the data sharing section of the privacy policy, not the marketing copy

Marketing copy says “we take your privacy seriously.” Privacy policies say what data is collected, how it’s used, and who it’s shared with. The gap between the two is frequently significant.

Choose tools that make privacy architectural rather than policy-dependent

The strongest privacy guarantee is one that doesn’t require trusting anyone. On-device processing, no-account architecture, and no server infrastructure eliminate the need for trust because they eliminate the infrastructure through which trust could be violated.

Somatic has no servers. No accounts. No third-party data sharing. All AI processing happens entirely on your iPhone using Apple’s on-device frameworks. Your training history, health data, and behavioral patterns never leave your device — not as a promise, but as a structural fact.


What Six Months of Data Actually Looks Like

Consider what a fitness app typically knows after six months of use: your name, email, age, weight, body fat percentage if entered, workout frequency, exercise selection, performance trends, GPS location of workouts, heart rate data, sleep patterns if integrated, and behavioral patterns around when and how you use the app.

Aggregated and sold to a data broker, this information has significant commercial value. Individual users don’t know when this happens, have limited recourse when it does, and typically consented through a terms-of-service document they didn’t read.

The alternative isn’t less functionality. On-device AI models running on recent iPhones are sophisticated enough to provide genuinely personalized recommendations using local data. A system that knows your full history and processes it locally can produce more relevant recommendations than a cloud model working from a privacy-constrained dataset.


Privacy in fitness apps is not a niche concern. It is a direct consequence of the business models most apps use — and most users don’t realize what they’re consenting to when they sign up.

The alternative isn’t a compromise. It’s a better architecture: on-device AI that knows your full history, processes it locally, and delivers a genuinely personalized recommendation without sending anything anywhere.

Your training data is yours. It should stay that way.

No subscription. Your data never leaves your iPhone. Join the beta via TestFlight.


  1. Grundy Q et al. (2019). “Data sharing practices of medicines related apps and the mobile ecosystem: traffic, content, and network analysis.” BMJ, 364, l920. ↩

  2. Huckvale K et al. (2019). “Unaddressed privacy risks in accredited health and wellness apps: a cross-sectional systematic assessment.” BMC Medicine, 17(1), 1–13. ↩

  3. Sweeney L (2002). “k-anonymity: A model for protecting privacy.” International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(5), 557–570. ↩