Table privacy policy

Table plans meals for a real household. That means it holds unusually personal things: the names of the people you feed, their food allergies — often a child's — what is in your fridge, and, when you talk to Sous, the sound of your kitchen. This page says exactly what the app does with all of that, in plain language. Where a promise has a limit, the limit is stated.

The short version

• Work happens on your phone wherever it can. Planning, allergy screening, your shopping list and your pantry all run there with no network at all. Only three things need outside help — holding a conversation with Sous (typed, spoken, or while you cook), reading a photograph, and importing a recipe from a link. Each sends data to servers — ours and our providers' — and this page lists every one of those flows and exactly what each recipient gets.
• Everything about your household lives on your phone. There are no accounts, and we run no database. Nothing about you is stored on our servers today, and if we ever ask to keep something — to teach the app to read your fridge better, or to learn which dinners get cooked again — it will be opt-in, off until you turn it on, and described before it starts.
• Before anything leaves your phone, identities are stripped: never a name, an age, a per-person allergy record, a ZIP code or a health goal. What does cross is content — your questions, your pantry, your plan's dish names, your photos, your voice — exactly as you wrote or spoke it, so a name you put in a question yourself does travel.
• Today there are no ads, no analytics, no tracking and no crash reporting. That describes the app as it stands, not every future version — but the limits below are promises: analytics will always be off until you turn them on, and any advertising would be chosen by what is on the screen, never targeted using what this app knows about you.

The long version

The rest of this page walks the same ground slowly: each thing that leaves the phone, who receives it, what they may keep, and where each promise stops. The sections stand alone, so you can read only the one you came for.

What does the app know about me?

Whatever you tell it: the people in your household with their names, age bands, allergies, diets, dislikes and favorite cuisines; your ZIP code and health goal if you entered them; your week's meal plan; your pantry; your shopping lists and shops; recipes you save or import; your cook log and streak. All of it is stored only on your phone, in the app's private storage, protected the way iOS protects app data generally (we add no encryption of our own on top).

And, only if you turn it on, what you said to Sous. Settings has a "Keep Ask conversations" switch, off unless you choose otherwise. With it on, the app stores the text of your last 10 Ask conversations on-device only — never uploaded, never leaving this phone — for 30 days — nothing older, nothing beyond ten, and never anywhere but here. Turning the switch off deletes what was saved, and there is a button to delete them without turning it off. This changes nothing about what leaves your phone: what you say to Sous is processed as described below whether or not a copy is kept here.

What leaves my phone, and who gets it?

If the phone can do it, the phone does it. That is the rule the app is built to, not a happy accident, and new features are held to it even when sending the work away would be easier to build. Turn on airplane mode and the app still plans your week, still builds and merges the shopping list, still screens every recipe against your allergies, still works out what a dish costs — even matching what a photo scan found against the ingredient list happens on the phone (the scan itself is one of the three flows below). The limit is dish photos, which come from the image libraries described below: the app fetches this week's ahead of time, while you have a connection, and a photo it does not already hold shows as a placeholder tile until you are back online.

Three things need outside help, and they are the only reasons anything leaves. Two of them — holding a conversation with Sous (typed, spoken, or while you cook) and understanding a photograph — genuinely cannot be done on the phone: they need models too large to live in an app. The third, importing a recipe from a link, goes through our server so the website sees a request from us rather than from your phone, and a model is involved only when the page carries no machine-readable recipe.

