A privacy checklist for calorie tracking apps

Start with the data, not the privacy adjective

Nobody opens a calorie tracking app because the privacy policy looked like a lively read. Yet the useful question arrives before the first food does: what will this app know after a month that it does not know today?

The direct answer is to make a small data map before choosing. List the account details, food names, calorie values, dates, targets, photos, body measurements, device identifiers, and usage events the app may handle. Then ask which items are required for the core log, which are optional, where each item is stored, who receives it, and how long it remains.

Do not treat every item as interchangeable. An email address supports an account; a food history builds a dated record of behaviour; a device identifier can connect events over time. A policy should explain these categories and their purposes in language specific enough that you can recognise the data you will actually enter.

This is also where feature appetite meets privacy scope. Search, scanning, connected services, coaching, social tools, and personalisation can each require different inputs or recipients. If you do not need a feature, check whether you can leave its data path unused rather than granting everything during setup.

Check where entries live and what offline really means

“Offline”, “local-first”, and “device-only” are not synonyms. Offline can mean the screen remains visible without a connection, or it can mean a new entry is saved safely and queued for later synchronisation.

Local-first usually means the device accepts the change first, but the record may still be sent to a service later. Device-only means something narrower and should not be assumed from either of the other labels.

Ask the app to explain a simple sequence: you save lunch with no signal, close the app, reopen it, and reconnect tomorrow. Where is the entry during each step? Does it survive an app restart?

Is its pending state visible? When it synchronises, is the local copy encrypted, and does an account-linked server copy then exist?

The consequence matters more than the architecture slogan. A durable local queue can protect a new entry from a patchy connection while still allowing account synchronisation across the service. That can be a useful tradeoff, but it is not a promise that data never leaves the phone.

Look for an equally clear answer about cached information after sign-out, account deletion, or removing the app. Deleting an icon, clearing a local database, and deleting an account are three different actions. A trustworthy explanation keeps them separate.

Treat permissions and analytics as separate decisions

A long permissions screen is not a substitute for a purpose. For every request, ask what feature it enables, whether the feature works without it, whether access is limited to the necessary data, and how to withdraw the permission later. “To improve your experience” is fog, not an answer.

Phone permissions and in-app consent controls also do different jobs. A camera permission allows camera use; it does not by itself explain whether an image is processed locally, uploaded, retained, reviewed, or reused. Access to a connected health source does not explain which record types are read or whether imported information changes anything elsewhere in the app.

Analytics deserves its own row on the checklist. Find out whether it starts before consent, which events and properties are allowed, whether food names or calorie values can enter those events, which provider receives them, and what happens after consent is withdrawn. Crash reporting, product analytics, advertising measurement, and personalised advertising are different purposes even when several arrive through software bundled into the same app.

Check the settings as well as the policy. A concrete control should have a clear state, and changing it should have an observable effect. Privacy theatre loves a handsome toggle whose consequences remain a mystery.

• Purpose: what exact feature or operational need uses the permission or event?
• Choice: is it required for the ledger, optional for another feature, or enabled by default?
• Scope: which data fields can be accessed or transmitted?
• Recipient: does the app operator handle it alone, or does another service receive it?
• Exit: where can you withdraw access, and what happens to data already collected?

Test export and deletion before you need either

Export and deletion are where a privacy promise becomes a real process. Check them before building a long food history, not on the afternoon you decide to leave. The app or its public support material should tell you where to start, how identity is verified, what the export contains, how it is delivered, and how long the process is expected to take.

For export, look beyond the presence of a button. Ask whether the file includes the dated entries and account information that matter to you, uses a format you can inspect, and arrives through a protected link or another controlled method. Also ask what is deliberately excluded and whether generated links expire.

For deletion, distinguish immediate loss of access from final removal. Some services provide a recovery period before purging live data, and backups may follow a separate expiry schedule. That is not automatically good or bad; the useful test is whether the stages, timing, reauthentication requirements, and effect on active sessions are stated plainly.

Run a paper test even if you do not create an account. Can you find the route from the public site? Is there a contact for a failed request?

Does the service explain whether removing a connected source also removes previously imported records? If the answer is hidden behind “contact us” with no process, record that as an unknown rather than filling the gap with optimism.

Use this ten-minute calorie app privacy check

Open the current privacy notice, the app-store disclosure when a verified listing exists, and the data controls described by the service. Give each item below one of three marks: clear, unclear, or not applicable. “Unclear” is a result, not homework you failed to complete.

After ten minutes, compare the unclear marks with how sensitive and long-lived the missing answer is. A vague note about an optional theme is not equal to a vague note about meal photos, food history, analytics identifiers, or account deletion.

This checklist does not produce a universal winner. It gives you a repeatable way to judge whether an app provides enough evidence for the data you plan to entrust to it. That is a more useful conclusion than a shiny privacy badge and considerably easier to revisit when the product changes.

• Data inventory: the service names the account, ledger, target, device, photo, and optional connected data it handles.
• Purpose and recipients: each important category has a stated use and identifies relevant service providers or recipient types.
• Storage model: local saving, server synchronisation, encryption, and offline limitations are explained without calling local-first data device-only.
• Consent: optional analytics and optional feature processing have separate, understandable controls.
• Permissions: camera or connected-data access is requested for a named feature and can be withdrawn.
• Export: the request path, identity check, contents, format, delivery method, and link lifetime are documented.
• Deletion: deactivation, recovery, live-data purge, backup expiry, and connected-data effects are distinguished where relevant.
• Account exit: signing out, deleting the app, and deleting the account are not presented as the same action.
• Contact and review date: there is a reachable privacy contact and enough version information to tell when the notice changed.

Where Haps fits this checklist

Haps is preparing for its first public release on iPhone and Android. It is a manual-first calorie ledger built around entering calorie values, reusing a recent food, and reviewing calories logged, remaining, or over target. It is not currently available for public installation.

Core entries save first to encrypted local storage. A durable offline queue keeps pending changes through connection failures and synchronises them with the Haps service later. This is local-first behaviour, not a device-only claim.

Product analytics are optional, remain off until consent, and use an allowlist that excludes calorie-ledger details, identity, dates, targets, routes, and free text. Haps does not claim that it collects nothing, because account synchronisation, privacy operations, and the core service require data handling.

The verified export process uses an identity check and delivers CSV files through a one-use link that expires after 72 hours. The internal handling target is 25 days. Account deletion revokes access immediately, allows recovery through reauthentication for 30 days, purges live data after that window, and lets encrypted backups expire within a further 30 days.

Those facts describe the current source truth, not a privacy score or a promise of zero risk. The Haps data and privacy page is the useful next step if this checklist matches your decision: it puts the product-specific storage, consent, export, and deletion evidence in one place. For personalised health or nutrition decisions, use an appropriately qualified professional rather than a calorie tracking app.

Common questions