Recipe Grab Privacy Policy

Effective date: August 12, 2026 App: Recipe Grab (iOS) Website: https://recipegrab.app Publisher: Recipe Grab is built by Hey Labs, an independent studio that designs and ships polished iPhone apps. Contact: contact@heylabs.co

This Privacy Policy explains what data Recipe Grab handles, where it lives, when it becomes public, and the controls you have. It draws a hard line between your private recipe library, which stays on your device, and the things you publish or share with other people, which do not.

1. Who we are

Recipe Grab is an iOS application that turns short cooking videos, recipe websites, photos of cookbooks or handwritten cards, and pasted text into structured recipes you can organise, cook from, and add to a grocery list.

Recipe Grab is published by Global Reach Retailers LLC, a Wyoming limited liability company with its registered office at 30 N Gould St #40636, Sheridan, WY 82801, United States (the "Company", "we", "us"). For privacy questions or requests, write to contact@heylabs.co.

When you buy a subscription, Apple processes the payment under Apple's privacy terms. We receive an App Store transaction record, not your card details.

2. The short version

Your recipe library lives on your iPhone and, unless you switch iCloud sync off in Settings, in your private iCloud container. We do not keep a server-side mirror of that library.
The app creates an account for you on first launch, before you sign in to anything. It holds an internal ID, a generated handle, and a profile. Signing in with Apple attaches that account to your Apple ID so it survives a new phone.
A new profile starts out public, and auto-publish starts out on. Before a single recipe is published, the app shows you what that means. Declining there hides your page; auto-publish is a separate switch. Both live in Settings and can be turned off at any time.
When auto-publish is on, each recipe you save is published as a public page: its ingredients, its steps, and a link back to the source. Your photos, your notes, your grocery list, and your meal plan are never part of it.
Public profiles and published recipes are meant to be found. Search engines can index them.
A shared shopping list is shared: everyone on it sees the items, the notes, and the names of the other members.
We never receive your email address from Apple. The app asks for no scopes when you sign in, so neither your real address nor a private-relay address reaches us. We only ever hold an email if you type one in yourself: on the Android waiting list on our website, or in the optional contact field when you report content.
We do not use IDFA, show third-party advertising, sell personal data, or track you across other companies' apps and websites.

3. Your account and your public identity

3.1 An account exists from first launch

Recipe Grab provisions an account for your installation the first time the app talks to our server, without asking you to sign in. It carries an internal account ID, a generated handle of the amber-fennel kind, a display name, and a profile record. This is what makes publishing, sharing, referrals, and shared lists work at all.

Signing in with Apple links that existing account to your Apple ID, so it survives reinstalling the app or moving to a new phone. It does not create a second account and does not discard what the guest account already accumulated.

We store:

the internal account ID and its lifecycle status;
the installation record, identified by a digest of a random secret the app generates on your device (not your IDFV, not your Apple ID);
for a signed-in account, a keyed one-way digest of the stable subject identifier the sign-in provider gives us, plus that provider's refresh token in encrypted form;
session tokens as digests, along with the security metadata needed to authenticate requests, detect replay, and revoke sessions;
your handle, and a digest of any handle you retire, so a retired handle cannot be silently claimed by someone else;
profile fields you fill in: display name, biography, avatar.

We do not receive or store your email address. The app asks Apple for no scopes at all when you sign in, so neither your real address nor an Apple private-relay address ever reaches us. We do not use an email address to merge sign-in identities, because we do not have one. We never see your provider password.

There are two places where we do hold an email address, both because you typed it in. If you join the Android waiting list on our website, we keep that address, together with a salted hash of your IP address, your browser's user-agent, and the hostname of the site that sent you, but not the page or its query. That row has no automatic expiry today, partly because the per-address rate limit counts those rows; write to us if you want it removed. If you fill in the optional contact field when reporting content, that address travels with the report, including into the messaging tool our operators read reports in.

Without signing in, a guest account can save, import, cook, and publish, but cannot change its handle, set an avatar or biography, or take part in shared lists.

3.2 Your profile is public by default

A new profile is created with visibility set to public. A public profile shows your handle, display name, biography, avatar, favourite ingredients and dishes, your published recipes, and public counts. Anyone can open it without an account from the moment the account exists, before you have published anything. We ask search engines not to list a profile until it has at least one publication; after that, the page is meant to be found.

You can hide the profile in Settings → Account. While it is hidden, nobody else can open it and your published recipes are not listed on it.

