Privacy Policy
Last updated 30 August 2026
Kitchive is a recipe app for your phone. This policy describes what it does with your information, which is very little, and it is written to be checkable rather than reassuring: every claim below corresponds to something in the app's source code or in the server's, and the technical declarations in the App Store listing say the same thing.
The short version
- There is no account. No email address, no password, no Sign in with Apple. Kitchive has no way to know who you are and no plans to acquire one.
- Your recipes are on your phone. Titles, ingredients, steps, notes, photos, ratings, tags, and folders are stored on the device. If you switch on iCloud sync they are also in your iCloud, which is between you and Apple. There is no copy of your cookbook on any Kitchive server, and no way for us to read one.
- There is a Kitchive server, and it exists for one thing: reading an import with AI. When you agree to that, what you sent goes to Kitchive's server, which passes it to an AI provider and hands the answer back. The server stores none of what you sent — no links, no text, no photographs, no recipes, no log of what you imported. What it does write down is a small amount of information about the device, so it can tell a genuine copy of Kitchive from a script and count how many reads you have used. That is described in full below, table by table.
- AI is never automatic on a route you have not been told about. On a link, a dialog names exactly what would leave your phone and where it goes, and you answer it — yes is remembered for links, no is not, and the same question comes back next time. On the paste screen and on the photograph screen the same kind of sentence is printed on the screen itself, and tapping Read the recipe, or taking or choosing the photo, is what sends it.
- AI costs Kitchive money, so it is metered. Three AI reads are free, ever. After that, reading with AI is part of Kitchive Pro, at thirty a day. Everything your phone does on its own — writing, saving, scaling, cooking, searching, organising, and every import route but one — stays free and unlimited.
- One stream of anonymous usage data exists, and it is off until you switch it on, which takes one tap in Settings. It contains nothing you wrote, and it is described in full below so you can decide.
What stays on your device
Everything you create. Recipes, the photos attached to them, ratings, tags, folders, favourites, your chosen theme, and your unit preference are all held in a local database that only Kitchive can read.
Deleting the app deletes all of it, and there is no copy on our servers to fall back on. If that matters to you, use Settings → Export everything to save a readable JSON file wherever you like. The one exception is iCloud sync, which is the next section: switch it on and a copy lives in your own iCloud, which outlives the app on this phone.
The export saves the text of every recipe — including which folder each one is in — and not the photographs attached to them. That is worth knowing before you delete anything.
Optional iCloud sync
If you turn on Settings → Sync with iCloud, your recipes are stored in your private iCloud database so they appear on your other devices.
This is between you and Apple. The data goes into your own iCloud account, under your own Apple Account, in the private database — Kitchive cannot read it, and neither can anyone else with access to our systems, because the systems described below have no copy of a recipe to read. Apple's handling of iCloud data is governed by Apple's Privacy Policy.
This is off unless you turn it on.
Importing a recipe
There are four ways to get a recipe in without typing it: a link, some text you pasted, a photograph of a written recipe, and a photograph of a finished dish.
Each of them has a device layer and an AI layer. Which one runs is decided by what you agreed to, and by what the source turns out to be.
The device layer, which is the floor under everything
A link is fetched directly from your phone, exactly as your browser would if you tapped it, and the recipe is read out of the page here. For TikTok, whose watch pages are a script rather than a page, Kitchive asks TikTok's own public oEmbed address for the caption instead. Pasted text is parsed on the device and needs no network at all. A photograph of a cookbook page or a handwritten card is read by Apple's Vision framework, which is part of iOS and runs on the device.
This layer is free, unlimited, and permanent. It works in aeroplane mode apart from the link fetch, and nothing about it is going away. If you never agree to an AI read, this is the whole of what the app does, and nothing you wrote or photographed reaches Kitchive's server or any AI provider.
The one thing that still leaves this device without an AI read is iCloud sync, and only if you switched it on: it copies every recipe and every photo into your iCloud, which is between you and Apple and which Kitchive cannot read. It is off unless you turn it on, and the section above describes it in full.
Instagram and Facebook sit behind a login wall that no app — this one included — can read without signing in. Kitchive does not try: a link to either is refused before any request leaves your phone, so nothing is fetched and nothing is sent anywhere. It says so immediately rather than appearing to work, and the way through is the same on both routes — copy the caption in and it parses like any other text. Shared to Kitchive from another app, the review screen's paste field is already there below the notice; pasted into Add → Paste a link, the caption goes into the very field the link was in.
A photograph of a finished dish is the exception, and it has no device layer. No amount of reading text off a picture turns a plate of food into a recipe. That route works only with the AI layer below, and the app says so on the card before you photograph anything rather than after.
Which layer actually runs, and in what order
This deserves to be stated plainly, because the obvious guess is wrong and an earlier version of this policy made it.
On a link whose page publishes machine-readable recipe data, your phone reads that data and the AI layer is never asked. Nothing leaves the phone but the fetch of the page itself.
Everywhere else — a link that yielded only a caption, pasted text, a photographed page, a photographed dish — the AI layer is tried first, and the device is the floor underneath it. If the model answers, that is the result you get. If it was not asked, was not allowed, or did not deliver, your phone reads what it can and you are told nothing went wrong, because nothing did.
So the AI layer is not a last resort that only fires on messy sources. What decides whether an import is read with AI is you: your answer to the consent dialog on a link, and your tapping Read the recipe under a paste or taking the photo on the photograph screen, both of which say where it goes before you act — and, after that, the allowance you have left. Not "whether it leaves your phone": a link is fetched from this device whichever layer reads it, which the section on links below sets out in full.
Being told first, separately, per kind of import
Before the first time each kind of import would leave your device, Kitchive names exactly what would leave and where it would go. Not "allow Kitchive to use AI" — a sentence about that import.
There are three separate sentences, and reading one never covers another:
| You are importing | Kitchive says | Where |
|---|---|---|
| a link | Kitchive opens the page on this phone and sends the text it finds to Kitchive's server, which passes it to an AI service to be read. The link itself doesn't leave the phone, and no copy of the text is kept. | a dialog, with Use AI and Just this device as the answers |
| text you pasted | The text you pasted goes to Kitchive's server, which passes it to an AI service to be read. No copy of it is kept. | printed on the paste screen, under the box, before you tap Read the recipe |
| a photograph, of a page or of a dish | The photo goes to Kitchive's server, which passes it to an AI service to be read — or, for a dish, so it can propose a recipe from what it can see. No copy of the photo is kept there; it stays on this phone as the recipe's picture. | printed on the screen itself, above the camera button, before any photo is taken — and, for a photo shared from another app, above a Read the photo button that nothing happens without |
The link route asks, because there a second answer costs nothing: the page is fetched by your phone whichever layer reads it, so "just this device" is a real choice. The paste and photograph routes do not ask; they tell. A paste is read with AI when you tap Read the recipe under the sentence that says so (until 30 August 2026 it asked the same dialog as a link); with no AI route the sentence is not shown and the paste is read on your phone. There is one photo screen for a page and a dish alike — the AI decides which it was sent, in the same call it reads it with — and a photographed dish can only become a recipe through the AI layer, so a dialog there could only be answered "yes" or "cancel". So on that screen the sentence above is on the screen from the start, the photo goes as soon as it is taken or chosen, and nothing stops you in between. If you do not want a photograph read with AI, do not take one on that screen: with no backend configured, or your free reads spent, the sentence disappears, the photo stays on the phone, and a page is read by the phone alone.
Saying no in the dialog is answered for that import only and is not remembered, because a buried permanent "never" is worse than a question you can answer again next week. On a link, saying no still completes the import on your phone — that is the read you asked for.
Saying yes is remembered, and this is the part to read twice. Once you have agreed for a link, later links go to the server without asking again. On the Add screen you still start each import yourself — a photograph starts the moment it is in, which is the act that starts it. On a link shared to Kitchive from another app, the app begins reading as soon as the screen opens — so with link consent already given, a shared link goes to the server and on to the AI provider without a further tap. That is the point of having been asked once. Until that first yes, a shared link is read on the device alone and the screen then offers the AI read properly.
Where it goes, and who else is in the chain
Kitchive's server is a set of small functions hosted on Supabase. It receives what you sent, passes it to an AI provider, and hands the answer back.
There are two AI providers, and both need naming.
- OpenAI is asked first (
api.openai.com). - OpenRouter (
openrouter.ai) is asked instead when OpenAI cannot answer — a connection that never opened, a rate limit, a billing refusal, or a server error on their side. OpenRouter is a router: it passes the request on to the provider serving the model it is configured for, which at the time of writing is Google (a Gemini model). So on a failover, your content reaches OpenRouter and Google behind it.
Which one answered is not something the app tells you, and there is no setting that picks. Both are third parties receiving what you sent, which is why both are named here and in the table at the end rather than only the one that usually answers.
Two small things travel with every AI import besides the content. The
language your phone or the app is set to — a tag such as de-DE, nothing more —
so the recipe comes back in your language; and, on a photographed dish, the name
of the dish you picked from the app's suggestions. Neither is stored.
A photographed dish asks two more services. Once you have picked a dish, the
server looks its name up on TheMealDB (themealdb.com), a public recipe
database, and on Wikipedia (wikipedia.org, in your language and then in
English) for the article that says what the dish is made of — so the recipe it
proposes is grounded in real ones rather than invented. Only the dish's name
goes to either — not the photo, not anything about you or your phone — and both
are named in the table at the end for that reason.
Kitchive will not make promises on either provider's behalf. What they do with what they receive, and for how long they keep it, is governed by their own terms, which are linked at the end. What this policy can say is what Kitchive does, and Kitchive's server stores none of it.
A link is not treated like the others, and the difference matters. Your phone opens the page itself and only the text it read is sent on. The link never reaches Kitchive's server or either AI provider. Pasted text and photographs have no page to fetch, so those go as they are.
One honest qualification to that, because "the link never leaves the phone" is what the dialog says and it is true of us: the link plainly does reach the site it names, since your phone has to fetch the page. For a TikTok link, that fetch is to TikTok's own public oEmbed address with the link in the query. Exactly as if you had opened it in your browser, and no more.
A photograph is sent as a smaller copy, never as the original. Before it leaves, the picture is reduced to at most 1200 pixels on its longest side and re-encoded as a JPEG. The original stays on your phone. Nothing else about the photo goes with it: not where or when it was taken, not the camera, not any other tag your phone attached to it, because the re-encoded copy is built from the pixels alone.
Kitchive does keep the photograph — for you. Whichever layer read it, the picture becomes the recipe's own image on your device, and syncs to your private iCloud with the rest of your recipes if you turned that on. Keeping your photo for you is a different thing from sending it somewhere, so this page says both rather than the tidier "no copy is kept".
What Kitchive's server keeps
Nothing you sent. There is no link column, no text column, no image column, and no recipe column in any table it owns, so there is no database of what you imported. The request is read, answered, and forgotten. The database migrations are in the repository and are the proof.
Nothing you sent is written to the server's diagnostic log either, with one qualification that is worth making rather than hiding. The functions log failure reasons — a provider name, an HTTP status, a rejection detail — and never a link, a caption, a photograph, a recipe, or your subscription identifier. The qualification is that when an AI provider refuses a call, the first 300 characters of the provider's own error message are logged, because that is where anyone diagnosing a broken deployment has to look. Those messages normally describe the fault; a provider that chose to quote part of the request back in one would put that fragment in the log. Kitchive does not put it there, and cannot promise a provider will not.
What is written down is four small tables, and none of them is about you:
- A device row. An Apple-issued attestation key id, the public half of that key, a replay counter, when the device first registered, and when it was last seen. See the next section.
- A counter row. How many AI imports that device has used — for life and today — how many model calls it has attempted today, and whether it currently holds a claim on one. These are kept against a one-way hash of the key id, salted with a secret only the server holds. Integers and dates, nothing else.
- A service-wide row. How many model calls were made across all of Kitchive on a given day. One date and one number, with no device in it at all.
- A subscription-claim row, written only for a paid subscriber. Two one-way hashes — one of RevenueCat's identifier for the subscription, one of the device's attestation key id — each salted with the server's secret, the first through a separate domain so it cannot be matched against the second, plus the dates the claim was made and last used. It binds a subscription to a handful of devices at a time, so a leaked identifier cannot turn one subscription into unlimited free ones. A free user never has one, and nothing in it names a person, a receipt, or an install.
How long they are kept: until they are cleared out by hand. There is no expiry job and no scheduled deletion, and this policy will not claim one that does not exist. What is in them is a key id, some salted hashes, some integers and some dates.
The device row, and why there is one
Kitchive has no accounts, so it cannot ask who you are — and an endpoint that calls a paid model without asking anything would be free computing power for the whole internet within a week, at the owner's expense.
Instead it asks Apple. The first time you agree to an AI read, the app has iOS generate a key in this device's Secure Enclave and asks Apple to vouch that it belongs to a genuine, unmodified copy of Kitchive on real Apple hardware. That vouching — App Attest — is checked against Apple's own certificate authority on the server, and the key is recorded so later requests can prove they come from the same install. The private key never leaves the Secure Enclave and cannot be extracted, by Kitchive or by anyone else.
None of this happens until you say yes to an AI read. A copy of the app whose user never agrees to one never generates a key and never registers anything.
A key id identifies a key, not a person. It is not the identifier Apple gives to any other app, there is no route back from it to you, and deleting and reinstalling Kitchive produces a new one. It is still a stable identifier for one installation of one app, held on a server, alongside the date it registered and the date it was last used — which is why it is described here in this much detail rather than waved at, and why the App Store nutrition label declares it.
The salted hash is not a second layer of anonymity, and this policy will not sell it as one. It stops someone who has only a key id from looking up that device's counters, which is what it is for. It does not stop anyone holding both the database and the salt from joining the two rows, because a hash that can be recomputed can be matched — and the key id sits in the neighbouring table in the clear. What protects those rows is that they are reachable only with the server's own credentials and that there is nothing in them that says whose they are.
Reinstalling therefore resets the free imports. That is a deliberate trade: the alternative is keeping something that survives a reinstall, which is to say something that identifies you.
Your subscription status, on each AI import
Each AI import carries RevenueCat's anonymous identifier for your purchase to Kitchive's server, which asks RevenueCat whether that identifier has an active subscription — so it knows whether you get three for life or thirty a day. It is an identifier for a receipt, never a name and never an email, and it is never sent to either AI provider. Kitchive's server does not keep the identifier itself: a free user's is used to ask RevenueCat and then discarded, and a subscriber's is kept only as the salted, one-way hash in the subscription-claim row above, which binds the subscription to your devices. This policy will not lean on "it is only a hash" — the note on the salted hash above says why.
The consequence worth stating: RevenueCat learns that an anonymous identifier attempted an import, and when. Their policy is linked at the end.
Your IP address needs a more careful sentence than the rest
Every server on the internet sees the address a request came from, and the honest answer is not "never seen". Four parties see it, and saying "we never see it" without saying who does would be the sort of true sentence that misleads:
The site you linked to, when your phone fetches the page — or, for TikTok, its own public oEmbed address. Exactly as it would if you had opened the link in your browser, and no more. Nothing about that fetch is reported back to us.
Kitchive's server, on an AI import. No table Kitchive owns has an address column, hashed or otherwise — the four tables above hold an attestation key id, salted hashes of one and of a subscription identifier, and some counters, and none of them can be joined to an address. The two places an address is used at all are registering a new install and drawing the short-lived challenge that precedes every AI import; in both it becomes a key in one running instance's memory so that nobody can script thousands of registrations, or grind challenges. Nothing writes it down — no table, no log line, nothing that survives the process. What bounds it is not a clock, and saying "an hour" would be the easy sentence rather than the true one: the count against an address stops mattering an hour after the first attempt, but the address itself stays in that instance's map until either Supabase recycles the instance or ten thousand other addresses have arrived and pushed the oldest out. Whichever comes first, it never reaches disk and never leaves that one process.
Supabase, which hosts those functions and keeps ordinary request logs the way every host does. That is their handling rather than ours, and their policy is linked at the end.
PostHog, when an anonymous usage event arrives. That is the one address that lands somewhere Kitchive can read on purpose, so it is the one that needs the care: the app disables the location lookup on every event, and the PostHog project is configured to discard the address rather than store it. The analytics section says exactly what each of those does, what it does not do, and why the privacy manifest still declares Coarse Location.
One thing goes the other way, and it is worth saying. Because the model call is made by Kitchive's server and not by your phone, OpenAI and OpenRouter see the server's address, not yours.
Sharing a recipe out
Sharing is entirely between you and whoever you send it to. Kitchive's share sheet offers three forms of one recipe — a picture of a card, plain text, and a JSON file. All three carry the method as well as the ingredients, so a recipient can cook from what you sent; the card stops at 25 ingredients and 20 steps and says how many more there were. The card also carries the recipe's cover photograph, which is worth knowing before you send one, since that photograph is yours.
Nothing about a share reaches Kitchive. The destination is the one you pick in the iOS share sheet, and the JSON file carries no photographs at all.
Subscriptions
Kitchive Pro is sold through the App Store and managed by RevenueCat. RevenueCat issues Kitchive an anonymous identifier for your purchase; we never call their login API, so that identifier is tied to a receipt and not to a person.
Payment happens entirely between you and Apple. Kitchive never sees your card, your billing address, or your Apple Account.
Pro is where the AI layer is paid for. Each AI read costs Kitchive money, so there is a number rather than a word: three AI reads are free, for the life of the install. After that, reading with AI is a Pro feature at thirty a day. Pro also raises the photo limit from one per recipe to twelve and turns on iCloud sync. Every colour theme is free.
Two honest qualifications on "thirty a day":
- It is a ceiling, not a promise of thirty. There are also caps on how many model calls one device may attempt in a day whether or not they succeed, and a service-wide daily ceiling, both of which exist so that a bug or an abuser cannot run up an unbounded bill. In normal use you will not meet any of them.
- A failed import does not cost you one of your three. Only a read that came back with a recipe is counted.
- Recognising a dish is not an import. The read that turns a photograph of a plate into a list of dishes to choose from costs none of your three; the import is counted when you pick a dish and a recipe is proposed. Dish recognitions have their own, daily number instead: three a day free, thirty a day with Pro. Past it, a photograph of a written recipe, a link and pasted text all still read.
Everything the device does on its own — writing, saving, scaling, cooking, searching, organising, and every on-device import route — stays free and unlimited, for everyone, with or without Pro.
Anonymous usage data
Kitchive sends a small number of anonymous events to PostHog, hosted in the European Union, so we can tell which features are used and — most importantly — why imports fail.
This one is opt-in. It is off when you first open the app
(Analytics.defaultsToEnabled is false in the source), nothing is sent and no
identifier is created until you switch it on, and it stays off unless you do.
Until 30 August 2026 it was the other way round — on until switched off — and
this paragraph said so; it is now the same way round as everything else here.
Switch it on, or off again: Settings → Privacy → Share anonymous usage. Turning it off erases the random identifier it was using, so switching it back on later starts fresh and cannot be joined to the earlier period.
This is the complete list of events. There are no others, and the app contains no general-purpose analytics library that could add any:
| Event | Sent with |
|---|---|
onboarding_completed |
— |
import_started |
which platform (TikTok, Instagram, YouTube, Facebook, web) |
import_succeeded |
which platform, which method (AI, structured recipe data, or a parsed caption) |
import_failed |
which platform, why it failed |
page_read_succeeded |
— |
page_read_failed |
why it failed |
meal_recipe_succeeded |
— |
meal_recipe_failed |
why it failed |
recipe_saved_manually |
— |
paywall_shown |
which screen it was shown from |
trial_started |
— |
theme_changed |
which theme |
cook_mode_started |
— |
Every event also carries the app's version number and a random identifier for the install.
What is deliberately absent: no recipe titles, no ingredients, no links, no creator names, no folder names, no device model, no operating system version, no screen recordings, no screenshots, no location, and nothing that identifies you. The events above are the only things measured, and every value they carry comes from a fixed list — a platform name, a failure reason — rather than free text.
"No location" needs one more sentence than the rest of that list. Everything else on it is absent because the app never puts it in the event. A location is different: it is not something Kitchive has and withholds, it is something an analytics service manufactures on its own. PostHog's servers see the connection an event arrives on and by default look up an approximate city from it, so an event that stays silent is stored with a location the app never had. Saying nothing is how you opt in.
So Kitchive says something. Every event carries $geoip_disable set to true,
PostHog's documented instruction not to run that lookup at all — and
payloadDisablesGeoIPDerivation in AnalyticsTests fails the build if
PostHogSink.payload ever stops sending it. No city, region, or coordinates are
derived. That one property is the whole of what makes the line above true, which
is why it is named here rather than left in the source.
The address the connection came from is a smaller claim, and it deserves the
smaller word. An earlier draft of this page rested it on the app also sending
$ip as null; that does nothing, because the lookup expects an address as text
and falls through a null to the connection. The app still sends it, and nothing
here rests on it. What the address claim rests on is a setting in PostHog's own
project to discard it rather than store it with the event — which lives in
someone else's console, not in this app's code, so no build can verify it. It is
also the later of the two, since PostHog's own documentation says GeoIP
enrichment can still read the address before it is discarded, so it could not be
a fallback for the event property even if a build could check it. That is why
Kitchive's privacy manifest declares Coarse Location for analytics instead of
claiming the category does not apply: declaring something that turns out not to
be collected is harmless, and the reverse is not.
Notifications
Cook mode can set timers that notify you when a step is done. These are local notifications scheduled on your device. Nothing leaves it, and Kitchive asks for permission before scheduling the first one.
Children
Kitchive does not collect personal information from anyone, including children. There is no account to create, no profile, and no social feature.
Your rights
Kitchive holds no personal data about you: no record with your name on it, no email address, no account, and nothing on any server that could be joined to a person. So there is nothing for us to show you, correct, or delete on request, and no way for us to find one if there were.
What you can do at any time, without asking anyone:
- Take your recipes out: Settings → Export everything, which writes readable JSON. It carries the text of every recipe, including which folder each is in, and not the photographs attached to them. Any single recipe can also be exported on its own from that recipe's own menu.
- Delete your recipes: Settings → Delete all data removes every recipe, tag and folder — and, with iCloud sync on, the copies on your other devices with them. Your settings and your answers to the AI questions are deliberately kept, so a user who only wanted their cookbook emptied is not asked everything again; the dialog names both before you confirm, and deleting the app removes them too.
- Stop the usage data: Settings → Privacy → Share anonymous usage.
- Stop iCloud sync: Settings → Sync with iCloud.
- Keep every import away from the AI: answer Just this device to the link and text questions, and do not take or choose a photo on the photograph screen while the sentence about AI is shown on it. Doing both keeps every import off Kitchive's server and away from both AI providers for the life of the app, and the only route that stops working is a photograph of a finished dish, which has nothing on the device to fall back to. (It does not stop iCloud sync, which is the separate switch above.)
Three honest limitations, stated rather than glossed:
- There is no switch that takes an AI consent back once you have given it. A yes to the link question is recorded and is cleared when the app is deleted, and that is currently the only way to clear it. There is no master "turn AI off" toggle in Settings either. Until there is, the accurate description of the control you have is: on a link it is exercised at the moment you are asked, once, and it is not revocable in the app; on a paste and on a photograph nothing is recorded because nothing is asked — the control is whether you tap Read the recipe or take the photo on a screen that says where it goes.
- "Delete all data" does not give you your free AI reads back. The count of reads used lives beside your settings on the phone and in the counter row on the server, keyed to this installation. Deleting the app clears both, because the next install registers a new attestation key.
- The server rows described above are not addressable by you, for the same reason they are not personal data: there is nothing on them that says which one is yours, and no way for us to work it out from anything you could send us.
If you are in the EU or UK, the anonymous usage data is processed on the basis of legitimate interest in improving the app, and you can withdraw from it with the switch above at any time with no effect on how Kitchive works. Sending an import to be read with AI is done on the basis of your consent: on a link, the dialog described above; on a paste, the notice printed under the box, which you act on by tapping Read the recipe; on a photograph, the notice printed on the screen before you take it, which you act on by taking it — or, for a photo shared to Kitchive from another app, by tapping Read the photo under the same notice, since a shared photo arrives already taken.
Third parties
| Who | What for | Their policy |
|---|---|---|
| Apple | The App Store, purchases, optional iCloud sync, and App Attest | apple.com/legal/privacy |
| Supabase | Hosting Kitchive's server functions and their database | supabase.com/privacy |
| OpenAI | Reading an import with AI — the provider asked first | openai.com/policies/privacy-policy |
| OpenRouter | Reading an import with AI when OpenAI cannot answer, and the model provider it routes to | openrouter.ai/privacy |
| RevenueCat | Managing subscriptions, and checking one on each AI import | revenuecat.com/privacy |
| PostHog | Anonymous usage data, EU region, optional | posthog.com/privacy |
| TikTok | Its public oEmbed address, asked for the caption when you import a TikTok link | tiktok.com/legal/privacy-policy |
| TheMealDB | Looked up by dish name, from Kitchive's server, when a photographed dish becomes a recipe | themealdb.com |
| Wikipedia (Wikimedia Foundation) | Looked up by dish name, from Kitchive's server, for the article's first paragraph, when a photographed dish becomes a recipe | wikimediafoundation.org/privacy |
Beyond that table, the only other host this app ever contacts is a site you pasted a link to, which your phone opens the way a browser would.
Nothing is sold, and nothing is shared with advertisers. Kitchive contains no advertising identifier and no tracking SDK.
Changes
If this policy changes in a way that affects what Kitchive collects, the change will be described in the app's release notes rather than quietly published here.
Contact
Questions about this policy, or about anything Kitchive does with your information: info@kitchive.app. The same address is on the site's support page and in its Impressum, which carries the provider's postal address.