Privacy Policy

Effective date: October 10, 2026
Applies to Savour for iPhone, version 1.0 and later, and the website at savour.recipes.

1. Who we are

Savour is published by Autonomous Studios LLC, a Wyoming limited liability company (“we”, “us”, “Savour”).

Email us about anything in this policy: [email protected].

2. There are no accounts

The Savour iPhone app has no sign-in of any kind. We do not require or provide account fields for:

• your name, email address, phone number, or postal address
• a sign-in password
• your contacts, calendar, location, or Apple Health records
• your social media logins

Creator Kitchens optionally collect the public name, handle and bio you choose. Publishing is protected by a separate generated Keychain credential, described in section 4.16.

Other server records are pseudonymous: they are associated with a device or installation identifier. These identifiers do not contain your name or contact information. See sections 5 and 6.

Website beta invitations

If you submit the invitation form at savour.recipes, we store your email address, the recipe-source label for the walkthrough, campaign labels from the signup link, your invitation consent version, and the signup date in our private Supabase database. We use your email to send beta invitations and related setup information. Signing up does not create an app account or guarantee a beta place. We do not sell this list or use it for advertising profiles.

We use Resend to deliver these emails and manage beta email subscriptions. We share your email address and beta subscription preference with Resend for this purpose. Resend records delivery, bounce, complaint and unsubscribe information so we can avoid sending unwanted or undeliverable emails. We do not enable email open or click tracking for this beta. Beta invitation consent does not subscribe you to a general newsletter. You can unsubscribe using the link in each beta email; an email unsubscribe does not delete your recipes or create or remove an app account.

If you select the separate optional email checkbox, we also store the cooking-and-product email consent version and date. We share your email and your selected email topics with Resend to send getting-started emails, cooking ideas, the Kitchen Journal and relevant product updates. You can change individual topics or unsubscribe through the links in these emails. Leaving the checkbox unchecked requests only beta invitations and related setup information. Existing invitation requests are not automatically subscribed to these optional emails. We do not link website email addresses to anonymous app activity or enable email open or click tracking.

The intake service uses a secret-keyed hash of your network address for request limits; it does not store your raw network address in the invitation or rate-limit tables. Rate-limit rows older than two days and invitation-only requests older than 180 days are periodically removed when the service receives signup requests. Requests with optional cooking-and-product email consent are retained to document that consent until you ask for removal; unsubscribed addresses remain suppressed in the email service. This is request-driven cleanup, not a daily deletion schedule. Hosting providers may maintain their own security logs.

To withdraw your invitation request or ask for removal, email [email protected] from the address you used to sign up. Campaign labels are captured only with your submitted request. The website uses the separate aggregate measurement described below; it does not store tracking cookies.

Website measurement

The landing page sends only these fixed event labels to our service: page view, beta-action click, walkthrough opened, walkthrough completed, invitation request accepted, and invitation request failed. We store daily totals for each label, not individual browsing histories. No email, recipe content, full page URL, campaign labels, persistent visitor identifier, or cookie is attached. Totals count events, not unique people. The website respects browser Do Not Track and Global Privacy Control signals.

For abuse limits, the service derives a secret-keyed network-address hash that changes each hour. It is kept separately from the counts and invitation list. We do not store the raw network address in these tables. Daily totals older than 90 days and rate-limit windows older than two days are removed when the measurement service receives requests. Hosting providers may maintain independent security logs. Measurement failure does not block an invitation request.

3. What stays on your iPhone

Your library and preferences are stored in the app’s private storage on your iPhone. Cloud features can send selected recipe content, exclusions and household preferences as described in section 4:

• your recipe library — titles, ingredients, steps, photos, notes, ratings, favourites, collections
• your meal plan and saved plan templates
• your grocery list, aisle categories, saved store orders, and shopping trips
• your pantry contents and expiry dates
• your household size, cooking nights, and taste likes and dislikes
• your appearance and display preferences

Deleting Savour removes its local library. Save a .savourbackup file to preserve recipes, photos, collections, plans and settings, and restore it on another phone. The backup goes only to the destination you choose; Savour does not upload it to us.

Photos. When you photograph a recipe or a cookbook page, or import a screenshot, Savour reads the text using Apple’s Vision framework, on the phone. That photo remains on your iPhone. If on-device extraction cannot structure the recognized text, that text can be sent to our service as described in section 4.5. A dish photo can leave when you accept the offer to turn it into a recipe (section 4.12). A compressed recipe photo also leaves when you explicitly publish it in a Creator Kitchen (section 4.16).

Your voice. When you talk to Sous Chef or cook hands-free, Apple transcribes your speech on the device. Your microphone audio and recordings are not uploaded. With your cloud permission and Speechify enabled in Cooking voice, the words Savour will say are sent through our service to Speechify to generate spoken audio. Those words may include recipe details or the assistant’s reply. You can turn Speechify off and use Kokoro or Apple’s voice on the phone. Local speech also takes over if Speechify is unavailable.

iCloud. Savour does not sync your library to iCloud or to us. If you use encrypted iPhone backups, your Savour data is included in that backup. That backup is between you and Apple and is governed by Apple’s privacy policy, not this one.

4. What leaves your iPhone, and when

Cloud recipe actions are initiated by you. Product measurement and entitlement refresh can run in the background; they do not upload your library.

Before the first cloud recipe request, Savour asks for permission to share the details needed for that request with the AI providers listed in section 7. You can decline and keep using recipes saved on your phone. You can change your choice in Profile → Cloud recipe help. Turning it off stops future model requests, including automatic cloud text fallbacks and retries; it cannot recall information already sent. Public catalogue reads and Apple purchase verification remain available. If the listed providers or the scope of sharing changes, we will ask again.

4.1 A recipe website you paste or share

Your iPhone fetches that page directly from the website, the way a browser would, and reads the recipe out of it on the phone. If the page declares a recipe photo, your phone downloads that image to save with the recipe.

The website sees the request, including your IP address and a user-agent string identifying Savour on iPhone. No identifier of you is attached — no device identifier, no cookie, no account. We are not involved and receive nothing.

4.2 A TikTok link

Your iPhone calls TikTok’s public oEmbed endpoint directly to read the creator’s caption, and reads the recipe out of that caption on the phone. TikTok sees the request, including your IP address. No Savour server is involved.

4.3 A social link your phone cannot read — Instagram, and reels generally

Instagram cannot be read from the phone, so the link goes to our importer, which fetches the post’s public caption and, where the platform publishes one, the reel’s transcript or subtitle track. That text comes back to your phone, and your phone reads the recipe out of it.

What we send onward: the link, to a scraping service (see section 7). What comes back: the creator’s own public caption, transcript, name, and thumbnail.

We cache this. The caption we fetched is stored against the link so that the next person importing the same reel does not make us buy the same fetch twice. That cache row records the public post — its URL, platform, caption, transcript, creator attribution, and how many times it has been served. It carries no device identifier and no reference to you, by design: it is a record of a piece of public internet content, never a record of who imported what.

4.4 Letting Savour watch a video

If the caption did not contain enough to cook from, Savour can analyse the video itself. The link and the caption text already fetched go to our service, which resolves the video’s media, has it transcribed and analysed by the AI providers in section 7, and returns the readings to your phone.

The video’s bytes are fetched, used for that one request, and discarded. We do not store the video, and we do not store the analysis.

4.5 Reading free text into a recipe

When your phone cannot structure a block of text by itself — an older iPhone has no on-device model to do it with — the text goes to our service and comes back as a structured recipe.

What we store depends on where the text came from. A creator’s published caption, a spoken transcript, or text read off the screen of a public video is public content, and the reading is cached so nobody pays to read the same reel twice. Text you pasted yourself, and text read off a photo you took, are not added to our shared public cache. Text supplied for a deep-video read may be retained in its private device cache for 30 days. Our AI providers may retain requests under their own service policies.

4.6 Writing a recipe from a request

When you ask Savour to write a recipe, your request goes to our service, together with the allergies and diet tags you saved in Profile, as plain words — so the recipe comes back already avoiding them. Our service does not store this request; provider retention is described in section 7.

Recipe generation, meal planning, dish-specific Sous Chef questions and recipe revisions can send your saved exclusions, dietary tags and relevant household or taste preferences. These help honor your request and are excluded from product analytics.

4.7 Sous Chef

Sous Chef answers most things on the phone. When it cannot place what you asked, your message and the conversation so far go to our service for a reply. When you ask about or revise a saved dish or a dish opened from Discover, its title, servings, ingredients, method and relevant exclusions and preferences are sent with your request. Discover questions can also include the public video link, creator credit and whether recipe details are estimates. Opening chat does not save that dish to your Library. Cloud meal planning can send candidate recipe summaries and relevant pantry, plan and household context. The server cannot directly read or write your on-device database; the app shows and confirms resulting changes. Request content is processed for the action. A completed deep-video read can be cached privately against your device identifier for 30 days so repeated reads do not incur the same processing cost. It is never shared with another device or added to Discover. Other cloud conversations are not saved as a private library on our servers.

Cook Mode’s coach line uses the same channel. When you start cooking a recipe, its title, ingredient names, and steps go to our service once, for a single sentence about what most often goes wrong with that dish. The sentence is kept on the recipe so it is not asked for again; our service does not store the request. Provider retention is described in section 7.

4.8 The plated-dish picture

When you ask for a picture of the plated dish, the recipe’s title and ingredient names go to our service to generate it. The generated image comes back and is saved on your phone. Our service does not store this request; provider retention is described in section 7.

4.9 Planning a week with AI

When you request a cloud meal plan, candidate recipe summaries and relevant pantry, existing plan, household preferences and exclusions can go to our service. This is the selected context for your request, not a copy of your whole library. The app reviews and confirms resulting plan changes. Our service does not store this request as a private library; provider retention is described in section 7.

4.10 Tidying a shopping list

When you tap a Shop button, each ingredient line goes to our service to be reduced to the item a shop actually sells — “3/4 cup shredded mozzarella (freshly shredded melts better)” becomes “shredded mozzarella”.

We cache this, against a one-way hash of the line, so the same line is never paid for twice across everyone using Savour. What is stored is the hash and the shortened product name. The row carries no device identifier and nothing linking it to you.

The shortened name can only ever be words your own line already contained — the service is not allowed to rename, translate, or substitute anything, and your phone checks that before using the answer.

Shopping with Kroger

When you use Shop with Kroger, your ZIP code and the product searches you choose go through our service to Kroger. Savour does not request your precise location for this flow. You review products and package counts before any groceries are added to your retailer cart.

Kroger handles your sign-in and asks you to authorize cart access. Savour never receives your Kroger password. One-time authorization codes and connection refresh tokens pass through our service to exchange or renew access; they are not stored in our database or application logs. Your connection tokens are kept in the device-only Keychain on your phone. Disconnect Kroger in the shopping flow to remove that connection from Savour; you can also revoke access with Kroger.

When you confirm Add to Kroger cart, selected product barcodes and package counts go directly from your phone to Kroger. Checkout, payment, substitutions and fulfillment happen with Kroger. Our service does not keep a copy of the product catalog. We record device-level request counts for abuse limits. Your phone keeps a cart-attempt timestamp and a one-way basket fingerprint to prevent accidental duplicate additions; it does not store product names in that record.

4.11 Buying a subscription

When you subscribe, Apple gives the app a signed receipt, which goes to our service so it can confirm the purchase and unlock the app on that device. Apple also notifies our service directly about renewals, cancellations, and refunds.

We store, against the device identifier: the App Store transaction id, which product was bought, whether it is active, and when it expires. We never receive your name, your email, your Apple Account, or your payment details. Apple handles payment; we never see a card.

Optional creator codes. If you enter a creator code before your first eligible subscription, our service records that code against the random device identifier. It sends the code and identifier to AgentScaler, our creator-program platform, to confirm attribution. For that referred subscription and its known renewal chain, we send verified App Store transaction identifiers, product, purchase and expiry dates, purchase amount and currency, and refund events to AgentScaler so we can measure referrals and reconcile creator commissions. Other subscribers' purchase records are not sent to this platform. Creators can see their attributed totals and earnings; they do not receive your device or transaction identifiers. Recipe content, dietary information, your Apple Account and card details are not included. A creator code does not change the subscription price. Attribution and payment records remain available for reconciliation; contact the privacy address below with a deletion request.

4.12 A photo of a plate of food

When you snap a photo and Savour finds no recipe text in it, it offers to treat the picture as a dish and write a recipe for it. Nothing happens until you accept. If you do, the photo goes to our service and on to the AI provider in section 7, for two questions in turn: what dish is this, and then a recipe for it. What comes back is Savour’s best guess at a restaurant-style version you can make at home — it is marked as Savour’s, not as any creator’s. Our service does not retain the photo after processing; provider retention is described in section 7.

4.13 Checking a cover picture

A recipe imported from a social video arrives with the video’s cover frame. Before Savour uses that frame as the recipe’s picture, it may send the frame to our service with one question: does this show the finished dish? The answer is yes or no, and a no means Savour shows its placeholder instead. This is the creator’s public frame, never a photo you took, and it is not stored.

4.14 Popular dishes

The “Popular with other cooks” row in your library asks our service for the most-reused public links in the recipe cache. The request carries the device identifier and nothing else — none of your recipes, and nothing about which tiles you look at. Tapping a tile runs an ordinary link import, and section 4.3 applies to it.

4.15 What stays outside these requests

We do not upload your whole private library as a backup. Ratings, private notes and collection membership stay local. Voice recordings stay on the device; only transcribed questions can be sent when you ask the cloud assistant. We do not access your contacts, precise location or Apple Health records. Selected recipe, pantry and preference context or photographs described above can be sent when needed for an action you request. Avoid putting unrelated personal information into a cloud request.

4.16 Creator Kitchens

Creating a Kitchen sends the public name, handle and bio you choose to our service. New Kitchens stay private until a service operator approves them. Publishing sends only the snapshot you review: recipe title, description, original yield, ingredient and method lines, estimate labels, cooking times, source credit, optional cooking tips, selected public collection and compressed recipe photo. These appear publicly in the app and on a share page. Personal notes, meal plans, cooking history, private collections and source transcripts are not included. Editing a local draft does not update its public snapshot until you publish again.

Following and blocking are stored on your phone. Saving a public recipe creates a personal Library copy. Unpublishing removes the public recipe; copies people already saved and temporary web caches may remain. Creator ownership uses a separate random credential kept in this phone’s Keychain. The server stores its hash. That credential is not part of a recipe backup and does not sync to another phone. Report submissions include the selected Kitchen, your report text and the service device identifier, and are private to our moderation service. Creator actions do not send content to an outside AI provider. Mutation rate-limit counters associate the service device identifier with an action and hourly count; counters older than two days are removed when a mutation is requested.

Public Kitchens and moderation reports do not have automatic expiry. To remove a Kitchen or a report, contact [email protected]. Do not send your private ownership credential.

5. The device identifier

To meter usage without accounts, Savour generates a random UUID the first time it needs one and stores it in your device’s Keychain. It travels on every request to our own services, with an Apple App Attest assertion proving the request came from a genuine, unmodified copy of Savour.

• It is randomly generated. It is not derived from your Apple Account, your email, your phone number, the advertising identifier, or any hardware serial number.
• It is not synced to iCloud and does not follow you to another device.
• It associates service records with a device. We do not obtain your name or Apple Account identity from it.
• It is used for rate limiting, abuse prevention, cost control, and knowing which device a subscription belongs to, and confirming an optional creator code as described in section 4.11. It is not an advertising identifier and is not used for cross-app tracking.
• It is never attached to requests to third-party websites (sections 4.1 and 4.2).

Because it lives in the Keychain, it survives deleting and reinstalling the app on the same device. Erasing the device removes it.