Treat every public profile field as public. Do not put anything in a display name, biography, or avatar that you would not want a stranger, an employer, or a search engine to see. Avatars are served from public storage without a signed URL, so anyone holding the address can fetch the image. The app re-encodes an avatar on your device before uploading it, which drops the embedded metadata a camera writes, including any location; our server does not re-check that, so the protection is the app's, not the server's.

4. Your private library and import processing

4.1 Content you create or import

Private-library content includes recipe URLs, pasted text, selected photos or videos, titles, ingredients, steps, your notes, scaling changes, grocery items, allergen flags, and meal-planner entries.

It lives:

on your device, in the app's local store;
in your private iCloud container, which is on unless you turn iCloud sync off in Settings. What syncs is the whole recipe: title, ingredients, steps, your notes, the source and video URLs, the transcript we extracted it from, and your meal-planner entries with their notes. It is governed by Apple's terms and we have no operator access to it. Separately, and outside that switch, iOS key-value sync carries your allergen list and a couple of counters between your own devices;
briefly in transit through our server and its processors when a feature needs server-side import, transcription, extraction, estimation, refinement, or feedback handling.

Your shopping lists are different. A personal list stays in a local store on the device. A shared list lives on our server, because that is what makes it shared; see Section 6.

4.2 What is sent for the feature you asked for

Action	What is sent	What happens to it
Import from a public video URL	The URL, a request ID, and device-attestation material	We fetch the public source or its captions through a transcript provider, extract a recipe, and return it
Import from a recipe website	The rendered page, plus the URL and a request ID	Your device usually loads the page itself, in a hidden web view with its own cookie store, separate from Safari, and sends us the result. That means the site sees your home network address and any cookies the app has built up with it. If that fails, our server fetches the page instead, and then the site sees our server rather than you. Either way we extract the recipe and return it
Import a recipe photo	The image bytes, a request ID, attestation material	A vision model extracts the recipe; the image is discarded after processing
Transcribe a video the device cannot handle locally	The video file itself, up to 50 MB, with request metadata. We do not strip the picture first	We pass the file to a speech-to-text provider, return the transcript, and discard the file after processing
Server-side estimate, or an AI refinement you request	Recipe-scoped title, ingredients, steps, and any transcript excerpt needed	One tap can fan out into several model calls in parallel, each looking at a different part of the recipe, and each may be retried. Results are merged and returned
Voice Chef session start	Recipe title, the current step in full, section title, up to twenty ingredient lines with their quantities, persona choice	We mint a realtime key carrying that context. Your microphone audio then streams directly to the realtime provider and does not pass through our server. Establishing that connection uses a public address-discovery server run by Google, which sees your device's public network address
Report a problem	Your comment, plus the context the feedback screen collects: the recipe as we extracted it, the source URL, an excerpt of the source transcript, recent entries from the app's own log, your device model, and app and OS versions	We read it and use it to fix the bug. Reports are kept on our server while they are useful to us; write to us if you want one removed

4.3 Caches, queues, and operational logs

To make imports reliable and avoid paying twice for the same work, we hold:

transcripts, public captions, and extraction metadata for up to 24 hours;
the extracted result for a recipe website, keyed by its address, for up to 7 days;
output extracted from an image for up to 1 hour;
the full result of an extraction job, including any video frames it used, for up to 24 hours;
a completed import in a delivery queue keyed to your device for up to 7 days, so an extraction that finished while iOS had suspended the app is not lost;
extraction artefacts, which can include a verbatim transcript, the source address, and a fragment of your device's vendor identifier, for up to 14 days;
a record of links we refused to import, with the address and a fragment of your device's vendor identifier, for up to 14 days, so we can see what is breaking;
the name of a dish we could not classify, so we can extend the catalogue.

Diagnostic logs carry request IDs, destination hostnames, truncated URL digests, response status, and rate-limit metadata. They are held for operational troubleshooting and rotated as our hosting requires rather than on a fixed published schedule.

About IP addresses, precisely. We do not store your IP address in our main database against your account. Rate limiting does use it: most limiters key a short-lived counter on a truncated hash of the address, and three, covering share-page views and abuse reports, key it on the address itself, held in our cache layer for five minutes in one case and an hour in the other two. A truncated hash of the address can also appear in operational logs and alerts. The Android waiting list stores a hashed address for as long as the entry lives. Our edge and security provider terminates TLS for all API traffic and processes IP and user-agent data to deliver and protect the service under its own terms.

5. Publishing, and what becomes public

5.1 Auto-publish

