Privacy Policy

Effective April 25, 2026 · Last updated September 14, 2026 · v2.6

FitGlass is an iOS calorie and macronutrient tracking app built and operated by Nisarg Chaudhary as an independent developer. This page explains, in plain English, what data FitGlass collects, where it goes, who can see it, and how you remove it. If something here is unclear or inaccurate, email privacy@fitglass.app and it will be corrected.

The short version. FitGlass stores your account, profile, food log, and water log in Firebase under your own user ID. Food descriptions and photos you send to the AI logger are passed through to Google’s Gemini models on Google Cloud Vertex AI for analysis; Google’s cloud terms say it does not use them to train models and does not keep them beyond producing the answer. If you log a meal by speaking, your device turns your speech into text by itself — the audio never leaves your iPhone and we never receive it — and only the text is sent, exactly as if you had typed it. If you scan a barcode, your phone reads the number off the label itself and sends only that number to Jar, our own food database — no image of the product leaves your device. When you search for a food, a copy of Jar inside the app answers first, and only what you type is sent on to look up branded products. Your Apple Health data stays on your device. We don’t sell your data, don’t track you across apps or websites, and don’t run advertising. FitGlass can email you about the app, but only if you switch that on yourself: the list holds your address and your first name, never anything about your health. You can export or delete everything from inside the app at any time.

Washington and Nevada residents: FitGlass also maintains a separate Consumer Health Data Privacy Policy as required by those states’ health-data laws.

Who we are

FitGlass is developed and operated by Nisarg Chaudhary, an individual independent developer. For the purposes of data-protection law (including the GDPR), Nisarg Chaudhary is the data controller for the personal data described in this policy. Contact: privacy@fitglass.app.

Information we collect

Account information

You can sign in three ways. What we receive depends on the method:

• Sign in with Apple / Google. Your email address, your name (Apple provides it only on first sign-in; Google on every sign-in), and an opaque provider identifier that lets you sign back in. FitGlass never sees your Apple ID or Google account password.
• Email and password. Your email address, a display name you choose, and a password. The password is transmitted directly to Firebase Authentication and stored by Google in hashed form — our servers and the app never store your plain-text password. Password resets are handled by a Firebase-generated email link.

Firebase Authentication also logs IP addresses and user-agent strings for security purposes and keeps them for a few weeks (see Firebase’s privacy documentation).

Profile and goal information

During onboarding you provide (some fields optional):

• Sex, age, weight, height, and activity level
• Your motivation (e.g., lose fat, build muscle, eat mindfully, maintain) and, where applicable, a target weight and pace
• Dietary preferences (e.g., vegetarian, vegan) and a typical meal schedule, if you choose to set them
• Daily calorie, protein, carbohydrate, fat, and fiber targets — calculated from the above using the Mifflin–St Jeor equation, or set manually
• A daily water goal — calculated from your weight and activity level, or set manually
• Display preferences: which macro bars appear on your dashboard, your chosen dashboard theme, and your preferred units (kilograms or pounds, centimetres or feet/inches, millilitres or fluid ounces)

Your appearance choice (light, dark, or follow-system) is stored on your device only and never reaches our servers.

This information is used solely to compute your daily targets and render your dashboard. It is never sold or shared for marketing.

Food and nutrition data

Every food you log is stored as a structured record:

• Food name (free text, AI-identified, or matched from Jar)
• Macros (calories, protein, carbohydrates, fat, fiber) and — for AI- and database-logged foods — label-set micronutrients (sugar, saturated fat, sodium, cholesterol, potassium, calcium, iron, vitamins A/C/D)
• Meal type (breakfast / lunch / dinner / snack), serving details, and timestamp
• The logging path (manual, Jar search, barcode scan, quick-add, or AI chat)

Our backend also maintains derived daily and monthly nutrition totals (aggregates of the entries above) to power charts efficiently. These are projections of your food log, not additional data.

Water logs

If you use the hydration tracker, each drink you log is stored as a small, separate record containing only:

• The amount, in millilitres
• The timestamp, and the calendar day it counts toward
• How it was logged (a quick-add preset or a custom amount)

Nothing else — no name, note, or free text. Your daily total and your hydration streak are recalculated from these records whenever they are shown; neither is stored as its own value. Water logs are never sent to Google’s AI and are not included in AI prompts.

AI conversation content

When you use the AI food-logging chat (text, photo, or both):

• The text you type and any photo you attach (resized and compressed on your device first) are sent to our backend — a Firebase Cloud Function — which forwards them to Google’s Gemini models on Google Cloud Vertex AI.
• Each request also includes context so the AI can respond sensibly: your daily targets, a compact summary of up to 12 of today’s logged entries (name, meal type, calories), and up to 8 of your frequently repeated meals from the past 14 days, with how often you logged each (so “my usual breakfast” resolves to your actual foods). This context is recomputed from your food log on each request — nothing extra is stored to support it.
• If you ask the AI to plan a meal, the request also includes your five computed daily targets (calories, protein, fat minimum, carbohydrates remaining, fiber) and your dietary constraint tags — the ones you set during onboarding, from a fixed list: vegetarian, vegan, pescatarian, halal, kosher, gluten-free, dairy-free, nut allergy. Some of these say something about your religion or your health, so we treat them as sensitive; see “Users in the EEA, UK, and Switzerland” below. Your name, email, age, weight, and height are not included — only the targets computed from them.
• If you ask the AI about your history (“how did last month go?”), the request also includes nutrition totals: the last 7 days and the last 3 calendar months, each as calories, protein, carbohydrates, fat, fiber, an entry count, and — where your entries carried them — micronutrient totals. These are sums only. They carry no food names, no meal types, and no times of day.
• If you ask the AI to change something you already logged (“make the rice a cup”, “drop the toast”), the request also includes today’s saved entries — up to 25 of them, each with its food name, meal type, calories, protein, carbohydrates and fat, and the internal record ID the app uses to find that row again. The record IDs are the reason this is listed separately: they are random strings that identify entries inside your own account, they mean nothing outside it, and they are not your user ID, your email, or your name. Without them the AI cannot tell two eggs entries apart. Nothing in this block is sent unless your message asks to change or remove something.
• The AI returns structured food suggestions which the app shows you before anything is logged. You always confirm the food cards before they become entries. When the AI proposes a change to an entry you already saved, the app applies it and shows you what changed, with an undo — the change is reversible, not silent.
• When you save foods from an AI proposal, we keep a small correction record: what the AI proposed versus what you actually saved (food names, calories, meal type). We use these records to measure and improve the AI’s accuracy. They are stored under your account and deleted with it.