Beyond fetching recipe photos (described below), nothing leaves until you use one of them. When you do, the request goes to our own server first (it holds the vendor keys so the app doesn't have to), and from there to the provider doing the work. Our server holds each request in memory only for as long as it takes to answer it; the little that outlives a request — its logs, and a per-install pseudonym — is under "Do you keep any of it?" below.

When you ask Sous a question (typing): your question, your pantry as a list of ingredient names, your plan as dish names and dates, and a stripped summary of your household — how many people, and the combined set of allergies and diets present among them — go to our server and then to Anthropic (the company behind the Claude models) to compose the answer. The summary is deliberately blank about who is who: every member is reduced to "Member 1", "Member 2", with the identical combined allergy list, so there is no per-person record to accumulate anywhere. When Sous's reply mentions "Member 2", your phone swaps the real name back in before you see it; the name itself never travelled. A few kitchen facts (your appliance list, time budget, priorities, avoided cuisines) ride along to our server but are not put into the prompt, so they stop there. Each question is self-contained — no conversation history is kept or re-sent on the text path.

When you cook with the assistant: the cook session — the recipe steps, titles, timers and scaled ingredient lines of the dishes you are cooking — goes to our server and then to Anthropic on each turn. For a recipe you imported yourself, this is where its text leaves your phone — this, and a voice session opened while you cook, which reads the same steps and amounts so Sous can speak them (see the voice section below).

When you photograph your fridge, a dish, or a recipe: see the photo section below.

When you import a recipe from a link: the link goes to our server, which fetches the page on your behalf — so the website sees a request from our server, not from your phone. If the page carries no machine-readable recipe, its text is sent to Anthropic to extract one. For TikTok links, the video's public caption is fetched through TikTok's own embed service.

When you talk to Sous: see the voice section below.

When you browse recipes: the catalog's dish photos are not packed into the app. Your phone fetches each one directly from the image library that hosts it — Unsplash, Pexels, Flickr or Wikimedia — when you look at a recipe, and the current plan's photos ahead of time, as described above. As with any image on any web page, the host sees your IP address and which photos your phone asked for, and nothing else: no name, no household, nothing you typed. Photos are cached on the device after the first fetch, and none of this touches our server.

Who each provider is — each name links to its privacy policy, which governs what it keeps: our relay server runs on Fly.io; Anthropic composes Sous's answers and reads photos; Deepgram turns your speech into text; LiveKit carries the voice call, and its inference service runs the xAI (Grok) voice that speaks Sous's replies; recipe photos come straight from the image libraries that host them, as above. That is the complete list. A grocery-ordering integration (Kroger) exists in the code but is switched off, and no shipped build can switch it on.

Who can hear my kitchen, and when?

The microphone is off until you tap the microphone button. Tapping it asks iOS for permission, then opens a live voice session. While that session is open:

• Deepgram receives your raw audio, continuously, to turn speech into text. We set Deepgram's model-improvement opt-out on every request, so your audio is not used to train their models. An opt-out is not the same as zero retention — Deepgram's own retention policy governs how long they hold audio.
• LiveKit carries the call, so it handles the audio in both directions, the live transcripts, and the data the assistant requests mid-call — your full pantry list when you ask what you have, the steps and ingredient amounts of the dish you are cooking, or what this week's plan still needs bought. Our session tokens grant no recording permission (this is pinned by an automated test), and LiveKit's own session-capture feature is switched off on our project.
• Anthropic receives the conversation transcript to decide what Sous says. Unlike the text path, a voice conversation re-sends what was said so far on each turn — so if you speak a name aloud, it stays in that session's transcript. The app never sends a name; it cannot un-say one you speak.
• xAI (Grok), reached through LiveKit's inference service, receives the text of each reply to synthesize the voice you hear.

The session ends — and all of that stops — when you tap the microphone off, when you leave the screen you started it on (with about a second and a half of grace so Sous can finish her sentence), when the assistant drops, or when the app leaves the foreground: Table requests no background-audio capability, so iOS cuts its microphone access when it is not the app in front of you. Muting stops your audio from being transmitted; on current builds it also shuts off the microphone hardware, and iOS's own orange-dot indicator is the honest signal either way.

One more voice fact worth knowing: the read-aloud toggle on the Ask screen is different — it uses your iPhone's built-in speech, on the device, so a reply containing a real name can be spoken without anything crossing the network.

What happens to a photo of my fridge?

When you photograph your fridge, pantry, a dish, or a recipe page, the photo goes to our server, which converts its format in memory if needed and passes it to Anthropic, whose model reads it. Our server never writes the photo to disk and keeps no copy; its logs record that a photo call happened and how large it was, not the image. Today we have nowhere to keep your photo, and we don't.

Anthropic holds it under its own API data policies — Anthropic does not train on API data by default, and its retention terms, not ours, govern how long the photo exists there. A photo of your fridge is a photo of the inside of your home; if you are not comfortable with it crossing the network, type the items in instead — every photo feature has a typed alternative.

Do you keep any of it?

Almost nothing, and nothing that is about you. Our server keeps no database of people, no accounts, and no profile. Three things outlive a request, and only the third is anything you typed:

• Server logs. Our server logs that a request happened: which feature, when, how large and how long it took. The logs carry no identifier for you or your phone — no name, no account, and not the install pseudonym below. When you import a recipe by link, the link itself is logged. When a request fails unexpectedly, the raw error is logged, and a provider's error message can quote fragments of what was being processed. That is the one path by which request content can reach a log. Logs are otherwise text about requests, never the requests themselves: no photos, no audio, no names. They are held by our hosting provider for 7 days — Fly's default — and we have added nothing that would extend it.
• The install pseudonym. On first launch the app makes up a random ID for itself (it looks like inst_…) and sends it with each request so our server can rate-limit one phone without throttling everyone else. It is not your name, is connected to no account, and cannot be resolved to a person. The server holds it only in memory, for the rate limit, and never writes it to a log or to disk; it is gone whenever the server restarts. It is not passed to the companies that carry a voice conversation — each conversation is given its own one-time ID instead. Deleting the app destroys the pseudonym; a reinstall gets a fresh one.
• Ingredient names you choose to send. In Settings, Table lists the items from your pantry and your own recipes that it does not recognize, and offers to send them so they can be considered for the catalog. Nothing is sent unless you tap the button, and you can uncheck any item first. What we keep is the words themselves, a count of how many people have sent that same word, and the date it was first seen — nothing about you, your phone, or your install. The pseudonym above is not attached, and there is no way to read the list back out of the server. It is capped at 2,000 distinct names; past that, new ones are discarded rather than stored. A seized disk would yield a list of ingredient names and their tallies, attributed to nobody.

That third item is a per-tap send, not a setting: there is nothing switched on to leave on, and nothing happens on its own. Anything ongoing would be a switch in Settings, opt-in and off until you turn it on. The switches we can foresee asking for, and the rules that bind every one of them, are under "If Table ever collects more", below. Until you turn one on, the three items above are the whole of what outlives a request, and nothing else is collected. In particular Table sends no usage analytics: the app contains the instrumentation and it is compiled to do nothing, so no screen views, session lengths or feature counts leave your phone at all.

What our providers keep is governed by their policies, not ours. We have set every no-training and no-logging switch those services offer, but we do not control how long they hold what we send, and their terms change without us. Rather than restate numbers here that could go stale, each provider's name in the one-line list under "What leaves my phone, and who gets it?" links to its policy; what each one receives is described at the flow that sends it.

What never leaves my phone?

Under any configuration of today's app, it never sends any of these. What you type or speak yourself is content, and travels as you said it; where a future opt-in switch could change an entry, the entry says so:

• Real names, and the map that connects "Member 2" back to a person
• Who has which allergy — only the combined, unattributed set leaves
• Age bands, dislikes, and favorite cuisines
• Your ZIP code and your health goal
• Your cook log, streak, declined meals and collections — the lists themselves. The planning switch under "If Table ever collects more", below, would send tallies drawn from them, never the lists
• The on-device correction log — capped, local, and uploaded nowhere today; only the fridge-reading switch described there could ever ask for it

What about my shopping list and Reminders?

Table can put your shopping list into Apple Reminders, so you can tick items off in the shop. This only happens when you tap Export, and it writes into exactly one list. Which list is either the one you picked in Settings, or — if you chose "Let the app decide" — an existing list of yours named Groceries, Grocery, Shopping or Table, and failing all of those, a list called Table that it creates. Settings always shows you which list it will use.

No server of ours is involved. The list is written straight into Reminders on your phone. But it does not stay there: Reminders syncs through your own iCloud account, and to anyone you have shared that list with. For a shopping list that is usually the point — a partner picking things up on the way home — and it is still the one thing in this app that leaves your device by an ordinary route rather than staying put. What travels is item names and quantities. Nothing about your household, your allergies, or your plan goes with it.

Table also reads, and it is worth saying exactly how much. Two things: the NAMES of your reminders lists, so Settings can show you a list to pick; and the items inside that one list, so that exporting twice does not put everything in twice. Table does not read your other reminders. iPhone does not offer an app permission for reminders that is write-only, so the permission you grant is broader than what Table uses — which is exactly why this paragraph exists.

Table never deletes or edits a reminder. It only ever adds, and it keeps a private note of what it has already added so it does not add it again. If you tick something off, rename it, or delete it, that is yours and Table leaves it alone.

What about my child's allergy?

Table is built for a household, and household members are often children. Their information is entered by whoever set the phone up — the app has no child-facing sign-up, no accounts, no messaging and no ads. A child's name, age band and personal allergy record stay on the phone, full stop. What leaves, when you use Sous, is the household's combined allergy list with no name or age attached — because a dinner suggestion that ignores an allergy is unsafe, and one that names your child is a disclosure. The allergy verdicts you see in the app ("contains peanut — not safe for Mia") are computed by rule-based code on the phone; no AI model and no server is asked to make a safety call about a named person.

A guardian gate, on by default in Settings, requires an extra confirmation before actions that leave the app — ordering link-outs and grocery sign-ins — so a teenager cooking alone can use the kitchen features without reaching the parts that spend money or leave the sandbox.

Do you track me?

No. There are no ads, no third-party analytics, no tracking SDKs and no crash reporting in the app you are running. Nothing about your usage — which screens you open, what you cook, how often — is reported to us or to anyone. The analytics layer in the code is switched to "do nothing", and no shipping build contains a vendor that could receive an event. We cannot see how you use Table.

If Table ever collects more

Three switches we can foresee asking for, and one business model. None of them exists today, and nothing here is a plan with a date on it — it is the shape of what we would and would not do. Whatever arrives, this page says so, dated, before it starts — not after — and two rules bind everything below.

Opt-in, and off until you turn it on. Not on-by-default with a switch to find; not a prompt worded so that yes is the easy answer. Turning a switch off stops its collection from that moment, and if you never open Settings, nothing in this section ever happens to you.

We do not sell your data, and we would not. Not to brokers, not to advertisers, and not as an "anonymized" dataset — because removing the names does not make data of this shape anonymous. A household's allergies and a fortnight of dinners are close to a fingerprint, and data much like them has been re-identified before by matching it against something public. Methods that carry a real mathematical guarantee do exist, and they are not what that word usually means; if we ever used one, we would name it and say what it promises. Selling is ruled out even then. What a switch shares is for making the app work better and for nothing else: not for advertising, and not for building a profile of your household.

Reading your fridge better — the fridge-reading switch. The shelf reader improves by learning from where it was wrong, and your corrections are already written down on your phone: the app read "oat milk", you changed it to yogurt. This switch would share three fields — the text the app was working from, what it guessed, and what you picked — the last two hundred of them, newest first. That log would be the whole ask: nothing else from the confirm card, and no picture — the photograph is not part of it and never leaves your phone. What you shared, we delete on request; there is no account to hunt through, and the log is capped and self-clearing either way — the oldest entries drop off, and deleting the app destroys it.

Photographs would be a separate question with its own switch. If keeping the images ever proved necessary, it would be asked for on its own terms — never folded into a general "help improve Table" toggle.

Planning better weeks — the planning switch. The weeks the app suggests only get better if we learn which of the catalog's recipes households cook again and which they throw out, and today we cannot see either. Your phone already keeps that score; this switch would send the score, not the diary: how the catalog's dishes fare — rated what, declined for which of a fixed list of reasons — plus which meal slots get swapped, how long screens and sessions stay open, and counts of feature use. By construction it can carry no free text, no photo, no name, never which allergy or whose, no pantry contents, and no recipe you wrote or imported: the reporting code cannot name a dish unless the shipped catalog contains it. We do not call this "anonymized" — the rule above says why that word is not on offer. It is thin instead: dish names and tallies, useful added up across everyone who turned the switch on, and collected from no one by default.

A free tier may one day carry advertising, and it would not be targeted at you. Ads would be chosen by what is on the screen — a recipe, an ingredient — and not by who you are or what we know about you. Nothing this app holds would be used to aim them: not your allergies or your family's, not your photographs, not your voice or anything said in your kitchen, not your pantry, not what you cook, not your children's data. Those exist so the app can cook with you safely. That rules out behavioral advertising and the ad networks built on it, which is the practical meaning of this promise rather than a caveat to it.

If advertising ever involved tracking you across other companies' apps and sites, iOS would ask you first. That is Apple's App Tracking Transparency prompt, it is not ours to skip, and "allow" would be a real question with a real "no".

Can I delete it?

Yes, completely, yourself: delete the app. Everything it knows — household, plan, pantry, recipes, cook log, corrections, any recipe shared into it and its install pseudonym — lives in the app's own storage and its share container, and iOS removes all of it with the app. There is no account to close and no server-side record of you for us to delete; our log lines age out on their own. Copies held by providers (a photo at Anthropic, audio at Deepgram) are subject to their retention policies; if you want help chasing one, contact us and we will make the request to the vendor on your behalf.

Note that "Run setup again" in Settings replays the questions but keeps your data — deletion is deleting the app.

Changes to this policy

The current policy always lives at this address. When the app's data flows change, this text changes in the same release, and the effective date below moves. If a change means something new leaves your phone, we will say so in that release's notes rather than only editing this page quietly.

Contact

Table is built by an independent developer. Questions, concerns, or deletion requests: hello@table-community.com.

Effective 4 September 2026.