Auto-publish is on by default for a new account. Before the first recipe is ever published, the app shows you a disclosure explaining that your page is public, that every recipe you save goes on it, and what does and does not appear there. Nothing is published until you have seen that disclosure and continued past it.

Choosing "Keep my recipes private" on that screen hides your profile, which stops everything from being served. Worth knowing: it hides the page rather than switching auto-publish off, and the two settings are separate. If you later make the profile public again, publishing resumes unless you also turn auto-publish off in Settings → Account.

When a recipe is published we store and serve a public functional projection: its title, ingredient list, steps, serving, time, cuisine and nutrition fields where available, the source URL, and attribution. Titles and steps may be paraphrased. Ingredient lines are not paraphrased, they are kept and normalised, because a paraphrased ingredient is a food-safety problem rather than a copyright improvement.

Never part of a publication: your private notes, your grocery list, your meal plan, your photos, your transcripts, and every recipe you did not publish.

5.2 Where published recipes appear

A published recipe lives at recipegrab.app/u/<handle>/r/<slug>, with the shorter recipegrab.app/r/<slug> redirecting to it, and appears on your profile page and on our dish and ingredient pages. Each card carries the handle and display name of its author; the recipe's own page also shows the address of the original video or page it came from, so a visitor can see which sources you import from.

Indexing works like this. Individual recipe pages carry a noindex directive today, so search engines are asked not to list them on their own. Everything around them is meant to be found: your profile page, our dish pages, and our ingredient pages are in our sitemap and can appear in search results, social previews, and third-party caches, each showing your handle, display name, and recipe cards. Our home page and its Explore section also list cooks and recent publications by handle, name, and avatar.

We generate a social preview image for your profile, showing your handle, display name, and how many recipes you have published, so a link to your page unfurls with those details on any platform that fetches it.

We also expose a directory of every profile that has at least one publication. It is readable without an account, so handles and display names are enumerable by anyone. Public responses about a publication include the internal identifier of its author's account alongside the handle.

5.3 Cookbooks and legacy share links

A shared cookbook page holds a stable code, title, cover, timestamps, your handle and display name, and an ordered list of references to recipes you have already published. We do not store a second copy of each recipe for it. The cookbook page itself shows each recipe as a card with counts rather than its full text, but the public interface behind that page returns the complete ingredients and steps of every recipe in the collection to anyone who asks it, without an account. Sharing a cookbook that contains unpublished recipes asks for your consent and publishes them first, which is a second, separate route to publishing.

A legacy share link is a separate, older mechanism that predates accounts: a random short code under the same /r/ path, public to anyone holding the link, excluded from our sitemap, and not tied to your profile. It stores the published recipe copy, the code, timestamps, a one-way device-ownership digest, and aggregate view state.

5.4 Stopping publication

In the app you can turn auto-publish off, hide your profile, stop sharing a cookbook, and revoke a legacy share link. Hiding the profile takes every recipe you published off public view at once.

Two limitations, stated plainly.

Retiring one individual publication while keeping the rest of your page public is not something the current app version can do on its own. Write to us at contact@heylabs.co with the address of the page and we will retire it. A retired publication stops being served permanently; limited tombstone, command, and audit records remain so its address cannot be silently reused.

Legacy /r/<code> share pages are stored separately from your account, and deleting your account does not currently remove them. If you have created legacy share links and want them gone, revoke them in the app before deleting the account, or write to us.

5.5 Reports and removal

A report about hosted content reaches our operators through a third-party messaging service, and that message carries what the reporter wrote and any contact details they gave. On our own servers we keep only a minimal record of the report: which surface, which page, and the reason chosen. Reports about an avatar are the exception and do get a stored record with a review state. We may hide or remove a profile, recipe, avatar, or cookbook to comply with law, answer a valid copyright complaint, enforce our Terms, or protect people.

6. Shared shopping lists

A shared list is one list that several people write to. When you create or join one, our server holds the list title, its members, and every item on it: the product name, quantity, brand, and any note, in the words whoever typed them used.

What other members see: every item, quantity, brand, and note on the list, and who else is on it, including each member's handle, display name, and internal account identifier. What they do not see: your library, your allergens, or anything outside that list.

Alongside the items we keep the bookkeeping that makes a shared list converge on several phones at once: per-item state and revision, who added or changed what and when, and an audit record of each change request.