Barcode scans and food search

Jar is FitGlass’s own food database. Every row in it comes from the US Department of Agriculture’s public FoodData Central releases — about 1.88 million foods, most of them packaged products carrying a barcode. Jar is reference data, not user data: nothing you log is ever added to it.

Jar exists in two copies. A trimmed copy of the generic foods ships inside the app, so search works instantly and offline. The full copy runs as a service of ours on Google Cloud, and that is the one a barcode scan or a branded-food search reaches.

Scanning a barcode

What leaves your device is the number, not a picture:

• Your phone reads the barcode itself. The camera preview runs on your device, iOS decodes the bars into a number (a GTIN — the digits printed under the barcode), and only that number is sent. No frame, photo, or video of the product is uploaded. If you take a photo instead of scanning, that is the AI chat path described above, and it is your deliberate action either way.
• Where the number goes. To Jar — our own service, running on Google Cloud. It is not an outside company’s database, and the lookup reaches no third party. The request carries your sign-in token so that only FitGlass users can query it.
• What the catalogue records. Its logs hold the barcode number, the matched food’s ID, and how long the lookup took. They do not hold your user ID, and they never hold food names.
• Barcodes we cannot match. If a product is not in the catalogue, we store the number and a count of how many times it has been asked for, so we know which foods to add next. That record holds the number and the count only — no account is attached to it, so it cannot be traced back to you.

A food you log from a scan becomes an ordinary food entry, exactly like one you typed, and everything above about food entries applies to it.

Searching for a food

Search is answered on your device first. The copy of Jar inside the app replies to every keystroke, with no network request at all, and it keeps working with no connection.

The words you type reach our server only under three conditions, and all three must hold: you have typed at least two characters, you have paused for a quarter of a second, and the app has not already answered that exact search from memory. Then the text goes to Jar to find branded products the bundled copy does not carry. Specifically:

• What is sent. The words you typed, and your sign-in token. Nothing else — not your profile, not your log, not what you searched for before.
• What we record. Our own logs keep counts and timings only: how many words your search had, how many results each half of the database returned, and how long it took. They do not record the words.
• One thing we should be exact about. Your search text travels inside the web address of the request, and Google Cloud writes its own request log for our service that includes the full address. So the words can appear in Google’s platform logs for our project, which we can read and which expire on Google’s default schedule of 30 days. Our application logs are the ones we designed to exclude the text; the platform log underneath is not ours to shape. It carries the words, the time, your IP address, and your browser type, not your name or your account.
• Where it does not go. Search text is never sent to Google’s Gemini models, never stored against your account, and never used to build a profile of you. A search you never log leaves nothing behind on your record.

Voice input (transcribed speech)

If you log a meal by speaking, what we collect is the text your speech becomes — never the audio:

• The transcribed text. Your device converts your speech to text on the device itself, and that text is then handled exactly like a message you typed into the AI chat. It is covered by “AI conversation content” above.
• Anonymous voice usage counters. Analytics events recording that a capture happened, which screen it started from, roughly how long it lasted, whether you tapped or held the button, and whether it succeeded. They carry no audio and no transcribed text.

We do not collect the audio itself. It is never uploaded, never stored, and never reaches our servers or Google’s AI. See “Voice input (microphone)” below for the full description.

Feedback you send us

If you use Profile → Send Feedback, the app pre-fills an email containing the app version and build number, your device model and iOS version, your Firebase user ID, and the IDs (not names) of your last three logged entries — so we can correlate your report with server logs. The body contains no food names, nutrition data, or chat content, and you can edit it before sending. Feedback goes to a Gmail inbox operated by the developer.

Operational metadata

To run the service safely, the backend records:

• A daily counter of your AI requests (rate limiting — currently 20 per UTC day).
• Daily AI token-usage totals per account (cost monitoring, not a user-facing feature).
• A short-lived record of each AI response (kept for about 10 minutes) so that if your app retries a request — for example after a network drop — you get the same answer back instead of being charged a second request. These records expire automatically.
• Structured server logs containing your user ID, latency, and event names. These logs do not include your food names, photos, or message contents.
• A device-integrity check. On launch, the app asks Apple to vouch that it is a genuine, unmodified copy of FitGlass on a real device, using Apple’s App Attest. Your device makes a key, Apple signs a statement about it, and our backend checks that statement with Google. This exists to stop a forged copy of the app from running up our AI bill. It carries no personal data, no account information, and nothing about you — it says something about the app and the device, not about the person holding it.
• A daily cost table. Once a day a job adds a single row to a Google BigQuery table recording that day’s total AI token counts, the total cost, and how many accounts used the AI. It is one row per day for the whole service. It holds no user IDs and no content — there is nothing in it that describes any individual.

What we do not collect

• Your location (no location services usage)
• Your contacts
• Your advertising identifier (IDFA) — we never request tracking permission
• Your browsing history, or any cross-app / cross-website activity
• Audio recordings — speech you dictate is transcribed on your device and the audio is discarded when the capture ends, so our app privacy manifest declares no audio data type at all

How we use your information

We use the data described above only to:

1. Authenticate you and route you to your own data.
2. Compute your nutrition targets and render your dashboard, weekly chart, and Home Screen widget.
3. Resolve your AI chat messages — typed or spoken — into food suggestions you can review and log.
4. Answer the three other things you can ask the AI for: a meal plan that fits your targets and dietary constraints, a summary of what you have logged over the past days and months, and a change to an entry you already saved.
5. Measure and improve the AI logger’s accuracy using correction records (proposed vs. saved).
6. Enforce daily rate limits and monitor operating costs so the service cannot be abused.
7. Look up a food in Jar — from a barcode you scan, or from words you type into search.
8. Run the Siri and Shortcuts actions you invoke, and show reminders your device schedules.
9. Confirm that requests come from a genuine copy of the app, and track what the service costs to run.
10. Diagnose crashes and operational errors.
11. Respond to feedback and honor your requests to export or delete your data.
12. Send you marketing email about FitGlass — only if you switch it on. See “Marketing emails” below.

We do not use your data for advertising, marketing profiling, or sale, and we do not use it to train AI models — neither ours (we have none) nor Google’s (see “AI logging” below). Marketing email is the one item on that list that is not about running the app for you. It is off until you switch it on, it holds nothing about your health, and “Marketing emails” below states the rule and why it is absolute.

How we share your information

FitGlass shares your data only with the service providers (processors) required to run the app, and only to the extent each needs to perform its function:

