Why On-Device Only — The Privacy Stance Behind LiftProof v1.0

Privacy-first is a marketing line most apps use the same way they use "premium quality" — a phrase that fills space without committing to anything. LiftProof v1.0 makes it specific. There are four engineering decisions behind the privacy posture and each one is reversible only at a real cost. This essay names each decision, explains why we made it, and acknowledges the tradeoff it created. If your reaction to the v1.0 limitations (no cross-device sync, no account-based backup, no remote support workflow) is "that is unacceptable," at least you will know the precise reason each limitation exists. We chose every one of them on purpose.

The frame: a strength training app generates a multi-year personal record of your body — what you can lift, how often you train, the intensity you carry into each session, the recovery you protect or skip. That data set is a portrait. A portrait of your body is a thing worth protecting at the engineering level, not just the policy level. The four decisions below are how we protect it.

## The four engineering decisions

[FOUNDER HARD-WRITE — Why no account at v1.0 (~100 words). The "no user account" call. Cover: anonymous local default per Gate G3, the trust posture (no email collected, no password stored, no account database), the v2.0 Phase N path that adds optional Sign in with Apple without changing the default. The honest cost: no cross-device restore at v1.0, no "I lost my phone" recovery flow, no shareable account identity. Why that cost is acceptable in v1.0: Core Data on a Face-ID-locked device is a strong default for one-person, one-device training records.]

[FOUNDER HARD-WRITE — Why on-device Core Data (~100 words). The "all data lives in Core Data on the device" call. Cover: SQLite + Core Data + iOS file protection, why we did not pick CloudKit at v1.0 (cloud sync is opt-in v2.0, not v1.0 default), why we did not pick a custom server (the trust surface we would have to ask users to extend to a server we operate). The data shape: workouts, sets, RPE entries, PR records, program state, exercise customizations — all of it local. Backup pathway: iCloud device backup carries the Core Data store if enabled, so the user already has a backup if they want one, without us operating the storage.]

[FOUNDER HARD-WRITE — Why HealthKit read-only (~100 words). The "HealthKit reads, never writes without explicit user action" call. Cover: read scopes (workouts, heart rate, body mass for tracking), the deliberate refusal to auto-write workouts to Apple Health (the user opts in per-workout to write, or never), the privacy-policy implication of HealthKit (Apple's on-device guarantee plus our additional pledge not to retain or sync HealthKit data off-device). The honest cost: less seamless integration than apps that auto-write, more user friction at workout completion. Why acceptable: the read-only-by-default posture is what makes HealthKit safe to use.]

[FOUNDER HARD-WRITE — Why no analytics SDK (~100 words). The "no Mixpanel, no Amplitude, no Firebase Analytics, no Plausible-in-app, no anything" call. Cover: the specific SDKs evaluated and rejected, the engineering reality that analytics SDKs add 1–4 MB to the binary plus background network activity plus a third-party data flow, the brand cost of a "privacy-first" app that ships a tracking SDK. The honest cost: we are blind to in-app usage patterns — we cannot tell which programs are run most, which features get touched, which paywall variants convert. Why acceptable: App Store ratings, user emails, and Plausible-on-the-marketing-website (server-side, no cookies, no PII) give us enough signal without compromising the in-app posture.]

## Tradeoffs we accepted

No cross-device sync at v1.0. If you train with iPhone and iPad, your data does not move between them in v1.0. This is the most-asked-about limitation in TestFlight feedback and we hear it. The v2.0 Phase O path adds optional CloudKit sync — Sign in with Apple, CloudKit private database, encrypted at rest and in transit, single-account multi-device. The "optional" matters: the anonymous local default does not change in v2.0. If you want sync, you opt in. If you do not, your v1.0 posture is preserved.

No remote support workflow. If you write to support with a problem, we cannot inspect your data the way an app with a server-side admin panel can. We troubleshoot from your description and from any screenshots you send. This is slower than the "let me look at your account" pattern most app support teams use. The benefit is symmetric: we cannot leak what we cannot see. If your data set is sensitive enough that the privacy posture is what brought you to LiftProof, the slower-support tradeoff is part of what you bought.

No "I lost my phone" recovery. If you lose the phone and have iCloud device backup off, the data is gone. The iCloud device backup path (Apple's built-in feature, on by default for most users, transparent to the app) is the v1.0 recovery story. We do not add a second backup layer on top because doing so would require either a server we operate (refused at v1.0) or a CloudKit path that lives behind the v2.0 Sign in with Apple gate. If iCloud backup is off and you skip the v2.0 sync, the data is local-only for real. State that openly.

No A/B testing. We cannot run remote feature flags or A/B test paywall variants because there is no analytics SDK to measure them with. App changes ship to everyone or to no one. This makes shipping slower and more deliberate. It also makes it impossible for us to silently roll out a worse paywall to half the users and call it a "test." We trade speed for symmetry.

## The v2.0 path

v2.0 is the planned moment to land optional cloud features without breaking the v1.0 posture. The framework is Gate G4 (cloud sync is opt-in, never default) and Gate G7 (privacy-first as the differentiator). What we are building toward: Sign in with Apple as the optional account, CloudKit private database for the sync layer, end-to-end encryption where the platform allows it, single-account multi-device only (no shared accounts), and a clear toggle in settings that turns the whole thing back off and returns the app to v1.0 local-only behavior at any time.

What we are not building toward: a social feed, a public profile, a leaderboard that requires us to host your data, an analytics SDK, a third-party identity provider beyond SIWA, or any feature that requires us to read your training data on a server we operate. Those refusals do not have a v2.0 expiration date. They are the brand.

## Why this matters

The current default in fitness apps is "we will collect everything by default because we might need it, and you can opt out in settings if you read the policy." LiftProof inverts the default: we collect nothing by default because we already do not need it, and you can opt in to specific features (HealthKit reads, future cloud sync) when you decide the value exceeds the surface they create. That inversion is the entire point. Lifting data is personal enough to deserve the inverted default, and a strength training app is small enough that the inverted default is engineering-feasible without a giant team.

If the inverted default matters to you, LiftProof v1.0 is built around it. If it does not — if you happily accept the standard fitness-app data tradeoff — there are great apps on the App Store built around the standard tradeoff and we cite some of them in the comparison essays. The point is not that one posture is right and the other is wrong. The point is that the posture should be a deliberate choice the user makes with full information, and the engineering should match the marketing.

Cross-links. Comparable rankings of privacy-first lifting apps live at https://gethealthycalculators.com/blog/best-lifting-apps-privacy/. The full launch essay lives at /blog/v1-launch-announcement/. The list of what v1.0 deliberately rejects (and why) lives at /blog/whats-missing-from-liftproof-v1/. If you want to talk through the privacy posture, jonathan@liftproof.app reaches a human.