FitMe: A Privacy-First Fitness Command Center for iPhone

Most fitness apps ask you to trade a little more personal context for a little more convenience. FitMe takes the opposite starting point: put training, nutrition, recovery and body composition in one iPhone command center, then keep the data path as local and explicit as possible. The project's README describes it as privacy-first with federated AI rather than a cloud dashboard that silently absorbs the whole profile.

FitMe is the product name; the GitHub repository is still named FitTracker2. It is an open-source SwiftUI iOS project from Regev Barak, and its GitHub repository is the source of truth. The companion FitMe showcase explains the product narrative and architecture, but the repository is where current setup requirements and code live.

What It Does

Training is the centre of the app. The repository describes an 87-exercise library and a six-day push/pull/legs split, with set-by-set weight, reps and RPE logging. A floating rest timer uses haptics, PR detection marks progress, and Epley's formula estimates one-rep max values so the same session can be read as a workout log or a longer-term strength trend.

Nutrition is connected to the training context rather than treated as a separate calorie notebook. Dynamic macros can adapt to a training day and program phase; meals can be entered manually, from templates, through English or Hebrew label OCR, or from an Open Food Facts barcode lookup. Supplement streaks and different hydration targets for training and rest days complete the daily layer.

Recovery and biometrics add the context that most workout-only trackers miss. HealthKit can provide heart rate, HRV, VO2 Max and sleep stages; a Xiaomi S400 smart scale contributes ten body-composition metrics. FitMe's readiness score is described as 40% HRV, 30% resting heart rate and 30% sleep, with Recovery Studio turning that signal into a lower-intensity alternative when the body is not ready for the planned session.

How to Install It

At the time of review, FitMe has no public App Store listing and the GitHub repository has no published Release asset to download. The README instead asks contributors to open the Xcode project with Xcode 16+ and an iOS 17.0+ deployment target. That makes a source build the honest primary installation path here; do not expect a ready-to-run IPA from the repository.

# Clone the source repository:
git clone https://github.com/Regevba/FitTracker2.git
cd FitTracker2

# Open in Xcode 16+, select an iOS 17+ simulator or device,
# then run the FitTracker scheme.
open FitTracker.xcodeproj

This is a developer-oriented setup, not a one-click consumer download. You need Xcode 16 or newer, an iOS 17 or newer simulator or device, and the repository's setup instructions for any optional services you want to enable. HealthKit permissions are granted at runtime, while authentication, sync and analytics require their own configuration. Start with a simulator or a test device and do not paste production secrets into a public checkout.

How to Use It

The Today view is intended to be the daily entry point: see readiness, the current training plan, macro and hydration targets, and the next action without opening four separate apps. During a workout, log weight, repetitions and RPE set by set; use the rest timer when you need a consistent interval, then let the app calculate PR and estimated one-rep-max signals from the session.

The useful workflow is deliberately cyclical. A training day changes the nutrition and hydration context, recovery data can influence whether the planned session is sensible, and the resulting workout becomes part of the statistics view. The app also exposes daily, weekly, monthly, three-month and six-month windows across 18 metrics, so a single good workout does not have to carry the whole story.

iPhone
├─ SwiftUI views
├─ EncryptedDataStore
│  ├─ AES-256-GCM + ChaCha20-Poly1305
│  └─ Keychain / Secure Enclave
├─ HealthKit service
├─ AI Orchestrator
│  ├─ local rules
│  ├─ cloud cohort (banded, k≥50)
│  └─ Foundation Models (iOS 26+)
└─ encrypted .ftenc sync → CloudKit / Supabase

Settings are where FitMe's privacy promise becomes concrete. The project documents encrypted local data, biometric access through Keychain and Secure Enclave controls, optional HealthKit integration, and a zero-knowledge sync design in which the server receives encrypted .ftenc blobs rather than readable fitness records. Apple Sign In and Passkeys are available authentication paths, but enabling an account does not remove the need to understand which services are turned on.

Morning
├─ sleep + HRV + resting heart rate
├─ readiness score
├─ training-day macros and hydration target
└─ today's workout / Recovery Studio

During the day
├─ log sets, RPE, meals and supplements
├─ optional barcode / OCR entry
└─ keep the data local unless sync is enabled

Evening
└─ review trends and prepare tomorrow's plan

The Screenshots