6. Analytics, ads, and tracking

• No advertising, and no ad network code of any kind.
• No third-party analytics or crash-reporting SDK. No Firebase, Google Analytics, Amplitude, Mixpanel, Segment, Sentry, or anything like them is built into Savour.
• No tracking, as Apple defines it. Savour never touches the advertising identifier and shows no App Tracking Transparency prompt, because it has nothing to ask for.
• No data brokers. We do not sell or rent personal information or share it for cross-context behavioural advertising under US state privacy laws. Our own creator-program platform processes the optional referral records described in section 4.11.

Savour sends minimal first-party product events to our service: screen names, subscription-plan and outcome labels, cooking activity and coarse counts or timings. A random per-install identifier groups these events. It is separate from the Keychain device identifier used for subscription and service access, and is not a name, email address or advertising identifier. We do not store the service device identifier on product-event rows. The device keeps up to 200 events for retry after interruption or loss of connectivity. Server product events older than 90 days are periodically removed; rate-limit hashes for this endpoint are periodically removed after one day. Recipe text, private links, allergy lists, household preferences and receipt payloads are excluded from this measurement. The optional PostHog delivery remains unconfigured in this release.

Discover also sends public post identifiers with view, playback-start, stall, failure, save, plan and completed-share counts and bounded startup timings to our service. These are separate from product-event rows: installation IDs are discarded, and a device hash that changes each day is used for duplicate protection and rate limits. Duplicate-check records are removed after two days; daily post totals are removed after fourteen days when feedback arrives. No private recipe text, dietary restrictions, goals or ingredient preferences are sent for Discover ranking. Taste recommendations stay on your phone. Failed playback never counts as a dislike. Feedback retries expire after one day.

7. Who else is involved

We use a small number of companies to run the parts of Savour that do not run on your phone. Each receives only what its job needs. Our AI providers may retain requests and responses for security or abuse monitoring under their service policies, independently of our own caches. Anthropic documents standard API deletion within 30 days, with exceptions; Google documents abuse-monitoring retention for 55 days. Deepgram public-video transcription is sent with its model improvement opt-out enabled. We do not promise zero provider retention.

Our AI and scraping providers are not given the Savour service device identifier. Supabase hosts the operational identifiers and records described in this policy. We do not give providers data for advertising profiles. If we change this list we will update this page.

8. What we store, and for how long

Product events and their rate-limit windows have bounded retention. Other operational and public-content records do not currently have an automatic deletion schedule, so we are not going to claim one. The honest answer is: we keep the rows above until you ask us to delete them, and we will delete them when you do.

To delete everything associated with your device: email [email protected]. App operational rows are not linked to your website invitation email. For those rows, we may ask you to send the device identifier so we can find the rows — we have no other way to locate them, and we will never ask you for identifying information to prove they are yours. If you would rather not send it, deleting the app and erasing the device removes the identifier from your end and leaves us with rows nobody can ever match to a person.

9. Your rights

Depending on where you live you may have rights to access, correct, delete, or port your personal data, or to object to its processing — under the EU and UK GDPR, the California CCPA/CPRA, or similar laws.

Most of these are self-executing here, because the data is on your device and under your control. For the server-side rows in section 8, email [email protected] and we will action any valid request.

We do not sell personal information and have not done so. We do not share personal information for cross-context behavioural advertising. There is nothing to opt out of.

For users in the EEA and UK: our legal basis for the device identifier and usage rows is our legitimate interest in running the service securely and controlling its cost; for subscription records it is performance of our contract with you. The processing is minimal and pseudonymous.

10. Children

Savour is a general-audience cooking app and is not directed to children under 13. We do not knowingly collect personal information from children. The website invitation form does collect an email address. If you believe a child has provided us personal information, contact [email protected].

11. Changes

If we change this policy we will update the effective date and post the new version at savour.recipes/privacy. Changes that affect what leaves your device will be surfaced in the app.

12. Contact

Autonomous Studios LLC
Wyoming, United States
[email protected]