TasteBud Privacy Policy

Effective: 19 July 2026 Contact: tastebud.hq@gmail.com

TasteBud looks at the food photos in your camera roll to learn what you like, then suggests meals to cook and places to eat. This policy explains exactly what leaves your phone, what doesn't, and what we keep.

We do not sell your data, show you ads, or use any third-party advertising or analytics SDK.

Your photos

Most of your photos never leave your device. When you scan your library, TasteBud runs a food-recognition model on your phone to decide which photos contain food. Photos it doesn't identify as food — people, documents, screenshots, everything else — are never uploaded, never seen by us, and never sent to anyone.

We do send a tally of how that model scored them. At the end of a scan, the app reports two sets of running totals: how many photos landed in each score range, and — for the photos that fell just short of counting as food — how many came closest to each of the model's own built-in phrases, such as "a photo of a dessert". There is no line per photo, no identifier, and no image: a photo that stays on your phone becomes one tick in a total, and a total cannot be turned back into a picture. We ask for this because that cut-off is the reason the rest of your library stays private, and until now we could only see the photos it let through — which told us when it was letting too much out, but never when it was quietly discarding your food photos.

Food photos are uploaded to our server to be described. They are resized and sent to our backend, which passes them to Google's Gemini API to identify the dish, its cuisine, and its likely ingredients.

We do not store your photographs. We delete each image as soon as the description comes back. What we keep is the text the model produced (for example: "chirashi bowl, Japanese, sushi rice, tuna, salmon, ikura"), the photo's date, and a short code that lets us recognise a photo we have already described, so we don't describe it twice.

Photo location is never uploaded. Photos often carry GPS coordinates. TasteBud reads those only on your device, and they are never transmitted anywhere, in any form.

Your taste profile lives on your phone. The profile built from those descriptions — your cuisines, your most-photographed dishes — is stored on your device, not in an account on our servers.

Your location

If you allow it, TasteBud uses your device location for one purpose: to find restaurants near you and show how far away they are. Your coordinates are sent with each search to our server and on to the Google Places API, which returns nearby restaurants. We do not store your location. If you decline, the "Eat out" section simply cannot show nearby places; nothing else in the app changes.

Usage data

To understand whether the app actually works — whether people find recipes they cook, which suggestions fall flat — we record limited usage information:

• From the app: how many photos a scan looked at, how long it took, how many were food, the score tallies described above, and which recipes were opened, saved, or marked as cooked. Apart from the recipe identifiers — which are ids from our own recipe collection, not anything you typed — these are counts. A scan also reports your device model and iOS version (for example "iPhone16,1" and "18.5"), so we can tell slow hardware from a bug. Every request also says where the app was installed from — the App Store, TestFlight, or a developer build — so we can tell public users from beta testers. That is a fact about the app, not about you.
• When a cookbook search finds nothing: that it happened, and — only if what you typed matches a dish on our own list of dishes we plan to add — the name of that dish, taken from our list. What you actually typed never leaves the phone; a search for anything not on that list is recorded as a bare "found nothing" with no words attached.
• If you send feedback on a recipe: we keep the words you wrote, together with which recipe they were about. This is the one place the app sends something you typed, it only happens when you tap Send, and the screen says so before you do. We read these to fix the recipe; they are never published.
• Setting up: whether you reached the welcome screen, whether you tapped through it, and whether you closed the invitation to scan your camera roll, so we can tell how many people stop at the photo-access question and how many decide against it. Three flags, nothing else — and if you decline access, this is the only thing we ever record.
• When something goes wrong: which step failed and why, as a fixed set of codes we wrote in advance ("extract", "offline"), along with the error status and how many photos were in flight. Never an error message, never a web address, never a photo's name. If the failure is what stopped the report from reaching us, it waits on your phone and goes out the next time you open the app — a failure that erases its own evidence is the one we most need to see.
• On our server: which cuisines and dishes a page of suggestions was built from, so we know where our recipe collection falls short; and, for each photo you upload, how confident the on-device filter was that it was food, which of that filter's own built-in phrases it matched, and whether the description that came back agreed. That is a few numbers and a yes-or-no — no dish name, no file name, no image — and it is how we find the photos the filter gets wrong and stop it sending them.

No photo content, no captions, no free text you write, and no coordinates are ever included in any of this.

Each installation generates a random identifier the first time it runs. It is not linked to your name, email, or Apple ID, and it is not taken from any identifier your phone carries — we generate it ourselves, and it exists to tell one installation's activity from another, so five testers don't read as one. The records above do attach your device model and iOS version to it, which says what kind of phone you use, not which phone. Deleting and reinstalling the app generates a new identifier and permanently disconnects you from the old data.

Who else sees your data

• Google — Gemini receives your food photos to describe them; the Places API receives your coordinates to find nearby restaurants. Google's handling is governed by its own privacy policy.
• Our hosting provider — runs the server that stores the data described above.

That is the complete list. No advertisers, no data brokers, no analytics vendors.

Keeping and deleting data

We keep dish descriptions and usage data while the app is in active testing, and delete data we no longer need.

You can remove your data at any time in two ways:

1. Delete the app. Everything held on your device — your profile, your saved recipes, your photo references — goes with it. 2. Tap "Delete my data from the server". Open Taste → Preferences in the app — the button erases every record our server holds under your installation identifier, immediately. If you prefer email, copy the identifier shown there and write to tastebud.hq@gmail.com; we will do the same by hand.

Children

TasteBud is not directed at children under 13 and we do not knowingly collect information from them.

Changes

If we change how TasteBud handles your data, we will update this policy and its effective date. During TestFlight testing, material changes will also be described in the release notes for the build that makes them.