The public README currently marks its detailed demo screenshots as coming soon, so there is not a finished screenshot gallery to use as proof of every screen. The showcase site supplies the product narrative and architecture diagrams, while the cover here is an editorial illustration rather than a capture from the app. Treat the repository's current build and docs as the authority for what is actually available today.

How It Works Under the Hood

FitMe's storage design layers several protections instead of treating a login as the same thing as privacy. The repository describes AES-256-GCM and ChaCha20-Poly1305 encryption, HMAC-SHA512 integrity protection, and biometric Keychain or Secure Enclave access controls. CloudKit private storage and Supabase can carry the synchronisation path, but the intended payload is an encrypted blob that the service cannot read as a normal workout database.

The AI path is confidence-gated rather than one giant always-on model. Local rules handle the first layer; a cloud cohort can contribute only banded values when the cohort reaches k≥50; and on-device Foundation Models are available on iOS 26 or later. That sequence supports useful recommendations while reducing the need to upload raw personal measurements, and it leaves an offline fallback when a remote or newer model is unavailable.

The Repository and Its Releases

The FitTracker2 repository contains the SwiftUI app, token checks, documentation, an AI-engine area and the dashboard or service pieces around the client. The README lists HealthKit, Apple Sign In and Supabase OAuth, Passkeys, CryptoKit, CloudKit private databases, Supabase Postgres/Realtime, a FastAPI service on Railway, Foundation Models and consent-aware Firebase Analytics. The repository is broad enough that the iPhone target is only one part of the full system.

There is no versioned public release to pin to in this review; the useful version marker is the current main branch and its documented iOS 17.0+ target. That matters for reproducibility: a source build can move as the repository changes, and optional back-end services may require configuration that is not represented by the Xcode project alone. Read docs/setup/ and the relevant legal documents before treating a local build as production-ready.

What You Can Verify Before Building

A cautious first run is simple: read the repository README, check the iOS deployment target and Xcode version, inspect the setup files for required service configuration, and run the project's local verification commands if you are contributing. Then decide whether you need HealthKit, cloud sync, Passkeys, analytics and AI features at all. Disable integrations you do not need and test deletion or export behavior before importing a complete health history.

Where It Falls Short

The main limitation is distribution friction. Without an App Store build or a GitHub Release asset, a non-developer user must install Xcode, resolve the project configuration and sign the app for a simulator or device. That is appropriate for an open-source project under active development, but it is not the same experience as downloading a finished fitness product from the App Store.

The second limitation is platform and data dependency. HealthKit, Foundation Models, passkeys, cloud sync and the Xiaomi scale each have device, OS, account or hardware conditions. The app can present a unified command centre, but it cannot manufacture sleep stages, HRV or body-composition measurements when the source device does not provide them. A readiness score is a decision aid, not medical advice.

Finally, privacy is a configuration boundary, not just a marketing label. Local encryption and zero-knowledge sync are strong design choices, but Supabase, Railway, Firebase, Apple authentication and any cohort service are still external systems when enabled. Health data also has a human consent and retention dimension: review the privacy policy, understand deletion/export behavior, and do not use an experimental build as a clinical record or diagnosis tool.

The Licence: What You Can Do

FitMe is released under the MIT licence. You may inspect, modify and redistribute the repository's code, including in a commercial or closed-source product, as long as the copyright and licence notice travel with the substantial code you redistribute. MIT does not require you to publish your modifications.

That permission covers the project code, not automatically Apple's SDKs, downloaded Foundation Models, Open Food Facts data, Supabase or Railway services, Firebase, or any other dependency. Those components keep their own terms. HealthKit data also remains subject to Apple's platform rules and the consent expectations that apply when an app reads or writes personal health information.

Should You Build It

If you want one inspectable iPhone workspace for workouts, macros, recovery and body composition, FitMe is an ambitious open-source project with an unusually explicit privacy architecture. Build it from the FitTracker2 source, start with local rules and the features your device actually supports, and add sync or cohort AI only after reviewing the data path. It is a good fit for developers who value control and are comfortable with Xcode; it is not yet a frictionless App Store replacement.

# Clone the source repository:
git clone https://github.com/Regevba/FitTracker2.git
cd FitTracker2

# Open in Xcode 16+, select an iOS 17+ simulator or device,
# then run the FitTracker scheme.
open FitTracker.xcodeproj