Your Training Data Is Yours — and That Is Not a Given

150 million MyFitnessPal accounts were caught in a data breach in 2018. Strava’s global heatmap made movement patterns at military sites visible the same year. And the US Federal Trade Commission later accused Flo Health of passing sensitive health information to analytics providers such as Facebook and Google despite promising otherwise.

Those are three very different cases. Together, though, they show something that easily gets lost when comparing training apps:

An app’s features are not the only thing that matters. What data it needs, where that data sits, and what your access to it depends on matter too.

What fitness apps can actually record about you

A Surfshark analysis examined the privacy labels of 16 popular fitness apps in the Apple App Store in January 2026.

On average, the apps declared 12 out of 35 possible data types. The most data-hungry app reached 24.

The wording on sharing matters more: Surfshark reported that 75 % of the apps examined use at least one data type for “tracking”. Apple’s definition of that includes linking app data about a user or a device to data from other companies — for personalised advertising, ad measurement or data brokers, for example.

That is more precise than the shortened claim that “75 % sell your training data”.

The study does not say that every one of those apps collects the same data, or that every instance of sharing serves the same purpose. What it shows is how differently data minimisation is handled within one and the same app category.

Depending on the product, what gets processed can include:

• email address and user ID
• device or advertising ID
• approximate or precise location data
• training and activity data
• body measurements
• heart rate or other sensor data
• photos
• purchases and subscription information
• usage and diagnostic data

A simple strength training diary needs nowhere near all of that.

Three cases show three different risks

Privacy problems get abstract quickly. The examples below show that not every risk looks the same.

MyFitnessPal: whatever sits on a server can become part of a breach

Under Armour reported in March 2018 that an unauthorised party had obtained data from roughly 150 million MyFitnessPal accounts.

According to the company, that included:

• usernames
• email addresses
• hashed passwords

Payment data and government identification numbers were not affected, according to Under Armour.

The point is not that cloud storage is automatically insecure. Professionally operated servers can be very well protected.

The structural difference is a different one: data collected centrally forms a shared target.

Strava: even aggregated data can reveal more than intended

Strava’s global heatmap visualised movement data from many users. In 2018 it became public that running and movement patterns around military facilities were identifiable through it as well.

The US Department of Defense later responded with restrictions on geolocation features in deployed settings.

This was not primarily about a hack.

The data had been collected for a legitimate feature. The problem arose from what could be inferred from the combination of many apparently harmless location points.

Flo Health: privacy promises and actual data flows have to match

The FTC accused Flo Health of transmitting sensitive information from its cycle and fertility app to external analytics providers, even though users had been given a different impression.

The case ended in a binding FTC order in 2021.

The example shows a third type of risk: data theft is not the only thing that matters. Legitimate SDKs for analytics and marketing can become a problem too, when particularly sensitive information ends up in those systems or the privacy policy does not describe the actual data flow cleanly.

Is training data automatically health data under the GDPR?

A more careful formulation pays off here than a blanket yes or no.

Art. 4 No. 15 GDPR defines health data as personal data related to physical or mental health that reveals information about a person’s state of health.

The European Data Protection Board points out that this term is to be interpreted broadly.

That does not automatically mean:

Every piece of information in a fitness app is always health data under Art. 9 GDPR.

What decides it is what can be inferred from the data about the health of an identifiable person.

Obvious examples are:

• heart rate and ECG data
• details of illnesses, injuries or medication
• body data from which concrete health information is derived
• activity data, where the context allows conclusions about a state of health

A single entry like “bench press 80 kg × 8”, by contrast, can say considerably less about health depending on the context.

For app developers this distinction matters: the more sensitive the data and the more health information can be derived from it, the higher the requirements for legal basis, transparency, purpose limitation and protection.

An account is not automatically a privacy problem

Many training apps use accounts because they offer cross-device synchronisation, social features, coaching or web access.

A sign-in can be technically sensible for that.

It gets problematic when registration is not necessary for the actual core function, yet the user cannot get anywhere without an account. In the UX literature that pattern is discussed as forced registration, or a dark pattern.

So for a local training logbook, one simple question helps:

Which specific feature needs my identity?

If the answer is “none”, a local model without an account can be the more data-minimising architecture.

If you do want a community feed, trainer access or automatic sync between several devices, though, the app needs some form of identity and server state.

Privacy is therefore not “cloud bad, local good”.

It is a question of data minimisation and purpose.

What happens when the provider disappears?

With cloud software there is a second issue alongside privacy: dependence on the service.

Jawbone is an instructive example.

The company was liquidated in 2017. The UP trackers relied heavily on the accompanying app and its server service. In 2018 the app became unusable; existing devices could no longer meaningfully do what they were for. Retailers were in some cases still selling remaining stock even though the central service had already gone down.

