LiftLog keeps your training history on the phone

No account, no server, no sync

LiftLog is described as an intuitive, cross-platform gym weight tracking app built with React Native and Expo, and the sentence that defines it is the second one. Everything you log is stored locally on your device, and no sign up is required.

That is a real design decision rather than a missing feature, and it has consequences in both directions. There is nothing to leak, because there is no central copy, and there is no account to lose access to. But there is also no cloud sync by default, no cross-device continuity, and no way to share your history until you decide to run the optional server.

The app runs on Android and iOS, and the README records that web support was removed, with a link to the commit that removed it. So this is a phone application and not a responsive web app that also runs in a browser, which narrows the audience to people who mainly log at the gym on a device.

The feature list is otherwise what you would expect from a good logging app. An interface for logging progression without getting in the way, entirely device local workouts, end-to-end encrypted social feeds for tracking workouts with friends, Material Design 3 with a liquid glass look, internationalisation through Tolgee and Weblate across more than ten languages, and an AI planner that tailors gym plans to goals and body.

The planner is the one that changes the dependency picture, and the README is explicit that it requires running your own server or purchasing pro. That is the line between the free, self-contained application and the part of it that needs infrastructure.

The optional backend: feeds, plans and backups

The backend lives in a separate project and is described in the README as a Dotnet WebAPI for feeds, AI plans and backups. The topics on the repository confirm the .NET side, and the solution file at the root of the repository ties the projects together.

The three things the backend does are worth separating, because they have different reasons to exist.

The social feed is end-to-end encrypted with AES. The documentation set includes a Feed Process document that covers how the feed and sharing work, especially around the end-to-end encryption, and the backend is described as handling the feed. The privacy claim is a structural one: the server relays data it cannot read, which is the only way a shared feed can live on infrastructure the user does not control without the operator being able to read the workout history.

The AI planner is the feature that needs a model behind it, which is why it is gated on running a server or buying pro. A self-hosted planner means the model calls go to an endpoint the user controls.

The offsite backups are the third piece, and they are the reason a user might run a server even without wanting a social feed. There is a Remote Backup document describing how to connect LiftLog to a remote backup server, and a Self Hosting document that covers running the backend for backups, for your own AI planner and for a private feed. There is also a Plaintext Export document for getting the data out as plaintext, which matters for a tool whose primary selling point is that the data stays on the device.

So the backend is optional in the sense that the app works without it, but it is the mechanism for three features that cannot exist locally.

Running the app and the backend from source

The quickstart lists the prerequisites, and they are the standard React Native set. Node.js v18 or later, the Expo CLI installed globally with npm install -g expo-cli, Android Studio for Android, and Xcode for iOS on macOS only.

Then the app is three commands:

cd app
npm install
npm run android   # For Android
npm run ios       # For iOS (macOS only)

The backend is separate, and the README points to backend/README.md for the details of running it, which keeps the two setup paths independent. That separation matches the architecture, since a developer evaluating the app on a phone does not need a .NET server running.

The repository also has a .sln at the root, which tells you the .NET side is a first-class project in the solution rather than a script, and the backend has a .dockerignore at the root, so the backend is expected to be containerised.

Two directories at the root hint at what else lives here. There is a plugins directory alongside a .claude-plugin directory, which suggests the project ships Claude Code plugins, and a scripts directory. There is also an examples directory with a single example, remote-backup, which is the same feature the documentation covers in prose, made runnable.

Documentation that covers the awkward parts

The documentation list is where this project distinguishes itself, because most of the documents describe the parts that are hard to reverse-engineer from the code.

There is the Self Hosting guide for running the backend. There is the Plan File Format document, which specifies the .liftlogplan file format and how to generate plans with an AI for import into the app, which is a notable idea because it makes the AI planner output a file you can inspect and edit before it reaches the phone. There is the Feed Process document on how sharing works, especially around the end-to-end encryption. There is the Remote Backup guide. There is the Plaintext Export document.

Two of them are about internals that would otherwise be invisible. The Workout Worker document describes a component that is an event based bridge between native and JavaScript, and it says what it powers, which is the Android persistent notifications. And the Storage Migrations document explains how on-device data is versioned and migrated, and what to do when you change a stored model.

That last one is the document a self-hosted user should read first, because a local-first application that stores its data in a versioned on-device format has to survive schema changes, and a project that documents how its migrations work has thought about the problem.

The README also notes the history that matters for anyone arriving from the old version. LiftLog was rewritten from the ground up in React Native, and the previous .NET MAUI Blazor implementation is still in the dotnet branch.

Translations, and the house rules for AI contributions

Internationalisation is handled with Weblate and Tolgee, and the README gives the Weblate instance address for the project with an invitation for anyone to create an account and start translating. The feature list claims more than ten languages, and the translation status widget in the README shows the progress per locale.

The contribution policy is worth reading in full, because it says something specific about AI-assisted work. Contributions, issues and feature requests are welcome, and the AI and LLM assisted contributions are welcome too. The condition is that issues and feature requests should be written in your own words, and the README points to an AI Usage Policy section in CONTRIBUTING.md.

That is a narrower permission than it first appears, and a sensible one. A generated issue that reads like a template is hard for a maintainer to triage, and the rule keeps the tracker usable. The same document is linked from the repository's AGENTS.md and CLAUDE.md files, which are the conventions the project expects to be followed by tools and by contributors alike.

The community channels are a Discord server and the app website, and the contributing guide is the entry point for everything else.

AGPL, frequent releases, and a rewritten codebase

The licence is AGPL-3.0, which is the detail to check first if you are considering anything beyond personal use. It is a strong copyleft licence, and unlike the MIT or Apache licences that dominate the open source app world, it carries network use conditions: a modified version offered over a network must be offered under the same terms. For a personal phone app that is irrelevant, and for a team that intends to modify and host the backend it is a decision that needs a lawyer rather than a paragraph.

The release history is busy. Version 4.24.1 came out on 2026-10-19, 4.24.0 on 2026-10-14 and 4.23.3 on 2026-08-30, and the last push to the repository was on 2026-10-19. The versioning is a simple four-part scheme that has clearly been running for a while, given the earlier mention of a March 2025 campaign in the store badge URL.

The applications are distributed in the usual three places, on Google Play, on the App Store, and through Obtainium, which is the route for people who would rather sideload an Android build built from the source repository.

The one structural point to keep in mind is the rewrite. The current code is React Native and Expo, and the earlier .NET MAUI Blazor implementation survives in a separate branch. That history explains a few things about the repository, including the .sln file at the root and the .NET backend, and it means a reader comparing the two branches is comparing two different applications rather than two versions of one.

Editorial conclusion

LiftLog fits a lifter who wants their training history to stay on their own phone, who does not want an account, and who might later want to share progress with friends through an encrypted feed on a server they run themselves. It is the wrong choice if you want the AI planner without running a backend, because the README states that the planner requires your own server or a pro purchase, and it is the wrong choice if you need a web client, since web support was removed. Before adopting it, read the self-hosting and feed process documents, decide whether the feed is worth a server, and check the AGPL-3.0 licence against how you intend to distribute it.

Frequently asked questions

Official sources

1. LiamMorrow/LiftLog on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases