Recipe Grab — Privacy Policy

Effective date: May 26, 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 that data lives, and the choices you have. It is written to match the app's actual architecture — not a generic template. If anything below doesn't match what you observe, please email us; that is a bug.

1. Who we are

Recipe Grab is an independent iOS application that turns short cooking videos (TikTok, Instagram Reels, YouTube Shorts), recipe websites, photos of cookbooks or handwritten cards, and pasted text into structured recipes you can cook from, scale, and add to a grocery list. There is no Recipe Grab account, no profile, and no login.

When you buy Recipe Grab, you pay Apple. We do not receive your name, email, billing address, or card data — Apple does, under Apple's own privacy terms.

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.

2. The short version

We do not require an account. We do not ask you to sign in.
We do not use IDFA, do not show advertising, and do not run App Tracking Transparency prompts.
Recipes you save live on your iPhone and — if you turn on iCloud sync in iOS Settings — in your own iCloud account. We never see them.
When you import a recipe from a public URL (TikTok video, web page, etc.), the URL is sent to our server so we can fetch the transcript or page content. We process it and return the structured recipe. We do not store the URL or the recipe.
When you import a recipe from a photo (camera scan or photo library), the image is sent to our server over HTTPS and run through a server-side AI vision model to extract the recipe. The image is not stored after extraction completes.
When your device cannot transcribe a video itself (older iPhone, no Apple Intelligence), the audio is sent to our server for transcription via a third-party speech-to-text provider, then discarded.
We use a small set of third-party SDKs for crash reporting, anonymous product analytics, and paywall presentation. Each is configured to minimise what it collects — see Section 6.

3. What data Recipe Grab handles

We split data into three categories: content you create or import, technical data we need to make the import work, and diagnostic / analytics data.

3.1 Content you create or import

Recipe URLs you share into the app (e.g. a TikTok or Instagram link).
Pasted recipe text.
Photos you import from your library or take with the camera (handwritten cards, cookbook pages, screenshots of recipes).
Video files you share from your library when on-device transcription isn't available.
The structured recipes themselves — titles, ingredients, steps, cuisine tags, your scaling adjustments, your notes, your grocery list, your allergen flags, your meal-planner entries.

Where this lives:

On your device, in the app's local Core Data store. Always.
In your private iCloud container if iOS-level iCloud Drive / CloudKit sync is on for Recipe Grab. The container ID is iCloud.dev.recipegrab.app and lives inside your personal Apple ID. We have no access to it. Apple's privacy terms apply to iCloud.
Briefly in transit through our server when you import from a URL, photo, or video — see Section 4 for the details.

We do not maintain a server-side copy of your recipe library. We have no recipe database to query, to be subpoenaed for, or to leak.

3.2 Technical data needed to make import work

When you import from a URL, paste text, or send a photo or short video, Recipe Grab calls our worker service at api.recipegrab.app. The payload depends on the action:

Action	What is sent to our server	What we do with it
Import from public URL (TikTok / Instagram / YouTube / web page)	The URL; a unique request ID; an Apple App Attest assertion proving the request came from a real install of Recipe Grab.	We resolve the URL through third-party transcript providers or fetch the public web page, extract the recipe, return it.
Photo of a recipe (camera scan or photo-library import)	The image bytes; a request ID; an Apple App Attest assertion.	We run the image through a server-side AI vision model (GPT-4o Vision) to extract the recipe and return it. The image is not stored server-side after the response is returned.
Video file that the device can't transcribe locally	The audio bytes; a request ID.	We forward audio to a third-party speech-to-text service and return the transcript. Audio is discarded after the response is returned.
Server-side estimate (calories, time) when the on-device model can't handle the language	A short ingredient list, title, cuisine tag, optional transcript snippet.	A single LLM call; we return the estimate.
"Improve with AI" / "Refine" actions you tap	Current recipe state plus transcript, scoped to the recipe you're editing.	A single LLM call; we return the suggested patches.
"Report a problem" feedback you explicitly submit	Your comment text, the source URL of the recipe (or the failed share), the recipe title, the ingredient list and steps as we extracted them, any extraction error code, and your app version + OS version.	Helps us reproduce extraction bugs and understand what content broke. We don't link this to an identity (no account system); we use the URL only to re-fetch and debug, and we delete the feedback record after the issue is resolved or 90 days, whichever comes first.
Onboarding answers you choose to share	The questions you tapped (e.g. dietary, allergens), an anonymous device ID, and any optional free-text note.	Used to personalise the app and to measure which channels bring people to Recipe Grab.
Anonymous "ingredient not recognised" telemetry	The ingredient name and its language tag — no recipe, no URL, no user ID.	Appended to a daily log so we can extend the ingredient catalogue.
Device registration for async save-complete push	APNs device token + IDFV; App Attest assertion	Stored in our Redis cache up to 30 days, used solely to send a single "Saved <recipe title>" notification when an asynchronously-imported recipe finishes saving after iOS suspends the app.
Voice Chef session start	Recipe title, current step text, section title, ingredient names, persona/personality selection, beta whitelist ID; App Attest assertion	We mint a short-lived OpenAI Realtime ephemeral key with this recipe context baked into the system prompt so the assistant can ground answers in the dish you're cooking. Sent once at session start; no further recipe data flows through our server.
Pipeline degradation telemetry (DataLossLogger)	Stage tag, error code, opaque hashed recipe ID, app version, randomly-generated per-install UUID; App Attest assertion (best-effort)	Sent in batches to help us detect silent extraction or AI-estimate failures. Carries no recipe content, URLs, or Apple identifier. Opt-out: Settings → Privacy → "Help improve Recipe Grab".

We do not log your IP address against the request. Our server logs the request ID, the destination host (e.g. tiktok.com), and a short hash of the URL — never the full URL — for the time needed to diagnose failures.

Once a request returns to the app, the server-side copy is discarded, with one narrow exception described below in "Server-side caching".

Server-side caching

To make the app faster for everyone, we cache results of recipe extractions briefly:

Transcripts and recipe metadata: up to 24 hours, keyed by URL hash
Vision-extracted recipes from photos/video frames: up to 1 hour, keyed by URL hash
Public video captions (Instagram/TikTok post metadata): up to 24 hours, keyed by URL hash

The cache stores extraction output only — not your device identifier, email, or any account info (we don't have accounts). Cache entries automatically expire and are deleted from server memory.

The only other persistent server-side data are: the "Report a problem" comments you choose to submit, and the anonymous unresolved-ingredient log.

Disaster recovery backups

For service reliability, we keep encrypted daily snapshots of our Redis cache in Cloudflare R2 (EU region) for up to 14 days. These snapshots contain whatever is in the live cache at backup time — transcript text, captions, quotas, push token mappings. Snapshots are accessed only for verified restore drills (monthly automated) or actual disaster recovery. We do not analyze, share, or hand over backups to third parties.

We are working to add selective key exclusion to backups — non-essential transient data will eventually be filtered out before snapshot. Until then, the 14-day window matches our broader retention stance: even if a backup snapshot persists, the data inside is bounded by Redis TTL (24h for transcripts/captions; 60 days max for push token mappings).

3.3 Diagnostic and analytics data

We use three third-party SDKs. Each is configured in privacy-minimising mode:

Crash reporting. A third-party crash-reporting SDK captures crashes and serious errors. It is configured to disable IP collection, not attach screenshots, not attach view hierarchies, not capture network breadcrumbs, not set a user identifier, and to strip URLs from any captured event before it leaves the device.
Product analytics. A third-party analytics SDK captures session start/end and a small set of typed product events (e.g. "first recipe imported", "paywall shown"). We explicitly disable IP, IDFV, carrier, city, region, DMA, and lat-long. We do not enable session replay. Our Amplitude analytics do not send recipe titles, URLs, transcripts, or ingredient names, and we do not transmit free-form text you type into the app — except for optional fields you choose to fill in, such as the "Report a problem" comment box or the "Other" note on an onboarding question. (Recipe context that flows to OpenAI Realtime at the start of a Voice Chef session is described separately in Section 3.2.)
Paywall presentation. A third-party paywall service is used only at the moment we present a purchase screen. It receives the placement name and an anonymous install identifier. It does not receive your recipes.

3.4 Permissions Recipe Grab asks for

Camera — only if you tap "scan a recipe with the camera". The captured image is uploaded over HTTPS to our server at api.recipegrab.app and routed through a server-side AI vision model (GPT-4o Vision) to extract the recipe in one round trip. The image is processed for that single extraction and is not stored server-side after the response is returned. We do not use it for any other purpose.
Photo library — only if you tap "import from photo". You pick which photos; the rest stay private. The selected image is uploaded over HTTPS to our server and processed the same way as a camera scan (server-side AI vision; not retained after extraction).
iCloud — controlled by you in iOS Settings.
Notifications — used for Live Activities while you're in cooking mode, and a one-time transactional push when an asynchronously-imported recipe finishes saving (so you know your share completed even if iOS suspended the app while extraction was running). We do not send marketing pushes.
Microphone — live audio streamed directly to OpenAI Realtime via WebRTC when you use Voice Chef. Our server only mints a short-lived ephemeral OpenAI key (signed with App Attest); audio bytes do NOT pass through our infrastructure. We do not record audio.
- Audio is NOT recorded or stored — it's streamed live and discarded by OpenAI per their Realtime API terms.
- Voice Chef stops immediately when you tap End, leave the recipe, or background the app.
- The microphone indicator (iOS yellow dot) shows whenever audio is being captured.
- You can revoke microphone access at any time in iOS Settings → Privacy → Microphone → Recipe Grab.

Recipe Grab does not request: location, contacts, calendars, reminders, health data, motion, Bluetooth, or local network access.

3.5 Data we never collect

Your name, email, phone number, address.
Your Apple ID, Game Center ID, IDFA, or any cross-app advertising identifier.
Your precise or approximate location.
Your contacts, calendar, photos you did not explicitly import, or any background screen content.
Health, fitness, biometric, or financial data.

4. On-device vs server processing (our differentiator)

This section exists because we promise it in the marketing and we want you to be able to check the promise.

On-device, by default, when your iPhone supports it:

Transcription of imported short videos, via Apple SpeechAnalyzer (iOS 26 with Apple Intelligence) or a local CoreML transcription model (iPhone 15 Pro and newer get a larger model; older devices get a smaller one).
Structured recipe extraction from the transcript, via Apple FoundationModels (iOS 26 + Apple Intelligence devices: iPhone 15 Pro / 15 Pro Max / all iPhone 16 / all iPhone 17 / iPhone Air).
Ingredient parsing, unit conversion, deduping, allergen flagging, grocery-list building — all in a local Rust core compiled into the app.
Search across your library.

Server side, when the device cannot do it locally — or when you explicitly ask for it:

Fetching the captions or transcript of a TikTok / Instagram / YouTube video that you imported by URL. The video is hosted by a third party; we fetch the transcript through a transcript provider and return it. We do not download and store the video.
Downloading the contents of a recipe web page you imported.
Transcribing an audio track when the device has no Apple Intelligence and the local CoreML model is not viable for that clip. The audio is forwarded to a third-party speech-to-text service for processing and then discarded.
Extracting recipes from photos (camera scans and photo-library imports). The image is uploaded to our server over HTTPS and processed by a server-side AI vision model (GPT-4o Vision) in a single round trip. The image is not retained after the response is returned, and is not used for anything other than that one extraction.
Estimating calories and cook time when the on-device model does not support the language of the recipe (currently Russian, Ukrainian, Polish, Arabic, Hindi and similar are routed to the server).
"Improve with AI" / "Refine" actions you trigger from the recipe editor.

When the server is involved, the data is processed and returned within the request. We do not retain it beyond the short-lived extraction cache described in Section 3.2 ("Server-side caching").

5. Why we process this data — and the lawful basis (for GDPR users)

Purpose	Lawful basis (GDPR Art. 6)
Run the import you asked us to run	Contract (you asked, we performed)
Present a paywall and process any purchase you make	Contract
Diagnose crashes and obvious errors via our crash-reporting SDK	Legitimate interest in keeping the app usable; minimised collection
Understand which features are used (anonymous product analytics)	Legitimate interest in product improvement; opt-out by uninstalling — we cannot identify you to honour a granular opt-out because we don't know who you are
Show you the right paywall (third-party paywall service)	Contract / legitimate interest
Read "Report a problem" feedback you sent	Consent (you submitted it)

We do not sell personal data. We do not use it for advertising. We do not profile you. We do not share data with data brokers.

6. Third parties we rely on

To run the service we use a small number of external processors, grouped by purpose below. Each processor handles data only on our instructions and does not use it to train any model. A current list of named sub-processors is available on request at contact@heylabs.co.

Category	Why we use it	What flows to it
Apple (App Store, StoreKit, iCloud, on-device AI frameworks, App Attest)	The platform Recipe Grab runs on	App Store transaction; iCloud data inside your private container; App Attest assertion
Our own server (`api.recipegrab.app`, on a VPS we operate)	Brokers calls to the providers below; runs server-side fallbacks	See Section 3.2
Third-party transcript providers	Fetch the public captions of a TikTok / Instagram / YouTube video you imported	The public video URL
Server-side AI providers	Speech-to-text when the device cannot transcribe locally; structured-extraction and language-routing fallbacks when on-device models don't support the source language	Audio bytes; or recipe-scoped text (title, ingredients, steps, optional transcript snippet)
Crash-reporting SDK	Crash and serious-error diagnostics	Stack trace, app version, OS version, redacted URL
Product-analytics SDK	Anonymous typed product events	Anonymous install ID, event names, OS / device class
Paywall service	A/B routing of the in-app paywall	Placement name, install ID, OS, device class
Edge network / DDoS protection	All worker traffic	Request metadata at the edge

We do not knowingly pass any of these processors data that identifies you personally, because we do not collect such data in the first place.

7. How long we keep data

Recipes, photos, library content — for as long as you keep them on your device or in your iCloud. Deleting the app or signing out of iCloud removes them.
Request transit data on our server — discarded as soon as the request completes, except for the short-lived extraction cache: transcripts and recipe metadata up to 24 hours, vision-extracted recipes from photos/video frames up to 1 hour. Cache entries are keyed by URL hash, contain extraction output only (no device or account identifiers), and automatically expire from server memory. Diagnostic logs are kept up to 30 days then rotated.
"Report a problem" feedback — kept until the developer has read and acted on the report, or 90 days, whichever comes first; then purged.
Unresolved-ingredient telemetry — kept indefinitely as it contains no identifier (just a noun and a language tag like "ru" / "укроп").
Onboarding survey answers — kept indefinitely. No Apple ID, no IDFV. Anonymous per-install Amplitude UUID + question/answer slugs. Used to size cohorts and tune onboarding.
Crash reports — the crash-reporting provider's retention applies (typically 30–90 days).
Analytics events — the analytics provider's retention applies.

8. Your rights

Because we don't operate accounts and don't store your library, most rights are exercised directly on your device or through Apple:

Access / portability: every recipe can be exported from the app at any time (Markdown / JSON). Your library is in your iCloud and accessible there.
Deletion: delete the app or individual recipes inside it; sign out of or wipe the iCloud container. There is nothing on our servers tied to you to delete.
Correction: edit any recipe directly in the app.
Object / restrict processing: for the server-side import calls, you can simply not import. The app works fully on imported and local content without further server calls.
Right not to be tracked: we do not track you across apps or websites. No action needed.
Complaint to a supervisory authority (EU/UK): you may lodge a complaint with your national data-protection authority.

California residents (CCPA / CPRA): we do not sell or share personal information for cross-context behavioural advertising. We do not have a "Do Not Sell" mechanism to honour because there is nothing to sell.

EEA / UK / Swiss data transfers: the worker server is operated on EU infrastructure. Third-party providers may process data in the United States; transfers rely on those providers' Standard Contractual Clauses.

To exercise any right, write to contact@heylabs.co. We will respond within 30 days.

9. Children

Recipe Grab is not directed to children under 13 (or the equivalent minimum age in your country) and we do not knowingly collect personal information from children. If you believe a child has provided personal information to us, please contact us and we will delete it.

10. Security

All traffic between the app and our server is TLS 1.2 or higher.
Server-side endpoints that incur cost are protected by Apple App Attest, so only legitimate installs of Recipe Grab can call them.
We do not store credentials, passwords, or payment data — there are none to store.
Crash and analytics traffic uses the providers' own TLS endpoints.

No system is perfectly secure. If you discover a vulnerability, please email contact@heylabs.co with the subject "Security · Recipe Grab".

11. Changes to this policy

If we materially change how Recipe Grab handles data, we will update this page and, where appropriate, surface the change in the app on next launch. The "Effective date" at the top reflects the current version.

12. Contact

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

contact@heylabs.co

Apple App Privacy Disclosure

The following is provided in the format Apple requires in App Store Connect, to make the corresponding App Privacy section straightforward to fill in.

Data Used to Track You

None.

Data Linked to You

None. (Recipe Grab does not associate any data with a user identity, because we do not collect or assign one.)

Data Not Linked to You

Purchases — Purchase History (handled by Apple; we receive an anonymised transaction).
Identifiers — Device ID (an anonymous install identifier used by our crash-reporting, analytics, and paywall SDKs for crash dedup, session continuity, and paywall A/B routing).
Usage Data — Product Interaction (typed events like "first import completed", "paywall shown"; no recipe content, no URLs).
Diagnostics — Crash Data, Performance Data, Other Diagnostic Data (third-party crash-reporting SDK; redacted, no IP, no user-identifying content).
User Content — Photos or Videos, Audio Data, Other User Content (transiently sent to our server during an explicit import action; not retained server-side; in the case of audio, processed by a third-party speech-to-text service and then discarded).

Data Not Collected

Contact Info (name, email, phone, address, other user contact info).
Health & Fitness.
Financial Info.
Location (precise or coarse).
Sensitive Info.
Contacts.
Search History.
Browsing History.
Identifiers — User ID, Advertising Data (IDFA).
Other Data.

Tracking

Recipe Grab does not engage in tracking as defined by Apple's App Tracking Transparency. No ATT prompt is shown.