FoodYou: an Android nutrition tracker that keeps your diary on the phone

A food diary with no account and no server

FoodYou is described as a free, open-source and privacy-focused food diary and nutrition tracker, and it is written in Kotlin for Android. The privacy claim is the concrete one: no account is required and all data is stored locally on the device.

That single design choice determines what the app is for. A nutrition tracker that needs a login is also a service that holds your eating record, and a service that holds your eating record can change what it does with it. FoodYou removes that party from the picture, which is the reason to prefer it over a commercial tracker even when the commercial one has more social features.

The app is built on the Android design guidelines with dynamic colour, so the interface picks up the colour scheme of the device it runs on. The homepage is a modular one: you compose it from functional cards that suit your habits, rather than accepting a fixed dashboard. The screenshots in the README show a home screen, the food databases, full nutrition tracking and recipe creation, which is the shape of the product in four screens.

The project is hosted at foodyou.maksimowiczm.com, the licence is GPL-3.0, and the primary language is Kotlin with a Gradle build. The last push to the repository was on 2026-09-23, and the release history shows 3.4.9 from 2026-06-27 and 3.4.8 from 2026-04-25 alongside the 4.0.0-alpha.1 build.

Three food databases, and uneven coverage between countries

The food data comes from three public sources rather than from a proprietary catalogue: Open Food Facts, USDA FoodData Central and the Swiss Food Composition Database. The README advertises this as comprehensive food database integration, and for the regions those three cover it is the practical core of the app.

The limitation follows directly from the choice. These databases are national and project specific, so a user outside the United States, Switzerland and the wider Open Food Facts contributor network is likely to find thinner coverage for local dishes and packaged products. The README does not describe an ordering system, a barcode scanning flow, or a mechanism to add a food that is missing from the databases, so it is not possible to tell from the documentation how complete the experience is for a cuisine the databases do not cover well.

Nor does the README say anything about how the data is cached or refreshed. An offline-first app that pulls from three network sources has to have some answer for a missing connection, and that answer is not documented here.

For an evaluation, the honest test is empirical rather than textual: pick ten foods you actually eat, look them up in the app, and see which of the three sources answers. That check will tell you more about whether FoodYou works for you than any description of the feature list.

Nutrition tracking beyond calories and macros

The tracking model goes past the usual numbers. The README states that you can set and track personalised nutrition targets, and that it monitors not only calories and macros but also vitamins, minerals and other essential nutrients. That is the difference between a calorie counter and a nutrient tracker, and it is the part of the feature list that a user tracking a specific diet is most likely to care about.

Recipes are computed the same way. Recipe creation means combining foods into a custom recipe with the nutrition calculated instantly, so a dish you cook yourself becomes a reusable entry with its own numbers instead of a sum you do by hand each time. Combined with local storage, that means a recipe library that lives on the device and works without a network.

The adaptive theming is not only cosmetic. It means the interface takes its colours from the device wallpaper on Android versions that support it, and the modular home screen means the information you want on the front screen is a choice rather than a fixed layout. For a log you open several times a day, those details are what make the habit stick.

What the README does not give is a data export or backup story. With everything stored locally, losing the device means losing the diary unless there is a backup or export path, and the documentation quoted here does not mention one. That is a real risk to weigh for a tracker whose value grows with the length of its history.

Installing from F-Droid or GitHub releases, and checking the signature

The README gives two distribution routes, a F-Droid listing for com.maksimowiczm.foodyou and the GitHub releases page, and it publishes the SHA-256 hash of the signing certificate so that an installer can check what they are about to run.

cd74b0aedd8ead8184063a65909d639a8c885cf6465829690a9be83a8904bdea

The README adds that the same signature is valid for F-Droid, and gives the reason: reproducible builds. That is a meaningful detail for an app that asks for no account and stores everything locally, because it means the binary a user downloads from a package repository can be verified against the one the project publishes, rather than trusted on the strength of the download page.

The F-Droid route is the one to prefer for a privacy focused app, since it avoids a direct install from a website, and the presence of a stable release channel is useful given that the newest tagged build is an alpha.

There is no self hosted variant, no web client and no desktop build in the documentation. FoodYou is an Android application, and the project is distributed as an APK.

For anyone who wants to run it on something other than a phone, that limitation is decisive.