Invitations work two ways. You can invite a specific person by handle, which requires being signed in and searches public profile fields only. You can also create an invite link, and anyone holding that link can read the list's name, how many members it has, and, if the inviter's profile is public, their handle and display name, without signing in. Withdraw an invitation before it is accepted if you sent it by mistake.

Two limitations worth knowing. Items and contributions on a shared list are not deleted when you delete your account, because the list belongs to everyone on it and removing one person's entries would corrupt what the others are shopping from. Ownership of a list you created transfers to its longest-standing member; if you were alone on it, the list is deleted with your account.

7. Referrals, rewards, and subscriptions

When you open an invite, a public recipe, or a cookbook link, we may record a time-limited attribution touch: the referring account, an opaque identifier for the visitor, the channel, timestamps, and settlement state. It exists to credit a friend or a creator once and to stop the same reward being claimed twice. This is first-party product attribution, not cross-company advertising tracking.

We record qualifying events that decide whether a referral pays out, the resulting reward grants, and any request you make to redeem a reward.

For subscriptions we hold the provider subscription identifier, the coverage periods it grants, and a digest of each notification we receive, so we can tell whether your account is entitled to paid features. Deleting your account detaches the subscription record from you but does not delete it, because we need it to reconcile billing with Apple.

We also record product events tied to your account, such as a recipe being opened, saved, planned, or cooked, to operate features like referral qualification and to understand what the product is used for.

8. Allergens, diets, and other preferences

If you set allergens, in onboarding or in Settings, or answer the dietary question during onboarding, we store those answers against your account so they can drive filtering and warnings across your devices.

We treat this as sensitive information. It is used to run the features you enabled, never to advertise to you or to build a profile for anyone else. It is not shown on your public profile. Favourite ingredients and dishes are a different thing entirely: those are shown publicly on your profile, which is the point of them.

Deleting your account deletes your stored allergens and dietary preferences from our servers outright. Your allergen list also rides Apple's key-value sync between your own devices, and that copy is yours: it lives in your Apple account and is not removed by deleting the server account.

9. Diagnostics, analytics, permissions

9.1 Diagnostics and analytics

Crash reporting. Configured to send no personally identifying data: no user identifier, no screenshots, no view hierarchies, no network breadcrumbs. On top of that we strip the payload before it leaves the device, blanking request, user and context data, replacing exception text, and removing file names, source lines, and local variables from every stack frame.

Product analytics. Identified by a random per-install identifier that is not your IDFV. We disable IDFV, IP address, carrier, city, region, and metro-area collection, and session replay is off. Events are typed, with values limited to enumerations, counters, and buckets. They carry no recipe text, ingredients, or transcripts. Three values are not from a fixed list: the hostname of a recipe website when we record whether fetching it succeeded, an error message truncated to 200 characters when extraction falls back, and the name of whichever paywall was shown. Your allergens and dietary answers are deliberately excluded from analytics and go only to your account.

Paywall presentation. This one is not anonymous, and you should know it. Our paywall provider is given your account identifier, and, once you have a handle, your public handle and the address of your public profile, so purchases and paywall assignments follow the right account. The provider's own SDK additionally collects your device's vendor identifier (IDFV) and network address for its own attribution matching, under its terms.

Pipeline-degradation telemetry carries a stage tag, severity, an error code, an opaque hashed recipe ID, app version and build, a random per-install UUID, and a details object describing what failed, which can include the hostname of the source. It is sent over an authenticated connection, so it is associated with your installation rather than being wholly anonymous. Unresolved-ingredient telemetry carries an ingredient term, its language, and its cuisine, so we can extend the ingredient catalogue.

Onboarding answers. The questions you tap during onboarding are recorded so we can see which answers lead to people staying, and they reach our analytics and paywall providers. Our own record of them uses a random per-install identifier, but the paywall provider knows your account identifier, so there they are tied to your account.

Two answers, your allergens and your dietary preference, are held back from everything our app sends onward and go only to your account. One caveat we would rather state than hide: those questions are presented on screens hosted by the paywall provider, so the answer reaches that provider first, before our app sees it. See Section 8.

9.2 Permissions

Camera and photo library: only for content you pick to import. Selected images are processed as described in Section 4.
iCloud: controlled by you in iOS Settings.
Notifications: cooking Live Activities and timer alerts, a message when an import finishes, meal-planner reminders, shared-list invitations, and referral updates. Not marketing. Push notifications we send from our server deliberately carry no recipe title or address; a meal-planner reminder scheduled by the app on your own device does name the recipe, because it never leaves the phone.
Microphone: used by Voice Chef, where audio streams straight to the realtime provider, stops when you end, leave, or background the session, and is not recorded by us; and by Live Recipe, where you dictate a recipe.
Speech recognition: for dictating a recipe. We ask iOS to keep recognition on the device and it does so where the device supports it. Where it does not, iOS sends that audio to Apple's speech servers under Apple's terms.