Jar — the food catalogue behind barcode scanning and search — is our own service, not a third party. It runs on Google Cloud, so Google hosts it in the same way it hosts everything else here, and the table’s Firebase row covers it.

Four of those six rows are Google. That is worth saying plainly: apart from Sign in with Apple and the marketing list, one company processes everything FitGlass handles — your account, your food log, the AI analysis, and the feedback inbox. Before August 15, 2026 the AI analysis sat with a separate company, which meant no single processor saw both your identity and your chat content. That separation is gone. What has not changed is that we still send no identifier with an AI request (see “AI logging (Google Gemini)” below), and Google acts as our processor under the terms linked above — it is not free to use your data for its own purposes. Google publishes the sub-processors it uses in turn at cloud.google.com/terms/subprocessors.

Resend is the sixth row and the only one that is neither Google nor Apple. It receives an address, a first name, and the emails we send, and only for people who switched marketing email on. It never receives your food log, your profile, your Apple Health data, or your Firebase user ID — see “Marketing emails” below, where that promise is stated in full. Resend publishes its own sub-processors at resend.com/legal/subprocessors.

We do not sell your personal information, and we do not share it with advertisers, data brokers, or marketing networks. We have no affiliates or subsidiaries.

If we are ever legally compelled to disclose your data (subpoena, court order, regulatory requirement), we will comply only as required by law and notify you where lawfully permitted.

Data storage and security

Where your data lives

• Account, profile, food entries, water logs, derived totals, correction records, operational metadata: Google Cloud Firestore, nam5 multi-region (United States). Stored under your unique user ID.
• AI conversation transcripts: not persisted on our servers. The transcript is held in memory on your device and discarded when you close the AI chat. Our backend briefly retains the structured response to each request (~10 minutes, for retry protection). Google does not store the request beyond producing the answer, with two exceptions — a 24-hour in-memory cache and, if its automated safety classifiers flag a request, abuse-monitoring logs. See “AI logging (Google Gemini)” below.
• The region your AI requests are processed in: unknown to us, by design. We call Vertex AI’s global endpoint, which Google documents as routing to whichever region is fastest rather than to a fixed one. See “International transfers” below.
• Voice audio: nowhere. Audio captured while you speak exists only in memory on your device, for as long as that capture is running, and is discarded when it ends. It is never written to a file, never uploaded, and never sent to Google. The text it produces is handled like any other AI chat message (above).
• A local copy of your food log: a SQLite database inside the app’s App Group container on your device, mirroring the food entries described above (including food names) so the app stays fast and works without a connection. It is a disposable copy — never uploaded anywhere, never sent to Google, and rebuilt from Firestore when needed. It is erased when you sign out or delete your account, so a different person signing in on the same device can never see your food data.
• Apple Health data: on your device only. See “Apple Health (HealthKit)” below.
• Widget data, appearance choice, reminder settings, and reminder engagement counters: on your device only, in an App Group container shared between the app and the Home Screen widget. Meal and water reminders are local notifications; their schedule never leaves your device. See “Reminders and notifications” below for what the app learns from them.
• Jar, the food database: the copy inside the app is read-only public reference data — not user data — and involves no network requests. The full copy is a Google Cloud SQL Postgres database in the United States. Neither copy holds anything about you.
• Your marketing-email setting, and the record of every change to it: Google Cloud Firestore, under your user ID but deliberately outside your profile document, beside a note of your welcome email (the date and which version). The setting is kept away from the document that holds your body measurements and dietary tags, because the mailing list is not allowed to know about them. Once you say yes, your address, your first name, and the emails we send you also sit with Resend in the United States.
• The unsubscribe code record: Google Cloud Firestore, one record per code, holding the code and your user ID and nothing else, so our server can match an unsubscribe to your account.
• The do-not-email list: a separate Firestore collection, keyed by a one-way hash of an email address and holding a reason and a date. It contains no address, no name, and no account. It is the only record that outlives account deletion, and “Marketing emails” below explains why.
• Backup copies: Google Cloud keeps automatic backups of our database so a mistake or an outage cannot destroy your food log. See “Backups” below — it changes how long a deleted account can linger, and we would rather you heard it from us.

Backups

Since September 5, 2026 our database is backed up automatically. This protects you from us: a bad deploy or a mistaken script cannot take your food log with it. It also has a consequence we should state plainly rather than bury.

• Google Cloud keeps a rolling 7-day rewind window on the live database, a daily backup kept for 7 days, and a weekly backup kept for 14 weeks.
• So when you delete your account, a copy of your data can survive in those backups for up to 14 weeks after deletion, even though it is gone from the live database within seconds. This is normal for any service that keeps backups, and it is the honest reading of “deleted immediately” — immediately from the database you use, not from the safe in the basement.
• Backups are encrypted, are readable only by the developer, and are never browsed. They exist to be restored from, not to be looked at.
• If we ever restore from a backup, we re-apply every deletion made since that backup was taken. A restore does not resurrect a deleted account.
• After 14 weeks, the last backup containing your data expires on Google’s schedule and nothing of it remains.

The food catalogue is backed up too. It contains no user data, so nothing of yours is in those backups.

Account isolation

Firestore security rules scope all data to your authenticated user ID; no other user — and no unauthenticated request — can read or write your namespace. Sensitive operational records (rate-limit counters, usage metrics, retry-protection records) are server-write-only and cannot be modified from a client, even by you.

Account security

If you sign up with an email address and password:

• We ask you to verify the address: Firebase sends a verification link to the inbox you signed up with.
• Sign-ups using known disposable-email domains are rejected.
• Repeated failed sign-in attempts are throttled. That throttle is kept on your device only, stored under a hashed key rather than the address you typed, and is never sent to our servers.

Transit and at-rest encryption

All network traffic between the app and our backend uses HTTPS/TLS. Firestore and Firebase Authentication encrypt data at rest using Google Cloud’s standard infrastructure encryption. Our backend authenticates to the AI service with the Cloud Function’s own service-account identity rather than an API key, so there is no AI credential to embed in the app binary or to leak.

Abuse prevention

AI requests are capped server-side (currently 20 per user per UTC day), authenticated end-to-end, and user-provided text is sanitized before being embedded in AI prompts. These limits cannot be bypassed by a modified app.

How long we keep your data

Apple Health (HealthKit)

If you grant HealthKit access, FitGlass:

