A privacy checklist for calorie tracking apps

Find out what the app needs from you

A food diary can hold more than the meal you just entered. Before saving a long history, check which information the app collects and why. You should be able to recognise your own entries and choices in the explanation.

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.

Check optional features separately. A camera, connected service or social tool can need different information from a basic food log. If you don’t want to use it, find out whether you can leave it off and still do the logging you need.

Check where an offline meal goes after reconnecting

Being able to save a meal offline does not tell you whether it stays only on the phone. Look for an explanation of local storage and later synchronisation. You need both parts to understand where the record is held.

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?

Saving locally can let you record a meal with no signal while still synchronising it with an account later. Check whether that is how the app works. Don’t assume that offline entry means there is no service-side copy.

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.

Choose what to allow and how to change your mind

Before granting access, check which feature needs it and whether you can use the app without it. Find the control for withdrawing access later. A purpose such as taking a meal photo is more useful than a general promise to improve the experience.

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.

Find the matching controls in settings as well as the policy. Check whether you can tell what is on, what is off and what changing the choice does. If that is unclear, ask before granting access you do not understand.

• 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?

Keep a copy or close the account when you need to

Before you have months of food entries, find the export and account-deletion instructions. Check where to start, how account control is verified and when the request is expected to finish. That avoids having to work out the process at the point you want to leave.

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?

For connected services, check what happens to information already transferred if you disconnect them. Removing a connection may stop future transfers without removing every copy. Ask about missing details rather than assuming the account-deletion route handles another service too.

Keep track of the answers you can find

Open the current privacy notice, the store disclosure and the data-control instructions. For each question below, note whether the answer is clear, unclear or not relevant to the way you’ll use the app. Keep the page and date with your notes so you can check again if the product changes.

Focus on the unanswered questions that affect your planned use. If you want to save meal photos, find out how those images are handled. If you need to take the diary elsewhere later, settle what the export contains before relying on it.

Use the checklist to decide whether you have enough information for your own choice. It does not give every app a universal privacy ranking. Ask the service about any missing answer that would change whether you use it.

• 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.

Find the Haps answers in one place

Haps is available on iPhone through the App Store and on Android through Google Play. Its data and privacy page explains storage, synchronisation, optional analytics, export and deletion. Use it to check what happens to the record you plan to keep.

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.

The Haps data and privacy page links the practical controls and handling details, with the privacy policy as the full notice. Use support if a step or recipient is unclear. For personalised health or nutrition decisions, use an appropriately qualified professional rather than a calorie tracking app.

Common questions