Recipe Grab does not request contacts, calendars, HealthKit data, location, motion, or Bluetooth. There is no HealthKit integration in this version, and no ATT prompt, because we do not track you.

9.3 Device attestation

Two endpoints ask your device to prove it is a real installation using Apple DeviceCheck: issuing the capability that lets the share extension upload, and publishing a recipe. The app obtains a token from iOS, our server asks Apple to validate it, and we keep the answer only for the length of that request. The token is cached on your device for a few minutes so we do not mint one per call. We do not use DeviceCheck's per-device bits and do not store the token on our servers. On publishing, the check currently only records its verdict rather than blocking.

If a video upload is rejected as unauthenticated, the retry carries an App Attest assertion generated on your device. Our server records it and does not act on it.

10. Why we process data

For people covered by the GDPR or similar laws, our principal lawful bases are:

Purpose	Basis
Run an import, an account, a save, Voice Chef, a purchase, or another feature you asked for	Performance of our contract with you
Provision an account at first launch so publishing, sharing, and referrals can work	Contract, and our legitimate interest in a working service; you can hide the profile and disable publishing
Authenticate accounts, secure sessions, prevent replay and abuse, keep audit records	Contract, and legitimate interests in service security
Host a public profile, publication, or cookbook after your publishing choice	Contract; you control publication and can reverse it
Store allergens and dietary preferences	Your explicit consent, given when you set them
Operate shared lists among their members	Contract with each member
Record referral touches and settle a reward	Contract, and legitimate interests in operating the programme and preventing abuse
Diagnose crashes and understand typed feature usage	Legitimate interests in reliability and product improvement, with minimised data
Answer copyright, safety, fraud, and legal requests	Legal obligation, and legitimate interests

We do not sell personal data, share it for cross-context behavioural advertising, or use your content to train our own general-purpose AI model.

11. Service providers

Running Recipe Grab means sending parts of what you import to specialist providers. Grouped by role:

Role	What reaches them
Apple (App Store, StoreKit, iCloud, APNs, DeviceCheck, Sign in with Apple)	Transaction records, your private iCloud container, push tokens, attestation validation, a stable subject identifier
AI providers (extraction, vision, estimation, refinement, paraphrasing, realtime voice)	Transcripts, page text, pasted text, recipe bodies, video frames, whole photos you import, whole short videos, and the recipe context for a Voice Chef session
Speech-to-text providers	The video file your device could not transcribe, picture included. If the first provider fails we try the next, so the same file can reach more than one of them
Transcript and page providers	The public URL you asked us to import
Hosting, edge delivery, DDoS protection, object storage	All API traffic, which means our edge provider terminates TLS and can see request bodies; avatars and public assets are stored in object storage
Crash reporting and product analytics	A random install identifier, typed events, heavily redacted diagnostics. Analytics libraries we depend on bring further vendor code into the app that we do not configure or send data to
Address-discovery (STUN) server	During a Voice Chef call only, your device's public network address
Paywall presentation	Your account identifier, your public handle and profile address, plus the IDFV and network address the provider's own SDK collects
Operator messaging	Content reports, including the reporting person's text and contact details

Each processes data for its role, under its terms and our instructions. A current list of named subprocessors is available from contact@heylabs.co.

Our servers are operated in Europe. Several providers process data in the United States and other countries; where required, those transfers rely on appropriate safeguards such as Standard Contractual Clauses.

12. Retention and deletion

Your private library stays on your device and in your iCloud until you remove it. Deleting your server account does not touch your iCloud library, and deleting the app does not delete your server account. Handle each one where it lives.
Account, profile, authentication, and service state are kept while the account exists.
Published recipes, public profiles, and cookbooks are served until you unpublish, hide, or delete them, or we remove them. Search-engine and intermediary caches are outside our control and lag behind removal.
Import caches and queues expire on the schedule in Section 4.3.
A digest of a retired handle is kept permanently so the handle cannot be quietly reassigned.
Feedback you send us is kept on our server while it is useful for fixing the bug it describes. There is no automatic expiry today; write to us if you want a report removed.
Crash reports, analytics, and telemetry follow each provider's configured retention.
Backups. We take snapshots of our cache layer into object storage and keep them no longer than 14 days. Data can survive in a snapshot after deletion until that window passes; it is not restored into active service afterwards.