Building a signed APK with the justfile targets

The repository carries a justfile with the release and preview pipelines written out, which is the clearest description of how a build is produced. The release target cleans, assembles the release variant, aligns the APK and signs it with apksigner.

release:
    @./gradlew --no-daemon --no-build-cache clean
    @./gradlew --no-daemon --no-build-cache app:assembleRelease

The signing step names a keystore file and a key alias, and writes the signed output to a file called release-signed.apk.

    @apksigner sign \
      --alignment-preserved \
      --ks foodyou.keystore \
      --ks-key-alias foodyou \
      --out ./release-signed.apk \
      app/build/outputs/apk/release/aligned.apk

The preview target mirrors it against an assemblePreview variant, and a separate target formats Kotlin sources with ktfmt using the kotlinlang style, which it expects to find at the path given by the KTFMT_JAR environment variable.

format:
    @find . -type f \( -name "*.kt" -o -name "*.kts" \) -not -path "*/build/*" | xargs java -jar $KTFMT_JAR --kotlinlang-style

The build also has a Nix side to it, with flake.nix and flake.lock at the top level, and a docs target that serves the documentation with zensical. None of this is needed to install the app, but it shows the project is set up for reproducible local development, which is a decent signal for a small open source project that publishes a signing certificate hash.

No code contributions accepted, and how the work is funded

The most unusual line in the README is an important one for anyone considering contributing. The project states that code contributions are not currently accepted, and gives two reasons: licensing, and the fact that the app generates some income.

That is a deliberate governance choice rather than an accident of neglect. The alternative contribution routes are still open. Translations go through Crowdin, and the README says the maintainer will credit contributors who want it. Feature requests and bug reports are filed as GitHub issues.

The funding model follows from the same position. The app is free, open-source and ad-free, and the README says that sponsorship directly supports full-time development of the project. The sponsor links are a Ko-fi page plus Bitcoin, Ethereum and Monero addresses, which is an unusual amount of detail for a README and tells you the author treats direct payment as the main mechanism keeping the project alive.

For an evaluator, this cuts both ways. A single funded maintainer with a stated policy against outside patches means the code is stable in the sense of not being churned by strangers, but it also means a bug you find will not be fixed by a pull request from you. If you need to change behaviour, your options are to file an issue and wait, or to fork, and the licensing reason given for the policy deserves attention in that decision. The GPL-3.0 licence governs the fork route, and its terms are in the LICENSE file at the top of the repository.

Other open source trackers, and the gap in the comparison

The README lists four other open source apps under a heading for similar tools: OpenNutriTracker, Energize, FitBook and Waistline, each with a repository link. It does not compare them.

That omission is worth noting precisely because the comparison a buyer would want is the one the project does not make. A reader who wants an Android nutrition tracker has several options, and the questions that separate them are the same questions this review keeps returning to: is the data stored only on the device, does the app require an account, does it work offline, which food database does it query, and can you export your history. The README answers all of them for FoodYou and none of them for the other four, so the comparison has to be done by opening each project.

There is a broader alternative too, and it is the one most people actually use: a food database plus a spreadsheet or a notes app. That approach is entirely local, it costs nothing, and it has no account, but it gives up the target tracking, the nutrient breakdown, the recipe computation and the live totals that are the reason to use a tracker at all. FoodYou's argument is that you can have all of that without the account, and the way to test that argument is to install it and log a week of meals.

The credits section names ReadYou as the source of inspiration for parts of the app, and the icon set as another credit.

For a project with a named maintainer, a funding page and a four-app shortlist, the deciding factor for most people will be how well the three databases cover their own food, which is a question you can answer in a few minutes rather than a question this repository answers for you.

Editorial conclusion

FoodYou suits an Android user who wants a food diary that works offline, needs no account, and pulls from three public food databases, and who is willing to accept that the project takes no code contributions and that its database coverage is uneven across countries. It does not suit anyone who needs the 4.0 rewrite to be stable, since the newest release is 4.0.0-alpha.1, nor an iOS user, nor a team that intends to fork the app. Verify first which of the three food databases actually covers the foods you eat, then check the release channel you install from and the signing certificate hash before you trust an update.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. maksimowiczm/FoodYou on GitHub
3. Project website
4. README
5. Releases