• Reads your active energy, resting energy, step count, exercise minutes, and workout history — to display your daily burn and activity alongside calories consumed. This data is displayed on your device only. It is never uploaded to our servers, never sent to Google’s AI, and never included in AI prompts.
• Writes dietary calories, protein, carbohydrates, fat, and fiber for foods you log, and dietary water for drinks you log, so your nutrition appears in Apple’s Health app alongside other sources. FitGlass never reads your nutrition or water back from Apple Health — these types are write-only.

You choose exactly which types to allow when iOS shows the permission sheet, and you can revoke access at any time from Settings → Privacy & Security → Health → FitGlass. The sheet lists each type separately, so you can allow nutrition but deny water, or the reverse, and the app respects either choice.

Consistent with Apple’s App Review Guidelines (§5.1.3), we never use HealthKit data for advertising, marketing, or data mining, never sell it or disclose it to third parties, and never store it in iCloud.

When you delete a water log inside FitGlass, the app also removes the matching water sample it wrote to Apple Health, so the two stay in step. Nutrition samples work differently: FitGlass writes them but does not remove them.

Important: uninstalling the app or deleting your FitGlass account does NOT remove anything FitGlass previously wrote to the Health app — nutrition or water. If you want those gone too, delete them from the Health app yourself (Browse → Nutrition → data source FitGlass). The in-app account-deletion flow reminds you of this.

AI logging (Google Gemini)

Food descriptions — typed, or spoken and transcribed on your device — and photos you send through the AI chat go to Google’s Gemini models on Google Cloud Vertex AI, via our Firebase Cloud Function. Specifically:

• The current chat session’s messages — including any photos, compressed and base64-encoded — are sent. Once you save a photo-based proposal, later messages in that session reference the identified foods by name instead of re-sending the photo.
• Your daily targets, up to 12 of today’s logged entries (name, meal type, calories), and up to 8 repeated meals from the past 14 days are included so the AI can respond in context.
• If you ask for a meal plan, your five computed daily targets and your dietary constraint tags are included. If you ask about your history, up to 7 daily and 3 monthly nutrition totals are included. Both are described in full under “AI conversation content” above. Neither was sent before August 15, 2026.
• Your identity is not sent: no user ID, email, or name goes to Google’s AI. Only our Cloud Function knows which request belongs to which account. Being honest about what that is now worth: the request is authenticated with our Cloud Function’s own Google Cloud identity, and the same Google Cloud project holds your Firestore data. The content and your identity are still not joined in the request, but they are no longer held by two separate companies.

Which Google product this is matters. FitGlass uses Vertex AI, Google’s enterprise cloud service, under the Google Cloud terms. It is not the consumer Gemini app and not the free Gemini API tier, both of which have materially different data terms — the consumer app allows routine human review of a subset of conversations, and the free API tier allows Google to use submitted content to improve its products. Neither applies here.

Per Google’s service specific terms (the “Training Restriction” and “Handling of Prompts and Generated Output” sections): Google will not use customer data to train or fine-tune its AI models without permission, and it will not store prompts outside our own account for longer than is reasonably necessary to produce the response, nor store the response at all. Note the shape of that second commitment — it is a “no longer than necessary” standard, not a fixed number of days. Our previous AI processor published a 30-day deletion window; Google does not publish an equivalent figure, and we will not invent one.

Three qualifications to that, which Google documents and we think you should know:

• Prompt logging is off. Vertex AI can write requests and responses to a log, but the feature is disabled by default and we have not enabled it.
• There is a 24-hour cache. By the same page, Google caches inputs, outputs, and derived data in memory to speed up responses, isolated to our project, with a 24-hour expiry. This is on by default and we have not turned it off.
• Flagged requests are kept for up to 90 days. Per Google’s abuse monitoring documentation, if automated safety classifiers detect suspicious activity, Google may log those prompts to check whether its usage policies were broken, store them for up to 90 days, and let authorized Google employees review them. Google states this data is not used to train or fine-tune models. This is not routine review of everything — it happens only after a classifier flags a request.

On our side, the structured response (identified foods and their nutrition — not your raw message or photo) is retained for about 10 minutes for retry protection, then expires automatically. When you commit an AI proposal, the proposed-vs-saved delta is kept as a correction record (see “Information we collect”) to improve accuracy.

Voice input (microphone)

FitGlass lets you log a meal by speaking instead of typing.

The audio stays on your device. When you tap or hold the microphone button, FitGlass captures audio from your microphone while that capture is active and converts it to text using Apple’s speech recognition running entirely on your device. We never receive the audio. It is not sent to our servers, it is not sent to Google, and it is not saved to a file — it exists only in memory while you are speaking and is discarded when the capture ends. A single capture is capped at 60 seconds and stops on its own after a short silence.

On-device recognition is required for every capture. If your device or your selected language has no on-device speech model available, voice input is disabled rather than falling back to network transcription.

To recognize food words more reliably, the names of foods you have logged recently are given to the on-device recognizer as hints. Those hints stay on your device.

The text is handled like anything else you type. Once your speech has been transcribed, the resulting text is treated exactly like a message you typed into the AI chat — it is sent to our backend and on to Google’s Gemini models on Vertex AI to be turned into a food entry, as described in “AI logging (Google Gemini)” above.

Where you start the recording determines when that happens. If you start it from the chat composer, the transcribed text appears in the message field as editable text and is sent only when you send it. If you start it from the Home screen, the text is sent for analysis automatically once you stop speaking; a discard control is shown while the recording is being finalized, and you can slide left while holding the button to throw a recording away before it is used.

What we measure. We record anonymous counters about voice usage — that a capture happened, which screen it started from, roughly how long it lasted, whether you tapped or held the button, and whether it succeeded. These counters contain no audio and no transcribed text.

Permissions. Voice input needs your permission for both Microphone and Speech Recognition. iOS asks the first time you press the microphone, not when you open the app, and you can withdraw either permission at any time in Settings → Privacy & Security. Declining only disables voice input — you can still log food by typing, by photo, by searching Jar, with a quick add, or by entering it manually.

Siri and Shortcuts

Since version 1.11.0 FitGlass offers four shortcuts that iOS can run — from Siri, from the Shortcuts app, or from an automation you build yourself:

• Today’s Calories — says what you have logged today and what is left.
• Log Water — adds a drink.
• Log a Quick Food — logs one of the app’s 15 fixed presets.
• Log Food with AI — hands a sentence to the AI chat.