Deleting your account. Settings → Account → Delete account. For a signed-in account we ask you to re-authenticate first. Sessions are revoked and public content is pulled from serving as soon as the request is admitted; physical erasure runs on a 30-day schedule. Deletion removes your profile, handle, publications and their paraphrases, cookbook collections, allergens and dietary preferences, messages, referral codes and touches, product events, sessions and sign-in links, and the account record itself.

Some things survive deletion on purpose, and you should know which:

subscription records and coverage periods, detached from you, so billing reconciles with Apple;
items, quantities, and change history you contributed to a shared list, because the list belongs to the people still on it; a list you owned passes to its longest-standing member;
a digest of your retired handle, so nobody can quietly take it;
legacy /r/ share pages, stored outside the account, which must be revoked separately as Section 5.4 explains;
bookkeeping records: proof that the erasure happened, tombstones and command records that stop a retired address being reused, request-deduplication rows, the record of any avatar report you filed, subscription notification receipts, and referral receipts;
copies already delivered elsewhere, such as a report that reached our operators through a messaging tool.

Your avatar image stops being linked from your profile immediately, but the file itself is removed when erasure runs rather than the moment the request is admitted.

13. Your rights

Depending on where you live, you may have rights to access, correct, export, delete, restrict, or object to processing, and to withdraw consent where consent is the basis.

Export. The app can share an individual recipe as text. A bulk export of your library, and the in-app button for your server-held account data, are not shipped yet; write to contact@heylabs.co and we will send you a copy of what your account holds.
Deletion. Settings → Account → Delete account, as described above.
Correction. Edit your profile in the app; write to us for anything you cannot reach.
Objection and restriction. Hide your profile, turn off auto-publish, leave a shared list, or write to us. Retiring one publication while keeping the rest public goes through us, as Section 5.4 explains.
Withdrawing consent to allergen and dietary storage: clear those fields in the app.

We may need to verify that you control the account, device, or content in question before acting. We will not ask for more than that requires.

California residents: we do not sell personal information or share it for cross-context behavioural advertising.

EEA and UK residents: you may lodge a complaint with your local data-protection authority.

14. Children

Recipe Grab is not directed to children under 13, or the equivalent minimum age where they live, and we do not knowingly collect personal information from them. Contact us if you believe a child has supplied personal information, and we will delete it.

15. Security

Traffic is encrypted in transit. Provider identifiers are stored as keyed digests, provider refresh tokens are encrypted at rest, sessions are short-lived and revocable, and requests carry replay protection and rate limits, with Apple DeviceCheck on the two endpoints described in Section 9.3.

Publishing routes are public by design. Never publish something you want to keep private. No system is perfectly secure. Report a vulnerability to contact@heylabs.co with the subject "Security · Recipe Grab".

16. Changes and contact

If we materially change how Recipe Grab handles data, we will update this page and, where it matters, tell you in the app. The effective date at the top identifies this version.

Global Reach Retailers LLC, 30 N Gould St #40636, Sheridan, WY 82801, United States.

contact@heylabs.co

Apple App Privacy disclosure summary

A plain-language summary to support the App Store Connect disclosure. Apple's own definitions control the live App Privacy label.

Data used to track you

None. Recipe Grab does not track as App Tracking Transparency defines it and shows no ATT prompt.

Data linked to you

Identifiers: internal account ID, a digest of the sign-in provider's subject identifier, installation and session linkage.
User content: public profile fields, published recipes and their source attribution, cookbook metadata, shared shopping list items and notes, feedback you submit.
Sensitive info: allergens and dietary preferences you choose to store.
Usage data: product events such as a recipe opened, saved, planned or cooked; publication and save commands; referral and attribution state; account security events.
Purchases: subscription state derived from the App Store transaction.

Data not linked to you

Identifiers and usage data: random install identifier and typed product-interaction events in our analytics.
Diagnostics: crash, performance, and pipeline-degradation data.
User content: photos, video, audio, and text sent transiently for an import, and unresolved ingredient terms.
Contact info: an email address, only if you type one into the optional contact field when reporting content. It is attached to that report, not to an account.

Data we do not collect

Your name, phone number, or address, other than a display name you choose to publish. Health and fitness data; there is no HealthKit integration. Financial account or card details. Location, precise or coarse. Contacts. Search history. Browsing history. Advertising identifiers.