CosmoYum · Effective date October 7, 2026
CosmoYum (“the App”, “we”, “us”) is a calorie-tracking app that estimates the nutritional content of your meals from a photo, a typed description, a dictated description or a barcode. This policy explains what data we handle, where it goes, how long it stays, and what you can do about it.
No sign-up is required — the App works straight away, with no name and no password. It never asks for your phone number or your location. An email address and a name appear in one case only: if you choose to link Apple or Google sign-in, so your diary does not go missing with your phone (see section 2).
Meal input. When you scan a meal, the App sends what you gave it — a photo, the text you typed, or the text your dictation produced — to our own server (Google Cloud Functions, hosted in the United States), which forwards it to Google’s Vertex AI to identify the dishes and estimate calories and macronutrients. Vertex AI is called through Google’s global endpoint — which region ends up doing the work is Google’s choice, not ours. Everything travels over an encrypted connection. Neither the photo nor the text is stored on our server after the answer comes back, and neither reaches our diagnostic logs (see section 4).
Allergy words. If you tell the App which allergens to warn you about, that list is sent with each meal request — it is what allows the model to answer “this dish may contain honey”. This includes any words you typed yourself. See section 3, which explains why we treat this as sensitive.
Barcodes. If you scan a product barcode, the barcode number is sent to the public Open Food Facts database to look up the product. If that barcode is not in the database and you photograph the label, the brand and product name read off it are sent there as a search as well. Nothing else travels with either request: no identifier of yours, only a line naming the App so the database knows which client is asking.
Dictation. Voice input is transcribed by your device’s own speech recognition (Apple’s Speech framework on iOS). Depending on your device and its settings, Apple may perform that recognition on its servers rather than on the device; we never receive the audio, only the resulting text — which is then treated as meal input above.
In the cloud, under an anonymous identifier. On first launch the App creates an anonymous account (Firebase Authentication). It is an identifier with no name, email or password attached, and it is what keeps your data yours across launches. Stored under it in Google Cloud Firestore:
If you have linked Apple or Google sign-in. The account stays the same one: the identifier does not change, and neither does your diary — linking adds a second way in, it does not create a second account. What Apple or Google sends is added to it: an email address and, on a first Apple sign-in, the name if you allow it to be shared. Apple lets you hide your real address, in which case we receive an Apple relay address and never see the real one. All of it lives in Firebase Authentication and serves exactly one purpose — recognising you on another phone. We have no password and cannot have one: Apple or Google verify the sign-in, not us.
If you subscribe. You pay Apple, not us: we never see your card, your Apple ID or your billing address. Apple reports the purchase to RevenueCat, the service that checks subscriptions for us (section 5), and RevenueCat keeps it under your anonymous identifier — which plan, when it started, when it renews or ends, whether it is a trial, and any refund. Our server keeps a short copy of the current state next to your recognition counter — whether Premium is active, until when, trial or paid — because that is what decides your daily allowance; the counter notes which plan today’s count belongs to. That day’s count is also kept against the subscription itself rather than only against the account — today’s date and number, nothing else — so that it follows the subscription to whichever account holds it.
On your device only. Meal photos. The App keeps a photo as a local file and stores only the path to it — a photo is never uploaded to our storage, only passed through for the analysis described in section 1. Your theme and language choice, and the fact that you accepted this policy, are also local.
Some of what the App holds says something about your body and your health: allergies, sex, date of birth (your age is calculated from it), height, weight and its history, and your weight goal. We ask for each of them for one visible purpose — allergies to warn you about a dish, the rest to calculate your calorie and macronutrient targets — and we do not use them for anything else, do not sell them, and do not share them with advertisers (there are none in the App).
Two consequences worth stating plainly. Your allergy list leaves the device with every meal request, because a warning is impossible otherwise. And your body metrics sit in the cloud rather than only on your phone, so that a new device shows the same diary and the same plan.
Crash reporting. The App uses Firebase Crashlytics. When it crashes or hits a handled error, a report goes to Google containing the error, a stack trace and technical details of the device (model, OS version). Photos, meal contents and credentials are deliberately kept out of these reports.
Server logs. Our server logs each request it handles for diagnostics: the model used, timings, sizes and lengths, how many items were involved. The content itself is not logged — not the photo bytes, not the meal description you typed, not the dish or ingredient names, and not your allergy words (only how many there are). There is a single exception, and it is a breakage: if the model’s answer comes back damaged and the App cannot read it, that answer is kept in the log (truncated to a length limit) — there is no other way to find out what broke — and dish names may appear in that fragment. These logs live in Google Cloud Logging and are retained for a limited period (currently up to 30 days), then deleted automatically.
All traffic uses HTTPS/TLS. Your cloud data is readable only by your own anonymous identifier, enforced by server-side security rules. The App ships with no API keys of its own: it can only reach the AI model through our server, which holds the credentials, so nothing sensitive can be extracted from the installed App.
The recognition counter is the one piece of your data the App can read but not write. Only our server may change it — which is what makes the daily limit a limit rather than a suggestion. Our copy of your subscription the App cannot even read: only the server uses it, so nobody can declare themselves subscribed from a phone.
Your diary and profile stay until you delete them. Deleting a meal in the App deletes it from the cloud as well.
You can delete everything yourself, in the App: Settings → Account → “Delete account and data”. It is immediate and final: the diary, profile, goals, weight log, favorites, photographed labels and recognition counter leave the cloud, and the account itself — along with any Apple or Google sign-in attached to it — stops existing. If you have Apple sign-in linked, the App will ask you to confirm it once more; without that we cannot revoke the access at Apple. What exactly goes and what stays is on the “Delete account” page.
Deleting the account does not cancel a subscription. It belongs to your Apple ID and keeps renewing until you cancel it in iPhone Settings → your name → Subscriptions. Our copy of it is deleted with the account, but the day’s count kept against the subscription stays: it holds no identifier of yours, only a date and a number, and deleting it would reset the daily allowance; RevenueCat keeps the purchase record under the anonymous identifier, which after deletion no longer leads to anything we hold — write to us if you want that removed as well.
Uninstalling the App is NOT deleting your data. The anonymous identifier is kept in the device’s Keychain and outlives the App: the cloud data stays where it is, and installing the App again on the same phone brings it back. If you do want it deleted and no longer have the App, email us at the address below — bearing in mind that with no sign-in linked we have no way of telling which data is yours.
Server logs expire on their own, as described in section 4.
The App is not directed at children under the age of 13, and we do not knowingly collect information from them. If you believe a child has provided information through the App, contact us and we will remove it.
We update this policy when the App changes what it does with data, or when the way to reach us changes. This revision adds the Premium subscription: what a purchase leaves behind (section 2), RevenueCat and the App Store (section 5), and what deleting the account does and does not do to a subscription (section 7). The one before it describes the optional Apple and Google sign-in of section 2 and records that the profile stores a date of birth rather than an age as a number. It also adds products read off labels to section 2, and narrows section 4: the server logs no longer record the content of a meal — neither the description nor the dish names. And it rewrites section 7: an account and everything under it can now be deleted with a button inside the App rather than by email — there is a “Delete account” page devoted to it. The revision before it moved the policy to its own address at cosmoyum.app, with a contact address on that domain rather than a personal mailbox. The revision before it recorded the recognition counter of section 2 and the daily limit it enforces; the one before that, that the diary and profile now live in the cloud, that text and dictation are analysed alongside photos, and that crash reporting is enabled. Material changes are announced in the App. The effective date at the top always reflects the latest revision.
Questions, or a deletion request? Email privacy@cosmoyum.app.