Speaking to Siri is not the same as using the microphone inside FitGlass, and the difference matters. The in-app microphone transcribes your speech on your own device and we never receive the audio, as described above. Siri is Apple’s service. When you talk to Siri, Apple handles your voice under Apple’s privacy policy, not this one, and we have no part in it and no access to it. What reaches FitGlass is the finished text, exactly as if you had typed it into the app. If you would rather no voice data reach Apple, do not use the Siri phrases — every shortcut also runs by tapping it in the Shortcuts app, and every one of these actions already exists inside the app.

Three further things worth knowing:

• Today’s Calories requires an unlocked device. It is the one shortcut that reads your data out loud, and Firebase keeps you signed in after your first unlock. Without that requirement, a locked phone would recite your calorie intake to whoever picked it up. The logging shortcuts stay available on a locked device, because logging water at the gym is the point and a write reveals nothing.
• Log Food with AI does not log anything on its own. It opens the app and puts your sentence in the chat, where the normal review step applies. You still confirm the food cards. The sentence is held in memory for at most five minutes and is discarded if you never arrive.
• What the system can see of your foods is our fixed preset list, the same 15 items for every user — so a shortcut you build can name “Coffee” or “Banana”. Your own logged foods are not exposed to Shortcuts or Spotlight.

Reminders and notifications

FitGlass sends meal and water reminders. They are local notifications: your device schedules and shows them by itself. There is no push server, FitGlass holds no device token, and no reminder is ever sent from our backend.

• When we ask. iOS asks for notification permission once, as you finish onboarding. Declining disables reminders and nothing else. iOS never asks twice, so you change the answer in Settings → Notifications → FitGlass.
• The app learns when you actually eat. Reminder times are derived from the times you have logged meals, taking the middle of your own history and splitting weekdays from weekends. This is computed on your device from your own entries, it is stored on your device, and the result is never sent to us. If you log too irregularly for the estimate to mean anything, the app falls back to fixed times rather than guessing.
• The app counts whether reminders work, and stops the ones that do not. Your device keeps a tally of how many reminders of each kind it has shown and how many you opened. After a run of ignored ones it thins that kind, and then stops it. Those counters live in the app’s own storage on your device — they are never written to our database, and they can only ever reduce what you receive.
• Taps. Opening a reminder now takes you to the screen it is about, and records an analytics event naming the kind of reminder and how long it had been waiting. It carries no reminder text and no food names.

Marketing emails

FitGlass can email you about the app — new features, how to get more out of what is already there, and new posts on our blog.

It is off unless you turn it on. There is no pre-ticked box anywhere, and creating an account does not sign you up. There are two places to say yes, and both are a box you tick yourself: an optional one on the last screen of setup, separate from the box that accepts this policy and with no effect on whether you can finish; and a switch at Profile → App → Marketing emails. Neither is bundled with anything else — you gave us your email address so you could log in, and that is not the same as asking to hear from us. Until you say yes for the first time, we hold no marketing record about you at all — “off” is the absence of a record rather than a stored “no”. The app never writes the setting itself; it asks our server to, so that every consent we hold carries a timestamp we control.

Saying yes sends one welcome email straight away. It goes once per account, ever — switching off and on again does not send another. Your account’s age picks the version: under 7 days old, a welcome; older, a short guide to features you may have missed. Open tracking and click tracking are both off.

What the list holds. Your email address, your first name if your account has one, and whether you are currently subscribed. Beyond that, our email provider receives only the emails we send you, each with your unsubscribe code. Your “first name” is the first word of the display name on your account — the rest is discarded before anything is sent.

Your Firebase user ID is never sent to our email provider. The list has no way to point back at your account. This is enforced in code, not just promised here: a single function builds the list entry, its fields are exactly the three above plus which list to add you to, and a test asserts that exact set so nothing else can be added quietly. The unsubscribe code is not your user ID and cannot be turned back into it. Only our server can match it to your account.

What the list will never hold — and this one is absolute. Nothing about your health. Not what you eat, not a food you logged, not your weight, height, age, sex, goal, dietary tags, streak, or targets. Not anything read from Apple Health. Not a summary or a score derived from any of it. We do not segment the list by health data, we do not personalize a message with it, and we do not export it to our email provider for any purpose. Three separate rules require this, and any one of them would be enough on its own:

• Apple’s App Review Guidelines (§5.1.2(vi) and §5.1.3(i)) forbid using health and fitness data for marketing.
• Washington’s My Health My Data Act treats your nutrition and body data as consumer health data, which may not be used beyond running the service you asked for without your separate consent. We are not going to ask you for it.
• Nevada’s SB 370 does the same for Nevada residents.

The practical effect: an email from us cannot know what you had for lunch, because the system that sends it has never been told.

How to stop. Move the switch back, or use the unsubscribe link that every message carries. The link opens a page on our own server, and pressing its button unsubscribes you. Opening the link alone changes nothing, because mail scanners open links by themselves. Your mail app’s own Unsubscribe button uses the same link and acts in one step. Stopping marks you unsubscribed rather than deleting the contact. When you delete your account, we ask Resend to delete the contact.

We keep evidence that you said yes. Every change to this setting appends a row under your account recording what changed, when, and what caused it — the setup box, the in-app switch, an unsubscribe, a spam complaint, or account deletion. Canadian law puts the burden of proving consent on the sender, which is the reason this record exists. It is deleted along with everything else when you delete your account.

One record outlives your account: the do-not-email list. If a message to your address permanently bounces, or you mark one as spam, we store a one-way hash of the address together with the reason and the date. No address, no name, no account — it is only ever used to answer “may we mail this one?”. It survives account deletion on purpose, so that deleting and re-creating an account cannot put a dead or complaining address back on the list. Nothing removes a row from it automatically. If you think your address is on it by mistake, email support@fitglass.app.

What happens when something fails. When you switch marketing email on, we record your consent first and tell the provider second. If that second step fails, your consent is on file and you are not on the provider’s list, so nothing after the welcome email reaches you. Nothing retries it. The failure is written to our logs and stays wrong until a person fixes it by hand. If an unsubscribe from the link cannot reach Resend, the page says it did not go through and asks you to try again.

Service email is different and is not covered by this switch. Password resets, address verification, a reply to your own feedback, and notices about this policy or your account are sent because they are part of running the service. They are not marketing, there is nothing to unsubscribe from, and turning marketing email off does not stop them.

The law that applies to this

Canada — CASL. FitGlass is operated from Saskatchewan, Canada. Canada’s Anti-Spam Legislation therefore governs every commercial message we send, to every recipient, wherever they live. It is stricter than the US rule in four ways that matter to you:

