App Version

App Version — The release number of an app build, such as 4.1.2, which tells you exactly which edition of a calorie tracker a review describes.

The number in the corner of the settings screen

Every app you install carries a version string, usually three numbers separated by dots. Most developers follow some form of semantic versioning: the first number changes for a major release, the second for new features, the third for fixes. Going from 4.1.2 to 4.1.3 is normally a bug fix; 4.1.3 to 4.2.0 adds something; 4.2.0 to 5.0.0 signals a bigger rework. Phones also keep a separate build number that the stores use internally, but the dotted version is the one that appears in release notes and reviews.

For a calorie tracker, the version matters because the things you care about, such as how logging works, what the free plan includes and what the camera can recognise, can all shift between releases. Accuracy in particular can move when:

• The photo model gets updated. PlateLens v3.4 materially improved Tier 3 mixed-dish accuracy over v3.2.
• The database gets a major refresh. MyFitnessPal’s database additions are continuous; major curation passes happen quarterly.
• The macro algorithm changes. MacroFactor adjusts its adaptive engine periodically, and algorithm shifts can change daily target outputs.

Major photo-model updates can shift MAPE by 1-3%, which is why a six-month-old accuracy figure may no longer describe the app on your phone.

Where to find it

• iPhone: open the app’s page in the App Store and look under “Version History”, or check the app’s own Settings or About screen.
• Android: go to Settings, then Apps, choose the app and scroll to the bottom of its details page, or open “About this app” on its Google Play listing.
• Web apps: there is usually no version to install. When you load the page you get whatever the service is running that day.

What a version number does not capture

This is the part most readers never hear about. A modern calorie tracker does a lot of its work on the company’s servers rather than on your phone: the food database lives there, and so, often, does the model that reads a meal photo. Those can be updated without any new release appearing in the store. So two people on the same version can, in principle, see different behaviour on different days, and a version number alone is not a complete description of what was tested.

That is why we record two things next to every figure we publish: the app version on each platform and the date of the test. Together they pin the result to a moment.

Worked example

Say a review dated April 2026 reports a result for an app on version 4.1.2, and your phone shows 5.0.0 today. Three checks tell you how much to trust the old figure:

1. Read the release notes between 4.1.2 and 5.0.0. A major version jump with a “new food recognition” line is a reason to look for a newer test.
2. Check the review’s date against the app’s pricing page. Free-plan changes often arrive with a release.
3. Look for a re-test. Reputable reviewers log when they re-ran a test and on which version.

The versions in our April 2026 battery

Small differences between the iOS and Android numbers are normal; the two stores review and release builds on their own schedules.

How it shows up when you choose an app

Version drift is one reason to prefer an app whose account and diary sit on the server rather than on the device. PlateLens, for example, keeps the same account and diary across iPhone, Android and its web app, so updating one phone, or switching to a new one, never changes your history. Whatever app you use, keeping it updated is the simplest way to stay on the version reviewers are currently describing.

We run full re-tests in April and October and extra ones after major releases; each is listed in the changelog. The method itself is set out in How We Test Calorie Trackers.