wger Flutter: a phone client for a self-hosted fitness server

The Flutter app is a client, and the server holds the data

The README is unambiguous about the architecture: this is the mobile app written with Flutter, it talks via REST with the main server. The application manages and tracks your exercises and personal workouts, weight, and diet plans, and every one of those records lives in the wger server rather than on the handset.

That single design choice decides most of the practical consequences. The app is not a standalone tracker that works in airplane mode with a local database. It is a front end for a wger deployment that somebody hosts, and the app is useful to the degree that your server is running, reachable, and populated.

The reason the project is structured this way is visible in what the platform carries. wger is described as a free, open source application whose goal is a flexible fitness and nutrition manager along with a comprehensive list of exercises and ingredients, all released under a free licence. The catalogue of exercises and ingredients is a substantial asset in its own right, and it is maintained on the server side with the data itself, which is exactly the kind of content that does not belong in a mobile binary that is distributed through app stores.

So the phone holds your session and your navigation, and the server holds the catalogue, the plans, and the history. A team that wants its members to log workouts without handing their training history to a vendor needs to think about operating a wger instance, and the app is only half of that decision.

One application id across four distribution channels

The README links the app from four places, and the naming makes the packaging arrangement clear.

The Android builds are published as de.wger.flutter on Google Play and on F-Droid, and the same identifier appears on Flathub for the Linux desktop. The iOS build sits on the App Store as wger Workout Manager. The repository also contains a flatpak/ directory and a fastlane/ directory, which is the standard pairing for producing the F-Droid and Flathub artefacts and for the store metadata, and the fastlane metadata directory holds the Android screenshots that the README embeds.

The platform directories in the repository tree confirm the reach: android/, ios/, linux/, macos/, web/, and windows/. That is more platform coverage than a phone-first project needs, and it follows from the fact that this app is a front end for a server the user controls. A user running their own wger instance on a home server can, in principle, use the desktop or web build from the same codebase.

The release numbers give a sense of the pace: 2.1.1 on 2026-10-03, 2.1.0 on 2026-08-28, and 2.0.5 on 2026-08-21. A minor bump followed by a patch bump inside a fortnight is the rhythm of a project with a steady stream of user reports.

The last push to the master branch was on 2026-10-19.

Running the app locally against a server whose database resets daily

The development instructions are short, because this is described as a regular Flutter application with no magic involved. You launch it with the Flutter tool:

flutter run

The catch is stated immediately after: you need a backend for this, and the project suggests using the test server, whose database is reset daily. The credentials are published in the README:

* URL: `https://dev.wger.de`
* username: `user`
* password: `flutteruser`

Pointing a local build at dev.wger.de is the intended first run, and it works because the app only speaks REST. Nothing about the client is bound to a development build of the server, which means you can also point it at your own instance once you have one.

The repository tree shows the supporting machinery for that workflow. There is an integration_test/ directory and a test/ directory, plus test_driver/, test_data/, and a dart_test.yaml at the root, so the project has both unit and integration level testing conventions in place. The schema.json file and build.yaml suggest a code generation step, and l10n.yaml drives translation extraction, with the translations themselves hosted on Weblate under the wger project.

Exercises, workouts, measurements, and diet plans are four different objects

The screenshots the README embeds are the quickest way to see the scope: a dashboard, a measurements screen, and a nutritional plan. The feature set the README describes covers exercises and personal workouts, weight, and diet plans.

The ingredients side deserves a separate note because it is where the platform differs from a generic workout logger. A diet plan in wger is built from a catalogue of ingredients with nutritional values, and the project describes the goal as a combined fitness and nutrition manager rather than a training diary with a weight field bolted on. The exercise database is described as comprehensive and is contributed to by users, which means the catalogue is the community asset that the mobile app consumes.