• It requires your express consent before a message is sent. An opt-out afterwards is not enough.
• It requires every message to identify us by name and carry a mailing address, and that address must stay valid for at least 60 days after the message is sent.
• It requires the unsubscribe mechanism to keep working for 60 days after the message.
• It puts the burden of proving your consent on us, not on a regulator.

Every message we send carries our name and a mailing address. If that address changes, the old one keeps receiving mail for 60 days after the last message that showed it.

United States — CAN-SPAM. Recipients in the United States are also covered by the CAN-SPAM Act. Meeting CASL also meets it, and we honor an opt-out straight away rather than taking the 10 business days that law allows.

EEA, UK, and Switzerland. The lawful basis is your consent (GDPR Art. 6(1)(a), together with the consent rule in the ePrivacy Directive Art. 13). You can withdraw it at any time, without giving a reason, and withdrawing it does not undo anything sent before.

Analytics and crash reporting

FitGlass uses two Firebase products for operational telemetry. Both are disabled in development builds and active only in TestFlight / App Store builds.

• Firebase Crashlytics — when the app crashes, a stack trace and basic device metadata (model, iOS version, build number) are sent to Firebase on next launch. Your Firebase user ID is attached so we can correlate a crash with your account if you report a problem. Crash reports never include food entries, profile data, or AI messages. Google retains crash data for 90 days.
• Firebase Analytics — collects usage events plus standard device metadata. The events are: app opens and sessions; a food_logged event carrying only the logging method, meal type, and a rounded calorie number; a water-logged event carrying only the amount; opening the AI chat; each onboarding step you finish and finishing onboarding; an AI error or a daily-limit message being shown; voice-capture counters (which screen it started from, a coarse duration bucket, whether you tapped or held the button, and whether it succeeded or, if not, which of a fixed set of reasons it failed for); how many of the AI’s proposed changes the app applied, skipped, or rejected, and whether you undid one; the three steps of email verification; a screen-view event carrying the name of the screen; opening a reminder, with the kind of reminder and how long it had waited; and running a Siri or Shortcuts action, with which of the four it was and, if it failed, why. The food_logged and chat-opened events carry a label recording whether the entry began as typed, voice, or photo input. That label carries no content, and neither does anything else on this list — the counts describe what the app did, never what you said or ate. Your Firebase user ID is attached to these events so we can understand real usage per account during the beta — this is app-internal measurement, not advertising. Food names, chat text, photos, audio, transcribed speech, barcode numbers, and any content you author are never sent to Analytics.

No data is used to track you across other companies’ apps or websites (NSPrivacyTracking is false in our privacy manifest), nothing is shared with ad networks or data brokers, and the app never requests the iOS tracking permission.

Your rights and how to exercise them

You can act on your data at any time, from inside the app, without contacting us:

• Access / export. Profile → Export my data produces a JSON file containing your profile and your food entries from the past 365 days. Share it anywhere via the iOS share sheet. The export does not yet cover your water logs or your marketing-email records — for those, for entries older than 365 days, or for a complete copy of everything we hold, email us and we will send it.
• Correction. Edit your profile from Profile → Edit profile; edit or delete any logged entry from the Dashboard, and any water log from the hydration screen.
• Deletion. Profile → Delete account (with re-authentication) immediately deletes your food entries, water logs, profile, and authentication account. Residual server-side records (derived totals, correction records, rate-limit counters, usage metrics) are removed by a server-side cleanup within 30 days, and Google purges authentication data from backups within 180 days. Deletion is permanent — signing in again later creates a fresh, empty account.
• Stop marketing email. Turn the switch off at Profile → App → Marketing emails, or use the unsubscribe link in any message we send. Either one updates the other: an unsubscribe by email turns the in-app switch off, and the switch tells Resend. Stopping affects nothing else — every feature of the app keeps working exactly as it did.
• Withdraw a permission. Voice input needs Microphone and Speech Recognition; you can turn either off at any time in Settings → Privacy & Security. Doing that — or simply never pressing the microphone button — disables voice input and nothing else: typing, photos, Jar search, quick-add, and manual entry all keep working. HealthKit access is withdrawn separately (see “Apple Health (HealthKit)” above).

Data FitGlass wrote to Apple Health is not covered by in-app account deletion. The one exception is water: deleting a water log inside FitGlass also removes the sample it wrote. Everything else — and anything left over after you delete your account — must be removed by you from the Health app.

For anything else — a full export, a deletion you can’t perform in-app, or any question — email privacy@fitglass.app from the address on your account (that’s how we verify it’s you). We respond within 7 days and honor requests within the timeframe your local law requires.

US state privacy rights

If you live in California or another US state with a comprehensive privacy law (Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and others), you have rights to know, access, correct, delete, and obtain a portable copy of your personal information — all of which the in-app tools above already provide, to everyone, regardless of state.

• We do not sell your personal information, and we do not share it for cross-context behavioral advertising. There is nothing to opt out of. Marketing email is neither: it goes only to people who asked for it, it is sent by us rather than sold to anyone, and it is never targeted using health data.
• We do not use sensitive personal information for anything beyond providing the service you asked for.
• We will never discriminate against you for exercising a privacy right.
• You may use an authorized agent to submit requests by email; we will verify the request with you directly.
• If we decline a request, you may appeal by replying to our response; we will answer the appeal within the period your state’s law requires.

Consumer health data (Washington & Nevada)

Nutrition, body-measurement, and fitness information is “consumer health data” under Washington’s My Health My Data Act and Nevada’s SB 370. Residents of those states: see our separate Consumer Health Data Privacy Policy for the required disclosures — categories collected, sources, purposes, sharing, and how to exercise your rights to access, withdraw consent, and delete. In short: we collect health data only to run the app for you, we share it only with the processors listed above, and we never sell it.

Users in the EEA, UK, and Switzerland

Lawful bases

International transfers

FitGlass data is stored in the United States (Firestore nam5; Cloud Functions in us-central1; the marketing list at Resend).

AI analysis is the exception, and we want to be exact about it. Our backend calls Vertex AI’s global endpoint, because the regional endpoints do not serve the Gemini model we use. Google documents that global endpoints “route and process data anywhere globally” and do not provide regional isolation or data-residency guarantees, and it warns that you cannot know which region a given request was processed in. So we cannot tell you which country analyses your food description or photo. We can tell you it is a Google facility, that it is transient, and that the storage above is unaffected — your food log stays in the United States either way.

