What's Missing From LiftProof v1.0 (and Why)
A complete v1.0 list of what is not in the app. Some of these are deliberate refusals. Some are v1.1 work. None are accidents.
[FOUNDER HARD-WRITE — opening (~150 words): why honesty about gaps is more credible than pretending v1.0 is complete. Pre-empt every "why doesn't LiftProof have X" App Store review by naming the X first. Set the frame: this is not an apology essay, it is a design-decisions essay. The reader should finish the intro understanding that the missing features were not missed — they were considered, and most were rejected for reasons you are about to explain. Reference the v1.x → v2 gates G1 through G8 as the framework that produced the calls, without quoting them verbatim. Voice register: confident, not defensive.]
## What we deliberately rejected
[FOUNDER HARD-WRITE — Cloud sync (~100 words): Gate G4 framing — cloud sync is opt-in at v2.0, not a v1.0 default. Cover the complexity cost, the privacy cost of adding a server you have to trust, and the genuine UX cost of single-device discipline. Make the case that single-device-only is a feature for most lifters at v1.0, not a bug. Acknowledge it is a real limitation for the iPhone + iPad cohort, name them, and point to the v2.0 Phase O path that lands optional CloudKit sync without compromising the privacy default.]
[FOUNDER HARD-WRITE — Social feed (~100 words): Gate G2 framing — social is v2.0, after 6+ months of MVP validation. Cover the brittleness of social systems shipped without moderation budget, the way social features warp product direction toward engagement instead of strength, and the specific failure mode (followers > training quality) that you are refusing. Frame the v2.0 path as "friends free, regional/global leaderboards premium" per Gate G6 without overspecifying.]
[FOUNDER HARD-WRITE — AI form-check (~100 words): Computer vision at consumer-grade is not honest yet for compound lifts. Cover the specific failure modes — squat depth, hip hinge tracking, bar path under load — and the brand cost of shipping a paid feature that does not deliver on its claim. The honest position: when the underlying tech is real, we will look at it. Until then, a "form check" feature that flatters bad reps is worse than no feature at all.]
[FOUNDER HARD-WRITE — Macros / nutrition (~100 words): Nutrition is a separate domain. HealthKit handles the integration for users who already track in MyFitnessPal, Cronometer, or Apple Health. The "lifting app that also tracks nutrition" pattern is a feature creep tell — apps that try to do both usually do neither well. Make the case for staying narrow. Acknowledge the light nutrition correlation work that v1.x might pull in via HealthKit reads only (Gate G8 framing) without overpromising.]
[FOUNDER HARD-WRITE — Plate calculator (~100 words): Plate calc was cut from v1.0 for scope reasons. The honest version is "this is in v1.1, it should have been in v1.0, and the only reason it is not is that we did not have time to build it right without delaying ship." Do not over-apologize. State the v1.1 commitment. Note any workaround that exists in v1.0 (mental math, third-party plate-calc apps).]
[FOUNDER HARD-WRITE — Custom rest days / deload nuance (~100 words): Per-day rest customization is handled at the program level rather than per-day for v1.0. Cover the design rationale (program-level recovery is more honest than per-day toggles that lifters fiddle into uselessness), the deload protocol you do support (programmed deload weeks within the named programs), and the v1.x candidate path for finer-grained customization if user feedback supports it.]
## What's coming in v1.1
[FOUNDER HARD-WRITE — Cloud sync v2.0 path (~100 words): The shape of the v2.0 cloud sync feature without overcommitting timeline. Sign in with Apple required, CloudKit private database, encrypted at rest and in transit, single-account multi-device only (no shared accounts in v2.0). Why CloudKit specifically: Apple-platform native, no third-party server, the trust surface is one Jonathan already trusts. v2.0 Phase O is the per-phase plan name.]
[FOUNDER HARD-WRITE — Sign in with Apple optional account (~80 words): Per v2.0 Phase N. SIWA stays optional — the no-account default does not change. SIWA exists only to enable cloud sync and cross-device data restoration. No social features, no profile, no public-facing user identity. The privacy default (anonymous local) is preserved as the v2.0 baseline.]
[FOUNDER HARD-WRITE — es-MX localization Phase D4 (~80 words): Spanish (Mexico variant first) is the first localization. Why es-MX before es-ES — covers the spillover audience size, the strength training cultural context in Mexico (training language conventions, exercise naming, regional powerlifting federations), and the readiness check on the rest of the app for localization mechanics. Other locales follow on user demand.]
[FOUNDER HARD-WRITE — v1.1 polish per Gate F decisions (~80 words): Other v1.1 work that does not fit a single-feature paragraph. Plate calculator (committed), program library expansion (which programs in the queue), Progress chart refinements based on user feedback, paywall presentation refinement, and the App Store rating prompt timing if that is in v1.1 scope.]
## What might never come
[FOUNDER HARD-WRITE — AI form-check until consumer CV is honest (~80 words): The "never until the tech is real" position restated more sharply. Set the bar for when we would reconsider — what specific accuracy thresholds, what specific compound-lift coverage, what failure-mode budget.]
[FOUNDER HARD-WRITE — Real-time social posting until v2.0 Tier 3 minimum (~80 words): Per Gate G1 (Tier 3 social is "maybe — design reachable, build after MVP"), real-time social posting is a Tier 3 ask, not a Tier 1. The bar for Tier 3 is post-MVP validation plus moderation budget, not user demand alone.]
[FOUNDER HARD-WRITE — Cross-platform single codebase (~80 words): The Android port is in flight as a separate native Kotlin codebase. It will not be a Flutter rewrite, it will not be a React Native rewrite, and the iOS and Android codebases will not share business logic. The honest reason: cross-platform abstractions cost more than they save once you care about platform-native fitness app patterns (Apple Watch, Health Connect, native widgets, native Live Activities).]
## What I'd build first if I had more time
[FOUNDER HARD-WRITE — Plate calculator and freestyle workflow defaults (~100 words): The two things that are not technical refusals, just time-box casualties. Plate calculator is the easy one — it is v1.1. Freestyle workflow defaults are the harder one — most v1.0 users come from a fixed-program background, but a meaningful cohort builds workouts on the fly, and the v1.0 freestyle path is functional but not first-class. Sketch what "first-class freestyle" would feel like.]
## Closing
Press: jonathan@liftproof.app or press@liftproof.app. Bug reports: feedback@liftproof.app. I read every email. The launch announcement essay lives at /blog/v1-launch-announcement/. The privacy stance lives at /blog/why-on-device-only/. The full GHC privacy listicle lives at https://gethealthycalculators.com/blog/best-lifting-apps-privacy/.