Licensing differs across those two kinds of content, and the README is explicit about it. The application code is AGPL 3+, while the initial exercise and ingredient data is licensed additionally under one of the Creative Commons licences, with the individual entries carrying their own detail. That split is what allows the data to be shared under terms designed for content rather than for software.

For an adopter, the practical question is which of these you want to run yourself. You can use a public instance and contribute exercises back to it, or host your own and own the whole catalogue. The app does not change between those choices.

The AGPL app store exception is the clause that makes store distribution legal

The licence section is the most legally interesting part of the README, and it is more specific than the bare AGPL label suggests. The application is licensed under the GNU Affero General Public License 3 or later, with an app store exception.

The exception works like this. As additional permission under section 7, you are allowed to distribute the software through an app store even if that store has restrictive terms and conditions incompatible with the AGPL, provided the source is also made available under the AGPL, with or without that additional permission, through a channel that does not carry those restrictive terms.

That is the reason the app can sit on Google Play and the App Store at all. Without the permission, the conflict between store terms and copyleft obligations would make distribution through those stores doubtful. The permission is not a blanket waiver, and it is not legal advice, but it is the mechanism the project relies on, and anyone building a fork and shipping it through a store is relying on the same clause.

The second half of the licence story is the data, licensed under Creative Commons terms per entry. Fork operators therefore inherit two licence regimes at once: the code under AGPL 3+ with the section 7 permission, and the catalogue under the per-entry Creative Commons terms.

Where the wger Flutter app is the wrong tool

The obvious case is a user who does not want to run a server. The app is a client for a wger instance, so without one there is nothing to talk to. A commercial fitness service with its own cloud account is a different product entirely, and for someone who wants their history to be looked after by somebody else, the app is the wrong shape of tool.

The second case is a team that wants a mobile app with no server to deploy. The REST approach is good for keeping data in your own hands and it is what makes the Android, iOS, and Linux builds work against the same deployment, but it also means every deployment of the app has to be paired with a maintained server. The operational burden sits with the adopter, and the project does not describe a hosted option for it.

The third case is offline use. Nothing in the README describes offline logging or a local cache that survives a lost connection, so a user in a gym with poor signal should expect to wait rather than to queue. The test server guidance reinforces the point: the everyday workflow assumes a reachable backend.

The fourth is a fork that needs different data. Changing the exercise and ingredient model touches the server side as well, and the app is only the client half of the system.

Contribution runs through Weblate, fastlane, and an issue tracker

The project asks for help in several forms, code, translations, exercises, and issue reports, and the README points everyone at the contribution guide published in the wger documentation. The Discord server is where contributors introduce themselves, and the README lists an issue tracker on GitHub and a Mastodon account alongside it.

The tooling in the tree matches that workflow. A Gemfile and Gemfile.lock sit at the root, which is how the Ruby based release tooling is pinned. fastlane/ holds the store metadata and the automation used to prepare the Android and desktop builds, flatpak/ holds the Flathub packaging, and CHANGELOG.md and CHANGELOG.template.md show that release notes are generated from a template rather than written from scratch.

The AUTHORS.md file at the root is a further sign of how the project treats its contributors, and the repository is tagged with the Hacktoberfest topic, which is a concrete way for new contributors to find an entry point.

Activity on the branch is current: the last push was on 2026-10-19, a fortnight after the 2.1.1 release, so the published build and the source tree are close to each other rather than months apart.

Editorial conclusion

Adopt the wger Flutter app if you already run or plan to run a wger server and want to log workouts, measurements, and nutrition from a phone against your own data rather than a hosted account. Do not adopt it if you want a client that works without a server you operate, and note that the exercise and ingredient catalogue arrives with the server, not with the app. Verify three things before you rely on it: that the AGPL 3+ terms with the section 7 app store exception match how you distribute binaries, that your server version exposes the REST endpoints the app expects, and that the daily reset test server at dev.wger.de is acceptable for your experiments, since its database is wiped every day.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. wger-project/flutter on GitHub