Transfers from the EEA, UK, and Switzerland are protected by Google’s safeguards as our processor. Google’s Cloud Data Processing Addendum names Google as a processor and incorporates the Standard Contractual Clauses where they are required for a transfer. Google separately states that it complies with the EU–US Data Privacy Framework and the UK Extension. Resend’s Data Processing Addendum likewise incorporates the Standard Contractual Clauses and the UK Addendum, and Resend states that it complies with the same framework and extension. If your own risk assessment depends on knowing the destination country for AI processing, the honest answer today is that we cannot supply one — email us and we will tell you where things stand.

Your rights

You have the rights of access, rectification, erasure, restriction, portability, and objection (GDPR Arts. 15–21), and the right to withdraw consent at any time without affecting prior processing. Exercise them via the in-app tools or by email. You also have the right to lodge a complaint with your local supervisory authority.

Children’s privacy

FitGlass is not directed to children and is not intended for anyone under 13 (or the higher minimum age your jurisdiction sets for consenting to data processing — e.g., up to 16 in parts of the EEA). We do not knowingly collect personal information from children. If you are a parent or guardian and believe your child has created an account, contact privacy@fitglass.app and the account and its data will be deleted.

Changes to this policy

If this policy materially changes — a new processor, a new category of data, or a new use of existing data — the “Last updated” date at the top will be revised and the change summarized in the change log below.

For significant changes we show you a notice in the app, before or at the time the change takes effect. If we also email you about a change, that is a service message about your account, so it reaches you whether or not you have marketing email switched on.

Continuing to use FitGlass after the effective date of a revised policy means you accept it; if you don’t, you can delete your account from the Profile screen.

Contact

For privacy questions, data requests, or anything else covered by this policy, email privacy@fitglass.app. Responses within seven days.

Change log

• v2.6 — September 14, 2026. One subject: marketing email. Version 2.5 said FitGlass “sends no marketing email and runs no mailing list”. That stopped being true, and this version corrects it.
  • Removed the false sentence. The consent system is deployed and working: the switch, the server function behind it, the provider account, and the unsubscribe feed all exist, and at least one real address is on the list. Saying we run no mailing list was accurate when v2.5 was written and was not accurate a day later.
  • Added a “Marketing emails” section, describing what is actually built. The list holds your address, your first name, and whether you are subscribed — nothing else, ever, and nothing about your health. It is off until you say yes, in one of two places: an optional unticked box at the end of setup, separate from the box that accepts this policy, and a switch in Profile. Neither is bundled with sign-up. Your Firebase user ID is never sent to the provider, which is enforced by a test rather than only promised here.
  • Named the email provider: Plus Five Five, Inc., trading as Resend, with its privacy policy, data processing addendum, and sub-processor list. It is a new row in the sharing table and the only processor there that is neither Google nor Apple, so the count under that table moved from four of five to four of six.
  • Disclosed the welcome email. Saying yes sends one straight away, once per account, in one of two versions chosen by account age, with open and click tracking off. Every message carries our name and a mailing address. Its unsubscribe link carries a code, not your user ID, and the record that matches the code to your account is deleted with the account.
  • Added CASL. FitGlass is operated from Saskatchewan, so Canadian law governs every message we send regardless of where the recipient lives, and it is stricter than CAN-SPAM: express consent, sender identification with a mailing address valid for 60 days, an unsubscribe that works for 60 days, and the burden of proving consent on us. This is the first version of this policy to mention Canada at all.
  • Disclosed the consent record. Every change to the setting appends a row saying what changed, when, and what caused it, because CASL puts the burden of proof on the sender. It is deleted with your account.
  • Put the in-app notice back as the way significant changes are announced. v2.5 replaced it with a promise to email everyone, because no notice existed then. The notice ships with this version, and nothing in the app can send bulk email, so the promise moves back.
  • Disclosed the do-not-email list, which outlives account deletion. A permanent bounce or a spam complaint stores a one-way hash of the address with a reason and a date — no address, no name, no account. Every other record goes when your account goes; this one does not, and the reason is stated rather than buried.
  • Said plainly that a failed sync is not retried. If a consent change fails to reach the provider, nothing retries it. The failure is logged and a person fixes it by hand.
  • Added marketing email to “How we use your information”, the storage and retention tables, the rights list, the US state rights section, and the GDPR lawful-basis table.
• v2.5 — September 8, 2026. Four months of app changes, disclosed together ahead of an App Store submission. No new company receives your data in this version, and nothing here is a new purpose — every item is a new path through the app.
  • Named the food database Jar, and described both copies. Jar is our own database, built entirely from public USDA FoodData Central releases — about 1.88 million foods. A trimmed copy ships inside the app; the full copy runs as our service on Google Cloud. The old policy described only the bundled copy and called it “the USDA food database”.
  • Disclosed food search against Jar, which is new in 1.10.0 and is the most substantive change here. Search answers on your device first. Your typed words reach our server only after two characters and a quarter-second pause. Our own logs record counts and timings and not the words — but the words ride in the request address, and Google Cloud’s platform request log for our service records the full address, so they can appear there for 30 days. That is stated rather than glossed, because “we do not log your searches” would have been true of our code and misleading about the system.
  • Disclosed Siri and Shortcuts (four actions, new in 1.11.0), and drew the line the old voice section would otherwise have blurred: the in-app microphone transcribes on your device and we never receive the audio, but Siri is Apple’s service and Apple handles your voice under Apple’s policy, not ours. Also recorded that Today’s Calories requires an unlocked device, that Log Food with AI opens the app rather than logging silently, and that only the 15 fixed presets are exposed to the system.
  • Disclosed what reminders now learn. Reminder times are derived on your device from when you actually log, and your device counts which reminders you ignore so it can stop sending them. Both stay on the device and are never written to our database. Also recorded that iOS asks for notification permission at the end of onboarding.
  • Disclosed that the AI can change entries you already logged. When you ask it to fix or remove something, the request to Google now includes today’s saved entries — up to 25, with names, meal types, macros, and the internal record IDs the app needs to tell them apart. The record IDs are called out by name because the previous version said no identifier was sent. They identify rows inside your account, not you.
  • Disclosed barcode scanning. Your phone decodes the barcode itself and sends only the number. No image of the product is uploaded. Unmatched numbers are kept, with no account attached, so we know which foods to add.
  • Disclosed backups, and what they mean for deletion. The database now has a 7-day rewind window, a 7-day daily backup, and a 14-week weekly backup. So a deleted account can persist in a backup for up to 14 weeks after deletion. The old policy said deletion was immediate and left it there; that was true of the live database and incomplete about the rest. Also stated: a restore re-applies every deletion made since the backup.
  • Disclosed the device-integrity check (Apple App Attest) and the daily cost table in BigQuery. Neither holds personal data, and both are listed anyway because “we send something to Apple and Google on launch” should not be something you find out from a network trace.
  • Brought the analytics event list up to date. It had grown from two kinds of event to eighteen — water, onboarding steps, AI errors, rate limits, agent actions, undo, email verification, screen views, reminder opens, and Siri actions. No content is in any of them, which was true before and is still true.
  • Replaced the promise of an in-app notice for significant changes. No such notice exists in the app yet, so the old sentence described something we could not do. Significant changes are announced by email to the address on your account, and the in-app notice is named as work in progress.
  • Added barcode scanning and search to the list of ways a food reaches your log, and to “How we use your information”.
