Effective: [PLACEHOLDER: effective date] · ezecal for iOS and Android · Available in English, German, Spanish, French, Italian, Portuguese and Latvian.
You are using an app that knows what you eat and what you weigh. That is exactly the kind of data you should be suspicious about, so here is the shape of it before any of the detail.
ezecal has no server sync. Your meals, your photos and your body profile are written to a database on your phone and are not uploaded to us. We hold no copy and have no mechanism to fetch one. (An unused syncedAt column exists in the app's database schema, left over from a sync feature that was never built. Nothing writes to it.)
Kept on your phone, and not sent to us:
What does leave your phone:
Two honest qualifications to "it stays on your phone", both spelled out below rather than buried: the single photo or description you choose to send for analysis does leave (§3.1), and your on-device database and photos are not excluded from your own device backup — iCloud on iOS, Google backup on Android (§4.5).
There is no analytics SDK, no crash reporter, no tracking pixel, no data broker, no location and no contacts access. See §15.
| What it is | Stored where | Does it leave your phone? | Who else can see it |
|---|---|---|---|
| Meals: name, portion, calories, macros, micros, category, your description, the AI's explanation | Your phone | Only the description you send for analysis, when you send it | Anthropic, as our processor |
| Meal photos | Your phone | Only the single photo you send for analysis, at the moment you send it | Anthropic, as our processor |
| Body profile: sex, age, height, weight, body-fat %, activity, goal, pace, targets, BMR/TDEE, waking hours | Your phone | Not sent to us or to anyone | Nobody, subject to §4.5 |
| Apple Health readings (opt-in, iOS only) | Your phone | Not sent to us, to the AI, or to advertisers | Nobody, subject to §4.5 and the CSV export you run yourself |
| Preferences: language, appearance, reminders, estimation mode | Your phone | Your app language and estimation mode only, attached to an AI request | Anthropic |
| Anonymous account record | Your phone's secure storage, and our server | Yes | Us |
| Session record: token, expiry, IP address, user-agent | Our server | Yes | Us |
| Daily AI usage count | Our server | Yes | Us |
| Premium on/off | Our server | Yes | Us |
| Dictation audio | Handled by your device's OS | Possibly, to Apple (iOS) or Google (Android) | Apple or Google |
| Ad requests | Google AdMob SDK | Not in this build — see §3.5 | Google, once enabled |
Controller: [PLACEHOLDER: controller legal name] Postal address: [PLACEHOLDER: registered postal address] Company registration number: [PLACEHOLDER: company registration number, if any] Email: [PLACEHOLDER: contact email] Data protection officer: [PLACEHOLDER: DPO name and contact, or state that none is appointed and why] EU representative (Art 27): [PLACEHOLDER: Art 27 representative if the controller is not established in the EEA, or state "not applicable"]
The ezecal API runs at [PLACEHOLDER: hosting provider and region for the ezecal API]. Its database runs at [PLACEHOLDER: hosting provider and region for the MongoDB database].
Six of the seven languages ezecal ships in are EEA languages, so the GDPR is the regime this policy is written against, not an afterthought.
The app keeps all of the following in a database (expo-sqlite) and a folder inside its own sandboxed storage, plus a few items in your device's secure storage — the iOS keychain, or Android's Keystore-backed encrypted storage. None of it is uploaded to us.
Some of this is health data — special-category data under GDPR Art 9. You are entering it into your own device in order to use the app: the Art 9 basis is your explicit consent (Art 9(2)(a)), given by entering it, and the Art 6 basis is Art 6(1)(b), because holding it is how the app works at all.
Reminders are local. If you set one, your phone schedules a notification with itself. Nothing is sent to us, and there is no push server.
When: only when you take or pick a photo of a meal, or type or dictate a description, or ask the app to correct a meal it already analysed. Never in the background, never automatically.
What is sent to our API, and on to Anthropic:
-120, not a date and not a location. We use an offset rather than a date so your daily AI allowance resets at your midnight and cannot be reset by changing your clock;What is not sent: no name, no email address, no account identifier, no profile, no weight, no targets, no history, and nothing from Apple Health. The request carries the prompt content listed above and nothing else.
What we keep: nothing. Our server holds the photo and the text in memory long enough to pass them to Anthropic and hand you the answer back. It does not write them to a database or to a file. On success we log which model answered and the token counts, to watch what the feature costs. On failure we log the error's name and message only — deliberately, because the underlying error object contains the whole request, photo included. Neither log contains your photo or your text.
Who processes it: Anthropic PBC, in the United States, as our processor. Transfers are covered in §7.
Lawful basis: Art 6(1)(b), performance of a contract — you asked for an analysis, and sending the meal is how it is delivered. To the extent a photo or description reveals something about your health (a medical shake, a diet you follow for a condition), the additional basis is your explicit consent under Art 9(2)(a), given by the deliberate act of sending that particular meal. Nothing is sent without a tap.
The app creates an account for you silently, the first time it needs one. There is no sign-up screen and nothing is asked of you.
What that account record contains on our server: a random user identifier, a flag marking it anonymous, created and updated timestamps, the fixed name "Anonymous", and a generated placeholder email address of the form temp@<random>.com. That address is not yours, was never yours, and cannot receive mail. Unless you buy something, we never ask for or store a real email address.
If you buy analyses, you sign in with Apple at checkout and the anonymous account becomes a real one: your name and email address (a private relay address if you choose to hide yours) replace the placeholders, and everything already attached to the anonymous account — this month's usage count and any balance — moves across to it. The reason is in §3.6: a purchased balance has to belong to a person, or it dies with the handset. Nothing else about the app changes, and if you never buy, nothing here applies to you.
Session records are stored alongside it: a session token, an expiry, and — as our authentication library records by default — the IP address and user-agent string of the request that created the session. These are held in the same database as the account record.
Why the account exists: the AI runs on one API key that we pay for. Without an account per device there is no way to give you a fair daily allowance instead of a free-for-all we would have to shut off.
Apple and Google sign-in appear in the app's configuration, but their credentials are not set, so nobody can use them today. If we enable them, this policy will change first.
Lawful basis: Art 6(1)(b) for the account itself; Art 6(1)(f), our legitimate interest in keeping the service running and unabused, for the IP address and user-agent on the session record.
Our authentication endpoints apply request limits — currently 60 requests a minute, and 10 anonymous sign-ins an hour — using the client IP address read from the request headers. Those counters live in the running server's memory and are not written to a database. The IP address is, separately, written to the session record described in §3.2.
To be precise about scope: this limiter covers the authentication routes only. The meal-analysis route is not rate-limited in the same way; it is protected by the per-user daily AI allowance described in §3.4.
Lawful basis: Art 6(1)(f). Our interest is in preventing bulk account creation and abuse of a shared key; the impact on you is small and the alternative is a slower or absent service.
Two small records exist on our server, and they are the only ones tied to your use of the app:
{ user ID, day, count, created-at timestamp }. How many analyses you ran that day. Nothing about what you analysed. The timestamp is what the automatic 60-day deletion is measured from.{ user ID, whether Premium is active }. We read Premium from this record and never from the app, so a toggle on your phone cannot raise the AI allowance.There are no meals, no photos, no body data and no health data on our server — not in another collection, not in a backup.
Lawful basis: Art 6(1)(b) for both, supported by Art 6(1)(f) (cost control and abuse prevention) for the counter.
Not active in this build. ezecal is built to show one banner above the tab bar in the free version. While purchases are switched off, the app grants every user the client-side entitlements a subscriber would have, and the banner is therefore not rendered and no ad request is made. When purchases are enabled, ad serving begins for users without a subscription, and the rest of this section applies. The consent step below does already run today.
Consent. Before any ad code initialises, Google's User Messaging Platform (UMP) gathers your consent. Your choice is stored on your device by that SDK.
You can change your choice later at Profile → privacy options. That entry is shown only when the consent SDK reports that a privacy-options control is required for you — which is where the law requires it, and it means users outside that status will not see it in the app.
Where the banner never appears: the logging flow (camera → AI review) carries no ads, and a subscriber sees none anywhere.
What we never send to ads: we set no keywords, no content URL, and no mediation user fields. Nothing about your meals, your weight, your goals, your profile or your Apple Health data is placed in an ad request or used for targeting. This is verified in code, not merely promised. Once ads are served, an ad request will still tell Google your IP address, general device information and which app requested the ad; Google uses that to serve and cap the ad and to detect fraud, and acts as an independent controller for parts of it under its own privacy policy.
About App Tracking Transparency (iOS only). Nothing in the app's own code calls for App Tracking Transparency authorisation. However, the app does ship the required usage-description string, and Google's UMP can be configured in the AdMob console to present the ATT prompt alongside the consent message. So we cannot promise you will never see it: if you do, the answer you give there governs, and Apple's advertising identifier is available to the ad SDK only if you allow it. [PLACEHOLDER: confirm whether the AdMob console is configured to present an ATT message, and align this paragraph and the App Store privacy labels with that setting]
Lawful basis: Art 6(1)(a), consent, for personalised ads and for storing or reading information on your device; Art 6(1)(f), funding a free app, for serving a non-personalised ad where consent for personalisation was not given — and where local law requires consent for the device access an ad involves, that access does not happen without it. [PLACEHOLDER: confirm the AdMob account has accepted Google's EU user consent policy and the applicable Google controller/processor terms, and that a UMP message is configured for every EEA locale the app ships in]
Two things can be bought: a Premium subscription, and packs of AI analyses ("credits"). Both are handled by Apple's App Store, directly — there is no payment intermediary between you and Apple, and none between Apple and us. Payment details always go to Apple, never to us — we never see a card number, a billing address or any financial instrument.
What we hold: for each purchase, the product identifier, the store's transaction identifier, how many analyses it was worth, and when it happened; and, for a subscription, whether it is currently active, plus the identifier Apple gave the original purchase so we can ask Apple about a renewal. We also hold a random identifier that we attach to a purchase so Apple's notification about it can be matched to your account. That is what the server checks before allowing an analysis, and what lets a balance survive a reinstall. Our server asks Apple directly about a transaction; no third party holds a copy.
Signing in is required to buy, and only to buy. Using the app asks for nothing. But a consumed consumable does not exist in Apple's transaction history, so a balance you have paid for can only survive losing or replacing your phone if it belongs to you rather than to that installation. Sign in with Apple therefore happens at checkout, and gives us your name and an email address — a private relay address if you choose to hide yours. We use them for nothing except identifying the account that holds your purchases. See §3.2.
Lawful basis: Art 6(1)(b) — performing the contract you enter into when you buy.
(There is no purchase processor to name here any more: purchases go to Apple, an independent controller already listed in §6.)
You can speak a meal instead of typing it. The app uses your device's own speech recognition through your microphone — Apple's on iOS, Google's on Android — and does not force on-device recognition. Depending on your device, your language and your settings, that audio may therefore be transcribed on Apple's or Google's servers. That company's privacy policy governs what it does with the audio.
We never receive the audio. What the app receives is text, and it goes into the input box rather than being sent anywhere — so you can fix a misheard word before deciding whether to send it for analysis at all.
Lawful basis: Art 6(1)(b). You asked to dictate.
Optional, iOS-only, and off until you turn it on.
On Android there is no health integration in this version: the app contains a registered but unimplemented Health Connect module, no health feature or permission prompt is ever shown, and nothing is read or written. If a future Android release adds health support, it would use Google's Health Connect under the same rules as this section, and this policy would change first (§16).
Only after you connect it, and only what iOS lets through the permissions you grant:
Where this data came from (Art 14): dietary entries and body mass are read from your Apple Health store, where they were written by other apps or devices you use. We obtain nothing from those apps or their operators, and they learn nothing about you from us.
Meals you log in ezecal are written back to Apple Health, tagged as ours. That tag is how imports skip them, so nothing is double-counted. Delete a meal in ezecal and the samples it wrote for that meal are deleted from Apple Health too — Apple only lets an app delete its own samples, which is exactly what happens.
Health data is special-category data under Art 9, and processing it is prohibited unless an Art 9(2) exception applies. Here one does: Art 9(2)(a), your explicit consent, paired with Art 6(1)(a). None of the others fit and we will not pretend otherwise — we are not a health-care provider, there is no substantial public interest, no employment law is involved, and you have not made this data public.
The consent is explicit in the way Art 9 requires: you tap Connect in the app, iOS then asks you category by category what ezecal may read and write, and sleep is asked for separately again. It is specific, informed, a clear affirmative act, and reversible.
One qualification about scope: these readings are queried, calculated and stored on your phone. They do not reach a server we run. We name a lawful basis anyway, because our software is what does the reading.
Data read from Apple Health is not sent to our server, not sent to Anthropic, and not placed in any advertising request or ad SDK field. A path once existed by which a meal imported from Health could have reached an AI prompt; it was found and closed, and the app now refuses to turn a Health-sourced entry into an AI request at all.
Two places Health-derived rows do travel, both by your own action: the CSV export you run (§9), which includes them deliberately because it is your data and goes where you send it; and your iCloud device backup, described next.
Withdrawing consent: turn ezecal off in iOS Settings → Privacy & Security → Health → ezecal, or use Disconnect in the app's Profile tab. Either stops further reading from that moment. It does not remove entries already imported into your log; you delete those in the app like any other meal.
The app's database and its meal photo files are not currently excluded from your iPhone's iCloud backup. If you back up your device to iCloud, your food log, your photos and rows derived from Apple Health can be included in that backup.
On Android the analogue is Google's device backup. We have not verified that the app excludes itself from Android Auto Backup, so assume the same there: your food log and photos can be included in a Google backup under your Google account. (Health rows cannot be — there is no health integration on Android, §4.)
That backup is yours, under your Apple or Google account, governed by that company's terms; we have no access to it and no way to reach it. But it means "it never leaves your phone" is true of us and not literally true of your device. A fix to exclude these files is planned. Until this section says otherwise, assume it has not shipped. You can control device backups in iOS Settings → [your name] → iCloud, or on Android in Settings → Google → Backup.
| What we do | Data involved | Art 6 basis | Art 9 |
|---|---|---|---|
| Run the app on your device | Everything in §2 | 6(1)(b) contract | 9(2)(a) explicit consent for health data you enter |
| Analyse a meal you send | Photo or text, prior corrections in that session, language, UTC offset, estimation mode, your category names, current food list when correcting | 6(1)(b) contract | 9(2)(a) explicit consent, where the content reveals health data |
| Keep you signed in anonymously | Random user ID, placeholder email, fixed name, timestamps, session token, IP address, user-agent | 6(1)(b) contract; 6(1)(f) security for IP and user-agent | — |
| Limit request rates on the auth endpoints | IP address from request headers | 6(1)(f) preventing abuse | — |
| Meter your daily AI allowance | User ID, day, count, timestamp | 6(1)(b) contract; 6(1)(f) cost control | — |
| Know whether Premium is active | User ID, active flag | 6(1)(b) contract | — |
| Personalised ads (once ad serving is enabled) | Device and ad-request data held by Google | 6(1)(a) consent | — |
| Non-personalised ads (once enabled) | IP address, general device information, held by Google | 6(1)(f) funding a free app, subject to consent for device access | — |
| Read and write Apple Health (iOS) | Energy, body mass, dietary macros, optional sleep | 6(1)(a) consent | 9(2)(a) explicit consent |
| Transcribe dictation | Audio, handled by Apple (iOS) or Google (Android) | 6(1)(b) contract | — |
| Who | What they get | Their role |
|---|---|---|
| Anthropic PBC (US) | The photo or text of a meal you send for analysis, plus the context listed in §3.1. No account ID, no name, no email, no profile, nothing from Apple Health. | Our processor |
| Apple | Dictation audio on iOS, where your device transcribes on Apple's servers; App Store purchase processing once purchases go live, and the transaction records our server reads back from it | Independent controller |
| Dictation audio on Android, where your device transcribes on Google's servers; Google Play purchase processing once purchases go live. From AdMob/UMP: nothing today, because no ad is requested in this build — once ad serving is enabled, ad request data (IP address, general device information, ad interactions) | Independent controller for its advertising and platform services; processor for parts of ad serving | |
| [PLACEHOLDER: hosting provider and region for the ezecal API] | Runs our API; sees requests in transit and server error logs | Processor |
| [PLACEHOLDER: hosting provider and region for the MongoDB database] | Stores the account, session, allowance and subscription records | Processor |
We would disclose data to a public authority only where a valid legal obligation requires it. Given what we hold — an anonymous ID, a session record with an IP address, and a count of AI requests — there is very little to disclose.
Anthropic (United States). When you ask for a meal analysis, the photo or text is sent to Anthropic in the US. There is no adequacy decision covering US companies generally; the EU–US Data Privacy Framework covers only individually certified organisations. This transfer therefore needs a valid Chapter V mechanism, and that has to be a real contract, not a sentence in a policy.
[PLACEHOLDER: transfer mechanism relied on for Anthropic — confirm the signed DPA, whether it incorporates the EU Standard Contractual Clauses, and/or whether Anthropic is certified under the EU–US Data Privacy Framework. State the mechanism actually relied on and the date the agreement was entered into.]
We will not describe this transfer as "safeguarded" until that line is filled in by a human who has checked. What we can tell you already, because it is in the code: the request carries no name, no email, no account identifier, and nothing from your profile or Apple Health. It is a picture or a sentence about food, plus the small amount of context in §3.1.
Apple and Google (platform services). Dictation transcribed on Apple's or Google's servers, and App Store or Google Play purchases, are handled under those companies' own terms and transfer mechanisms.
Google (advertising). Once ad serving is enabled, ad requests reach Google infrastructure including servers outside the EEA, under Google's own published transfer mechanisms.
Our hosting. [PLACEHOLDER: hosting region(s) and, if outside the EEA, the transfer mechanism relied on for the API host and the database host]
You can ask us for a copy of the relevant safeguards at [PLACEHOLDER: contact email].
| What | Where | For how long |
|---|---|---|
| Meals, photos, saved meals, categories, profile, preferences | Your phone | Until you delete them, delete your account in the app, or delete the app. We have no say in it. |
| Anonymous account record | Our database | Until you delete the account |
| Session record (token, expiry, IP address, user-agent) | Our database | Until you delete the account. An expired session stops being valid, but the row is not swept automatically — deletion of the account is what removes it. |
| Daily AI count | Our database | Deleted automatically 60 days after the record was created, by a database expiry rule; sooner if you delete your account |
| Subscription record | Our database | Until you delete the account |
| The photo or text you sent for analysis | Not stored by us | Not stored by us at all. Anthropic's retention: [PLACEHOLDER: Anthropic's retention and use terms for API inputs and outputs under the contract in force, including whether zero data retention applies] |
| Server logs (model tier, token counts, error name and message — never your content) | Our hosting provider | [PLACEHOLDER: retention period for server logs at the hosting provider] |
| Your ad consent choice | Your phone, stored by Google's consent SDK | Until you change it or delete the app |
You have the rights below. Exercising them costs nothing, and we answer within one month (extendable by two further months for complex requests, with notice).
Access (Art 15). Almost everything is already in your hands — open the app and it is there. For a machine-readable copy of your log, use the CSV export in the Profile tab. What we hold on the server is: your anonymous user ID, a placeholder email of the form temp@<random>.com, the name "Anonymous", timestamps, session records (token, expiry, IP address, user-agent), your daily AI counts, and whether Premium is active. Ask us at [PLACEHOLDER: contact email] — but read the limitation at the end of this section first.
Rectification (Art 16). Every number the AI produces is editable: tap a meal and change the name, the portion, the calories, the macros, the category. Your profile is editable the same way. On our server, the one thing that could be inaccurate about you is the IP address and user-agent on a session record — a forwarded-header IP is taken at face value unless we have configured trusted proxies — and we will correct or delete a session record on request where we can identify it.
Erasure (Art 17). Profile → delete account. This deletes your account, its session records, your daily AI counts and your subscription record from our server, and then erases the app's local database and photo files on your phone. Deleting the app removes local data too. You can also delete any single meal at any time, which also removes the samples ezecal wrote for it in Apple Health. Note one limit: a few small items in the device's secure storage (language, appearance, estimation mode, the Health-connected flag, the session cookie) are not cleared by the in-app erase, and on iOS may survive an uninstall. They contain no meal, body or health data.
Restriction (Art 18). Stop sending meals for analysis, disconnect Apple Health, or withdraw ad consent, and the corresponding processing stops. Ask us and we will freeze the server records instead of deleting them, if that is what you want.
Portability (Art 20). The CSV export writes out every meal you have logged — day, time, name, portion, calories, macros and micros, category, the individual items, the source, and the AI's note. It includes rows imported from Apple Health, deliberately: it is your data. It goes wherever you choose through your device's share sheet, and we do not see it. Today this export is available to every user, subscriber or not.
Objection (Art 21). Where we rely on legitimate interests — rate limiting, and non-personalised ads once ad serving is enabled — you can object at [PLACEHOLDER: contact email].
Withdrawing consent (Art 7(3)). Ad consent: Profile → privacy options, where that control is shown to you (§3.5). Apple Health (iOS): iOS Settings → Privacy & Security → Health → ezecal, or Disconnect in the app. Camera, photo library and microphone: iOS Settings → ezecal, or Android Settings → Apps → ezecal → Permissions. Withdrawal takes effect from the moment you do it and does not undo what was lawful before.
Complaints (Art 77). You can complain to the data protection authority in the EU country where you live or work, or where you think something went wrong. Our lead supervisory authority, if one is applicable: [PLACEHOLDER: lead supervisory authority, or state "not applicable"]. You do not have to contact us first, though we would rather you did.
Your account is anonymous by design: no email, no name, no password, nothing that ties it to you. Under Art 11(2), where a controller genuinely cannot identify the data subject, the access, rectification, erasure, restriction and portability rights may not be exercisable through us on a request alone — we cannot hand a stranger a session record because someone emailed us.
We treat that as a reason to build the tools into the app, not as an excuse. Export, correction and deletion all work from inside the app, on the device that holds the account, without you proving anything to us. If you need to exercise a right over the server records specifically, write to us and we will explain what is possible from the device you still have.
No statute requires any of it. In practice:
The AI estimates what is in your food. That is the whole of it.
There is no automated decision producing a legal effect or anything similarly significant for you within the meaning of Art 22. Nothing here decides about credit, insurance, employment or access to a service. We do not profile you for advertising ourselves, and we send nothing about your food or your body to anyone who does.
The estimate is an estimate and can be wrong. Every number is editable, you can ask it to correct itself in your own words, and the app shows you in plain language why it arrived at a figure — so you can judge it rather than trust it.
ezecal asks for your age on the device, to calculate your energy needs. That number never leaves your phone.
The app performs no age verification — we are telling you that rather than implying a gate exists. ezecal is not designed for or directed at children, and is not intended for anyone under [PLACEHOLDER: minimum age — set from the App Store and Google Play age ratings and the applicable national age of digital consent, which ranges from 13 to 16 across the EEA].
We could not identify a child's account if we tried, since we collect no name, no age and no email on the server. If you believe a child has been using the app, deleting the app removes everything held on the device; write to [PLACEHOLDER: contact email] and we will help with the account.
The ad SDK is configured for a general audience, with no age-restricted treatment asserted. [PLACEHOLDER: decide whether AdMob's under-age-of-consent / child-directed tagging should be set, and align this paragraph with that decision]
We do not sell personal information and we do not receive money for sharing it. No ads are served in the current build. If ad serving is enabled and you consent to personalised ads, that consent enables what some US state laws call sharing for cross-context behavioural advertising; declining, or withdrawing later, stops it, using the same control described in §3.5. We offer no financial incentives for data and do not discriminate against anyone who says no.
https:// URL; nothing in the app enforces the scheme, and the development fallback is plain http on a local network. [PLACEHOLDER: confirm the published EXPO_PUBLIC_API_URL is https and that the host redirects/enforces TLS]No system is perfect. If you find a problem, please tell us at [PLACEHOLDER: contact email] before telling anyone else, and we will fix it and say what happened.
Stated plainly, because absence is hard to prove by silence:
If what the app does changes, this policy changes first or at the same time — not months later. The date at the top is the version you are reading. For material changes (a new recipient, a new category of data leaving your device, a new purpose) we will tell you in the app rather than quietly editing the page.
[PLACEHOLDER: controller legal name] [PLACEHOLDER: registered postal address] [PLACEHOLDER: contact email]
Ask us anything about this policy, or about the data behind any number the app has shown you.
This document is provided for information. Have a qualified lawyer review it against your circumstances before you publish it.