That is an extreme example, but the principle is more general:

If your training history is only reachable through a proprietary server, your access depends on

• the service continuing to run,
• your account continuing to work,
• the app continuing to be supported
• and an export remaining possible.

A good cloud service can reduce those risks a great deal through exports, backups and clear migration paths.

Offline-first takes a different route: the core function is not meant to exist only by virtue of a running server.

Offline-first is more than “works in airplane mode”

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan described the concept of local-first software in 2019.

The central idea: the local copy should not be merely a temporary cache of a server. It should be the primary working copy. Cloud services can add synchronisation and backup, but the software does not remain wholly dependent on them.

For a training app that has several practical consequences.

The workout does not wait for the server

In a gym with poor reception it should not matter whether an API is reachable right now.

Ticking off a set, changing the weight, starting a timer, saving a PR — those things can happen locally.

Less data has to leave the device

When analysis and storage work locally, not every set has to be transmitted to a central server for the basic function.

That reduces the amount of data that has to be processed externally at all.

A server outage does not automatically make your history inaccessible

When the local database is the primary copy, past workouts stay available on the device.

That is a different failure mode from software whose entire interface is only a view onto a remote data store.

Local-first is still no automatic privacy guarantee

An offline-capable app can in theory still contain tracking SDKs or transmit data as soon as internet is available.

And local data can be lost if the device breaks and no backup exists.

So offline-first replaces neither a good privacy policy nor a backup concept.

It only shifts the technical starting position in favour of local control.

How hitPR implements this

I develop hitPR. The architecture is deliberately built so that the actual training does not depend on a hitPR server.

The details are in the privacy policy. For everyday training, these points are the relevant ones.

Training data stays local

Exercises, sets, weights, plans and PRs are stored locally on the device. The app works without a hitPR account and without a permanent internet connection.

Analytics and crash reports are optional

There are no advertising SDKs and no profiling of your training content. Analytics and crash signals are disabled by default; if you enable them, only the anonymous technical and usage signals intended for that are processed.

Your specific sets and weights are not meant to become a central user profile through it.

Cloud backup is optional

Anyone who enables a backup uses their own cloud storage — iCloud or Google Drive.

The backup is encrypted on the device with AES-256-GCM. The recovery code stays with the user. hitPR runs no central training data server on which I could read your history.

The flip side belongs to being transparent: anyone who loses the recovery code also loses the ability to decrypt an encrypted backup.

Core features need no cloud

Logging, timers, 8 progression systems, the muscle heatmap, PR detection, the plate calculator and the training plans all work locally. Pro adds longer analysis periods, backup and the Watch companion, among other things.

Export is part of owning your data

A backup keeps you working inside the same app. An export has a different job: it is meant to get your data out of the app.

Both matter.

If a training app stores your history for years, the question should not only be how you get in — but also how you get out again.

Five questions that say more than a privacy label

Before you accumulate several years of training in an app, I would check these points:

1. Where does the primary copy of my training data live? Locally, in the cloud, or both?
2. Which features need an account — and why?
3. Can I export my complete history? In a documented, reusable format?
4. Which data goes to analytics, advertising or crash services? Are those features optional?
5. What happens if the provider or the server is gone tomorrow? Can I still get at my data?

A good privacy policy should answer those questions more clearly than a marketing slogan like “privacy friendly”.

Conclusion

A training app does not have to be completely offline to handle data responsibly. Cloud sync, social features and coaching can be good reasons for servers and accounts.

The important point is a different one:

An app should process only the data its features genuinely need — and explain transparently where that data sits and how you get it back out.

Offline-first is no magic privacy seal for that. But for a personal training logbook it is a strong architectural principle: the workout works locally, the history stays on your device, and cloud features become an addition rather than a precondition.

Further reading:

• How to measure training progress: 5 methods that work
• Strength training app without a subscription: still a thing?
• Tracking your training: why a training log counts

Sources

• Surfshark (2026): Fitbit tops fitness apps in user data collection
• Under Armour / SEC (2018): MyFitnessPal data security issue
• U.S. Department of Defense (2018): Wearables and Strava heatmap
• U.S. Department of Defense (2018): Policy on geolocation in deployed settings
• Federal Trade Commission (2021): Flo Health
• EUR-Lex: General Data Protection Regulation, Art. 4 No. 15 and Art. 9
• EDPB (2020): Guidelines 03/2020 on data concerning health
• Kleppmann M, Wiggins A, van Hardenberg P, McGranaghan M. (2019): Local-First Software
• The Guardian / Which? (2018): Jawbone trackers after app closure