• v2.4 — August 31, 2026. Changed the contact address in this policy from fitglass.app@gmail.com to privacy@fitglass.app. Nothing else changed: the same person reads the mail, the response time is still seven days, and no data practice, processor, or retention period is affected. Use the new address for any new request.
• v2.3 — August 15, 2026.
  • Changed the AI processor. AI food analysis moved from Anthropic’s Claude API to Google’s Gemini models on Google Cloud Vertex AI. Anthropic no longer receives anything and has been removed from the processor table. This was a real processor change, not a rename — v2.2’s note that a change involved “no new processor” does not apply here.
  • Replaced every Anthropic-specific retention claim rather than transferring it. The old policy said Anthropic deleted request content within 30 days and could keep policy-violating content for up to 2 years. Neither figure describes Google. Google’s terms instead commit to not storing prompts longer than is reasonably necessary to produce the response, with no fixed day count published; separately, requests flagged by Google’s automated safety classifiers may be kept up to 90 days. Both claims are now cited to Google’s own terms and documentation.
  • Disclosed two things Google’s service does that the old processor’s terms did not describe: a 24-hour in-memory cache of inputs and outputs that is on by default, and optional request logging that is off by default and that we have not enabled.
  • Corrected the international-transfers section, which would otherwise have become false. The policy previously said all data is processed in the United States. That remains true for storage, but the AI requests now go to Vertex AI’s global endpoint, which Google documents as providing no data-residency guarantee. We cannot tell you which country processes a given AI request, and the policy now says so instead of implying the US.
  • Disclosed new data reaching the AI, which is the substantive part of this update and is separate from the processor change. Asking the AI for a meal plan now sends your five computed daily targets and your dietary constraint tags; asking about your history now sends up to 7 daily and 3 monthly nutrition totals, including micronutrient totals. Neither was sent to any AI before this version. Some dietary tags reveal health information or religious observance, so they are named explicitly and given their own row in the GDPR lawful-basis table.
  • Added meal planning and history summaries to “How we use your information”. They are new uses of data we already held.
  • Noted that the identity separation is weaker than it was. We still send no user ID, email, or name with an AI request — but the AI processor is now the same company that stores your food log, so the content and your identity are no longer held by two unrelated companies.
  • Clarified that FitGlass uses Vertex AI under Google’s enterprise cloud terms, not the consumer Gemini app and not the free Gemini API tier, both of which have weaker data terms.
  • Corrected the encryption note: the backend no longer holds an AI API key in Secret Manager, because Vertex AI is authenticated with the Cloud Function’s own service-account identity.
  • Renamed the “AI logging (Anthropic)” section to “AI logging (Google Gemini)” and updated the cross-references to it.
  • Corrected two counts that were already slightly off: the repeated-meals context is capped at 8 meals, and it carries how often you logged each.
• v2.2 — August 13, 2026.
  • Added voice input / microphone disclosure for the speech logging the app shipped on July 30, 2026: a new “Voice input (microphone)” section covering on-device transcription, the recognition hints, the Microphone and Speech Recognition permissions, and what happens to the transcribed text depending on whether you start the recording from the chat composer or from the Home screen.
  • Stated that the audio itself is never collected, uploaded, stored, or sent to Anthropic, and added it to “What we do not collect”, “Where your data lives”, and the retention schedule.
  • Noted that AI chat text sent to Anthropic may have been transcribed from speech (no new processor — Anthropic was already listed), and that analytics events now include anonymous voice counters and a typed / voice / photo origin label carrying no content.
  • Added an “Account security” note: email verification for email/password sign-up, rejection of known disposable-email domains, and on-device throttling of repeated failed sign-in attempts.
• v2.1 — July 16, 2026.
  • Added the hydration tracker: water logs (amount, timestamp, and how they were logged) are a new category of data stored under your account, and a daily water goal is a new profile field.
  • HealthKit writes now include dietary water. Clarified that nutrition and water are write-only — FitGlass never reads them back — and that the permission sheet lets you allow or deny each type independently.
  • Disclosed that deleting a water log in the app also deletes the water sample FitGlass wrote to Apple Health. The previous wording said no third-party app could remove Health entries on your behalf; that is accurate for nutrition but was not accurate for water.
  • Noted that water logs are deleted with your account, and that the in-app JSON export does not yet include them (email us for a copy).
  • Added new display preferences: unit choices (kg/lb, cm/ft-in, ml/fl oz) stored with your profile, and an appearance choice (light/dark/system) stored on your device only.
  • Water reminders join meal reminders as local, device-only notifications.
  • Disclosed the on-device copy of your food log (a SQLite database in the app’s App Group container) that the app added in July 2026 to work offline. It never leaves your device and is erased on sign-out or account deletion.
• v2.0 — July 2, 2026.
  • Email/password sign-in is now available (v1 said it was disabled). Added a description of how passwords are handled.
  • Corrected the analytics description: Firebase Analytics events carry your Firebase user ID and a food_logged event (method, meal type, rounded calories) — v1 described analytics as anonymous. No content (food names, messages, photos) is sent, as before.
  • Disclosed that the structured AI response is retained server-side for ~10 minutes for retry protection (v1 said requests were dropped immediately; the raw request still is).
  • Disclosed AI correction records (proposed-vs-saved food names and calories, used to improve accuracy).
  • Expanded the HealthKit section: reads now cover active energy, resting energy, steps, exercise minutes, and workouts (display-only, on-device); writes now include fiber.
  • Added: server-maintained daily/monthly nutrition totals, the feedback-email contents, precise Anthropic retention terms (30-day deletion, no training), a full retention schedule, US state rights, EEA/UK lawful bases and transfer safeguards, and a separate Consumer Health Data Privacy Policy for Washington and Nevada residents.
• v1.0 — April 25, 2026. Initial policy.