Gainplate Privacy Policy

Gainplate ("Gainplate", "we", "us", "the app") is an iOS meal-planning app focused on hitting a daily protein target. This policy explains what data the app touches and what leaves your device.

The short version: nothing individually-identifiable about you is uploaded anywhere. Everything you configure — body weight, dietary preferences, favorites, imported recipes, swipe history, household size — lives on your iPhone in the app's UserDefaults, its Documents folder, or the iOS Keychain. We do not run servers that receive any of it, and there is no user account to create.

One categorical exception exists and is described in detail below:

1. Product-interaction analytics via PostHog (Section 2.4). An install-scoped anonymous ID plus a small closed set of behavioral events (tab views, retailer handoffs, cook-through confirmations, paywall shown / subscribed) is sent to PostHog so we can measure feature usage and retention. No bodyweight, no household, no favorites, no imported recipe content, no email, no Apple ID is ever included. Opt-out toggle: Profile → App → Analytics.

The "Add your own recipe" feature is fully on-device: photos are OCR'd with Apple's Vision framework and structured into a recipe locally, and nothing derived from the photo or the text you paste or type ever leaves your phone (see Section 6 of the Terms of Use and Section 3 below).

Additionally, future releases may share aggregate, anonymized statistics computed over cohorts of ≥100 users with grocery retailer partners so those partners can see the routing / fulfillment performance of the Gainplate user base (Section 3.5). Individual user data never enters those aggregates in an identifiable form, and the same Profile → App → Analytics opt-out excludes your device from all outbound data collection.

Gainplate is developed and operated by Austin Connor, an individual solo developer, not an incorporated entity. All references to "we" in this document mean that individual.

1. Data we collect and store on your device

The following are stored locally on the iPhone the app is installed on, in UserDefaults (or the iOS Keychain where noted). They stay on-device — they never leave your phone unless you explicitly export them (e.g. by sharing a screenshot) or unless a specific outbound feature described in Section 2 requires them for a single request:

• Body weight and protein multiplier. Used to compute the daily protein target displayed on the Today tab.
• Dietary exclusions and preferred cuisines. Used to filter recipes in Browse and to shape the Today lineup and recommendations.
• Cook-time preference. Sets Browse defaults.
• Household composition (adult / kid counts). Scales ingredient quantities on the Recipe Detail view.
• Favorites list (FavoritesStore). Recipe IDs you have starred.
• Imported recipes (UserRecipesStore, stored as user-recipes.json in the app's Documents folder). Any recipes you have added via the "Add your own recipe" flow — the structured recipe (name, ingredients, steps, macros) plus the optional user-supplied hero image. Never uploaded. Delete an individual recipe from the "My Recipes" collection at any time; uninstalling removes all imports.
• Per-recipe buy-list filters (BuyListStore). Which ingredients on a given recipe you have marked as "already have" vs "still need to buy" — used to trim the retailer deep-link payload.
• Swipe / preference history (MealPreferences). Per-recipe swipe outcomes and the derived preferenceScore used by the Today ranker and Browse feed. Stays on device.
• Cook-through history. Which recipes you have opened in Detail or handed off to a retailer. Used locally to influence ranking and to render "Recently cooked" surfaces. Stays on device.
• Weekly meal plan (WeeklyPlanStore, key gp.currentWeeklyPlan, Premium+ only). The generated 7-day × 4-meal lineup.
• Preferred retailer setting. Which grocery retailer Profile is locked to (or auto for smart routing).
• Onboarding acknowledgment. A single boolean recording whether you have seen the first-run disclosure sheet, so we do not re-show it on every launch.

Uninstalling the app deletes all of the above (any Keychain entry is scoped to the app's service string and is removed with the app). We do not sync any of it to iCloud by default.

2. Data sent to third-party services

The app calls a small number of anonymous public APIs. No personal data — name, email, device identifier, body weight, dietary preferences, favorites — is transmitted in any of these calls. The one place a specific ingredient list crosses the network is a retailer deep link that you explicitly tap (see §2.2 below).

2.1 TheMealDB (recipe data)

• What we send: an anonymous HTTPS request for recipe search / lookup by name, ID, or cuisine.
• What comes back: recipe records (title, ingredients, image URL, source URL).
• Provider: TheMealDB, themealdb.com.

2.2 Retailer deep-links (grocery hand-off)

• What we send: nothing programmatically. When you tap a per-ingredient retailer glyph on Recipe Detail, the app opens the chosen retailer's iOS app (or their website in Safari as a fallback) with a search query for that single ingredient pre-populated. The retailer, not Gainplate, handles the resulting session — including any account sign-in, cart persistence, and checkout.
• Which retailer: Walmart, Target, Kroger, or Hy-Vee — chosen by the smart-routing rule or locked to a single retailer via Profile. Walmart and Target open via a native scheme (walmart://search?query=… / target://search?query=…) with a walmart.com / target.com web fallback; Kroger and Hy-Vee open their website search directly.
• What the retailer receives from us: only the search query string (a list of ingredient names). No Gainplate identifier, no user profile, no swipe history, no preference score, no cook-through history, and no account handle is included in the deep link or shared with the retailer through any back-channel. We have no server-side integration with any retailer today.
• Providers: Walmart Inc., walmart.com; Target Corporation, target.com; The Kroger Co., kroger.com; Hy-Vee, Inc., hy-vee.com.

2.3 Apple StoreKit (subscription payments)

• What is sent: standard StoreKit purchase flow. Apple handles all payment processing, receipt validation, and subscription-lifecycle events.
• Provider: Apple, standard App Store payment infrastructure.
• Note: Gainplate never sees your payment method, billing address, or Apple ID.

2.4 PostHog (product-interaction analytics)

• What we send: a small, closed set of behavioral events that measure feature usage and retention. The full catalog is defined in Sources/GainplateApp/Services/Analytics.swift (AnalyticsEvent enum) and includes: app_launched, tab_viewed, recipe_viewed, recipe_favorited, retailer handoff initiated / completed events (with recipe id, ingredient count, and an estimated basket-value bucket — no user identity, no bodyweight, no household), cook-through confirmed / skipped, paywall shown / subscribed, and shopping-session start / end events. Each event carries an install-scoped anonymous ID (a random UUID minted on first launch and stored in the iOS Keychain under gp.analytics.installID) as the PostHog distinctId so retention and cohort math work without ever handing PostHog anything derivable back to a person.
• What is NEVER sent: body weight, protein target, household composition, dietary exclusions, favorites list contents, imported-recipe content, email address, Apple ID, IDFA, IDFV, IP address (we don't set it; PostHog's edge sees whatever your network already reveals), device model tied to an individual, or any content of photos / OCR text / typed recipes.
• Endpoint: https://us.i.posthog.com (PostHog's US cloud).
• Provider: PostHog Inc., posthog.com. PostHog's own privacy policy governs their processing of the events described above.
• Retention: subject to PostHog's default retention on our project (currently 1 year for raw events, per PostHog's US-cloud defaults). We do not export raw event data outside PostHog.
• Opt-out (kill-switch): Profile → App → Analytics. Toggling this off immediately calls PostHog's optOut() and short-circuits every subsequent track(…) call in the app, so no queued event replays and no future event fires while opt-out is set. The toggle state is stored on-device (UserDefaults key gp.analytics.optedOut); the SDK is initialised at launch and respects the persisted opt-out before any network call. Session replay is disabled at the SDK config level; no session recording ever leaves your device.

3. What we do NOT do

• We do not sell your data to advertisers. Ever. This is not a business model we will ever adopt. The app has no advertising SDKs integrated today, no ad SDK is served, and there is no back-door mechanism that ships user data to an ad network under any circumstance.
• No user accounts, no sign-in, no email required to use the app.
• No cross-app or cross-website tracking. We do not use the iOS IDFA, we do not fingerprint your device, and we do not correlate activity across other apps or websites you use.
• No transmission of any individually-identifiable user data (body weight, dietary preferences, favorites, imported-recipe content, swipe history, cook-through history) to Gainplate servers or any third party. The install-scoped anonymous ID sent to PostHog (Section 2.4) is a random UUID that is not linked to any real-world identifier. See Section 3.5 for the strict boundary on aggregate statistics shared with grocery-retailer partners.
• No AI / language-model calls. The app makes no LLM requests. The "Add your own recipe" import runs entirely on-device (Apple Vision OCR + local structuring); nothing you scan, paste, or type is sent to any server or AI service.
• No advertising SDKs. (The app contains stubs for rewarded ads as a future free-tier unlock mechanism, but no ad SDK is integrated and no ads are served.)
• We do not sell your personal data. Product-interaction analytics described in Section 2.4 are used solely to measure feature usage and retention for our own product decisions — not sold, brokered, or licensed to any third party.
• Analytics posture: the app ships with PostHog integrated for product-interaction analytics as described in Section 2.4. The event catalog is closed and explicit — no free-form event names, no identity payload — and the entire pipeline is governed by the Profile → App → Analytics opt-out toggle (Section 3.5.3).

The current release's PrivacyInfo.xcprivacy manifest declares NSPrivacyTracking = false (PostHog analytics is first-party, own-app-scope only, keyed to a random install-scoped ID and never used for cross-app tracking — so under Apple's ATT definition this is "collection," not "tracking") and an NSPrivacyCollectedDataTypes array covering the NSPrivacyCollectedDataTypeProductInteraction data class, with NSPrivacyCollectedDataTypePurpose = Analytics and both NSPrivacyCollectedDataTypeLinked and NSPrivacyCollectedDataTypeTracking set to false. Required-reason API declarations cover UserDefaults access (CA92.1) and FileTimestamp access (C617.1). Any future release that changes this will update the manifest in the same commit.

3.5 Data sharing with partners (grocery retailers)

Gainplate's long-term business model is to license aggregate, anonymized recipe-intelligence insights to grocery retailer partners (e.g., Walmart, Target, Kroger, Instacart) so those partners can see the fulfillment performance of routed Gainplate users. This section sets the hard boundaries on what that ever means for your data.

3.5.1 What is NEVER shared with partners

Individual user data is never shared with any grocery retailer, data broker, or other third party in individually-identifiable form. That prohibition specifically includes, and is not limited to:

• Swipe preferences (MealPreferences outcomes and derived scores).
• Cook-through history (which recipes you opened, handed off to a retailer, or confirmed you cooked).
• Favorites (FavoritesStore starred recipe IDs).
• Macro history (per-day protein / kcal actuals derived from cooked meals).
• Purchase intent (which recipes or ingredients you routed to Walmart, Target, or Kroger and which ingredients survived the buy-list filter).
• Body weight, protein target, dietary exclusions, household composition, or any other Profile field.

3.5.2 What MAY be shared with partners

Aggregate, anonymized statistics computed across a cohort of Gainplate users may be shared with grocery retailer partners solely to demonstrate routing performance — for example, "median basket size for Gainplate users who chose Walmart in the past 30 days," or "cook-through rate for imported recipes vs TheMealDB-sourced recipes."

Every aggregate export is subject to the following irreducible constraints:

• Cohort minimum of 100 users. Any aggregate statistic shared externally must be computed over a cohort of at least 100 Gainplate users. Sub-100 cohorts are dropped, not published, to prevent re-identification by joining a small-cohort statistic back to a single user.
• No personally-identifying information in the export. Aggregate exports carry no name, no email address, no IP address, no advertising identifier (IDFA), no vendor identifier (IDFV), no device model string tied to an individual, and no cohort key that could resolve to a single user. Only the aggregate statistic itself and the cohort size travel to the partner.
• No re-identification-capable joins. We do not ship keys, hashes, or tokens that a partner could use to line up a Gainplate aggregate row against a specific user in their own systems.
• Retailer-neutral cohorts. Aggregate cohorts are constructed across the Gainplate user base as a whole (or across all routed users of the retailer in question); we do not slice cohorts in ways that would encode information about specific individuals.

3.5.3 The Analytics opt-out (kill-switch)

Every form of outbound analytics data collection — the PostHog product-interaction pipeline described in Section 2.4, and the aggregate-partner rollups described in Section 3.5.2 — is governed by a single opt-out toggle:

Profile → App → Analytics

Turning this toggle off disables ALL outbound analytics data collection by Gainplate: no product-analytics events fire, PostHog's own optOut() is engaged at the SDK level so nothing queued is flushed, and your device's activity is excluded from every aggregate cohort computed for a partner. The toggle is a hard kill-switch, not a preference — turning it off means your device produces zero outbound analytics signal from that point forward, including for the partner-aggregate use case in Section 3.5.2.

Note: the opt-out governs analytics only. Third-party network calls required to deliver a feature you explicitly invoke — TheMealDB recipe lookups (§2.1), the retailer deep link that opens when you tap an ingredient's shop glyph (§2.2), and Apple's StoreKit purchase flow (§2.3) — are not analytics and are not governed by this toggle. They fire only when you take the action that requires them.

The toggle's state is stored on-device and is respected client-side before any analytics event is emitted, so opting out does not require trusting a server round-trip. Toggle state defaults are documented in the in-app disclosure the first time the app introduces the toggle.

3.5.4 We do not sell to advertisers

Nothing in Section 3.5 permits the sale of user data (individual or aggregate) to advertisers, ad networks, or data brokers. Aggregate statistics under Section 3.5.2 are provided to grocery retailer partners for the sole purpose of demonstrating fulfillment / routing performance under a B2B licensing arrangement. They are not provided to any advertising ecosystem, and they are not brokered.

4. Data retention

Because all app data lives only on your device, retention is entirely under your control:

• In use: data persists in the app's UserDefaults (and, for imported recipes, in the Documents folder) for as long as the app is installed.
• Reset: clearing the app's data (iOS Settings → General → iPhone Storage → Gainplate → Delete App and reinstall) removes all stored preferences, favorites, and imported recipes.
• Deletion: uninstalling the app deletes all Gainplate-owned local data. There is nothing for us to retain because nothing was ever uploaded.
• Backups: if you use encrypted iCloud or iTunes device backups, Gainplate's local data is included in those backups per Apple's standard backup behavior. We do not manage or access those backups.

5. Your rights (CCPA, GDPR, and international users)

Gainplate is designed so that data-subject-rights requests are trivial to satisfy: since we do not collect, store, or process your personal data on our servers, there is nothing for us to hand over, correct, port, or delete on your behalf. Nevertheless, we recognize the rights below and describe how each maps to Gainplate:

• Right to know / access: all data the app has about you is visible inside the app (Profile tab shows body weight, protein target, dietary preferences, favorites, imported recipes, household). No server copy exists.
• Right to deletion: uninstalling the app deletes all data. There is no server copy to also delete.
• Right to correction: edit any field directly in the Profile tab.
• Right to portability: screenshot or export the visible data yourself. We do not lock you into a proprietary format.
• Right to opt out of sale / sharing: we do not sell your personal data to anyone, for any purpose, ever. We do not share individually-identifiable personal data with third parties for their own use. The only category of data that ever leaves Gainplate in a form derived from user activity is the ≥100-user aggregate, anonymized cohort statistics described in Section 3.5.2, and even those are gated behind the Profile → App → Analytics opt-out toggle (Section 3.5.3), which lets you exclude your device from every aggregate cohort at any time.
• Right to non-discrimination: we do not condition access to the app on you providing personal data (there is no login).

These rights are honored regardless of your jurisdiction. If you are in California (CCPA/CPRA), the EEA/UK (GDPR/UK-GDPR), Brazil (LGPD), or elsewhere, the same policy applies.

6. International data transfers

Not applicable. No user-identifying data leaves your device. The third-party HTTPS endpoints listed in Section 2 are called anonymously from your device to whichever regional edge those providers serve — this is a browser-style anonymous fetch, not a data transfer we control or process.

7. Children's privacy

The app is not directed to children under 13 and is not designed to attract them. If you are a parent or guardian and believe your child under 13 has used the app, contact us at the email below — but since Gainplate does not collect any personal information off-device, there is nothing to delete beyond uninstalling the app from that child's device.

The App Store age rating for Gainplate is 4+ because the content is non-objectionable — this is not an invitation for use by children under 13, who should not be using apps that reference macro or weight-based nutrition targets without adult supervision.

8. Security

Data stored on-device is protected by the standard iOS data-protection class assigned to UserDefaults, which encrypts the value when the device is locked. We use HTTPS (TLS 1.2+) for every third-party API call.

9. Changes to this policy

If the data-handling behavior of the app changes (e.g. we add accounts, cloud sync, add a new outbound endpoint, activate the aggregate-partner rollups in Section 3.5.2, or enter into a specific grocery retailer partnership), this policy will be updated and the version, effective date, and last-updated date at the top of this document will change. Where the change is material — including any new event category added to the PostHog catalog, any new category of aggregate export, or any new partner category beyond grocery retailers — the app's on-device disclosure will reflect it before the change ships, and the Profile → App → Analytics opt-out toggle (Section 3.5.3) will continue to govern all outbound analytics data collection.

10. Contact

Privacy questions or requests:
[email protected]

Responses within a reasonable time — this is a solo-developer app, not a support call center.