Privacy policy

Website waitlist

When you join the waitlist, we collect your email address, the form location you used, confirmation status, and email-delivery history. We use a one-way keyed hash of your network address for short-term abuse prevention; we do not store the plain address in the waitlist table.

Why we use it

We use this information to confirm your request, prevent spam, deliver launch news you asked for, honor unsubscribes, and understand whether the launch list is functioning. We do not sell waitlist information or use it for third-party advertising.

Service providers

Vercel hosts the website and app-facing API, Neon stores waitlist and app-security records, Resend delivers email, Apple provides StoreKit subscription and App Attest integrity data, and OpenAI generates optional coach replies and speech. Each provider processes information needed to provide its service and operates under its own security and privacy terms.

The iPhone app

Profiles, routines, check-ins, chats, workout partners, and progress photos are stored in the app’s local storage. Subscription protection separately sends the Apple-signed transaction, a random app-account token, and App Attest security material to Fruit Captain’s service. Fruit Captain does not currently use advertising, analytics, HealthKit, its own user accounts, or cloud profile sync. A user can still receive the app’s built-in offline coaching when the online service is unavailable.

Subscription and app-integrity protection

Fruit Captain verifies paid access on its server instead of trusting a local access flag. The service receives Apple-signed transaction data and may store the product and subscription-group identifiers, Sandbox or Production environment, original and latest transaction identifiers, random app-account token, entitlement status and dates, and the App Attest key-to-subscription binding. Raw signed Apple transaction and notification bodies are not kept; the service stores their verified fields and, for notifications, a one-way payload hash and delivery metadata used to reject replays. If Apple sends a verified Family Sharing transaction notification, Fruit Captain records the event for replay protection but does not use it to create or change paid access. The public production service may also record verified Sandbox notifications, but it does not let a Sandbox entitlement authorize online coaching.

App Attest supplies a public key, attestation object, opaque Apple receipt, and later signed assertions. Fruit Captain may store public-key material, keyed hashes of the app key and installation identifiers, the opaque receipt, assertion counter, environment, status, and timestamps to verify that paid API requests came from the registered app and to prevent abuse. The opaque receipt is stored as unverified input only for a possible future Apple fraud-risk workflow. Fruit Captain does not use that receipt to register a key, verify an assertion, bind a subscription, authorize a paid request, or classify fraud. Current app-integrity checks instead use the verified attestation object, registered public key, one-time challenges, and increasing assertion counters.

The random installation identifier, App Attest key reference, and app-account token are kept in iOS device-only Keychain storage. They are designed to survive an app reinstall on the same iPhone so the app and server identity remain aligned, but they are not moved to another device through backup. Fruit Captain deletes any legacy installation identifier found in UserDefaults rather than adopting it. Uninstalling the app alone may leave these device-only security values available for a later reinstall; Delete All Data explicitly removes them after attempting to revoke the server binding.

Fruit Captain does not currently have its own user account. New purchases use a random app-account token. When Apple includes that original signed token in a verified restored transaction, the app adopts it before synchronizing, so the server can bind the restored subscription without accepting a replacement token. A legacy or otherwise missing-token transaction cannot bind online coaching. Deleting all app data does not cancel or erase the Apple subscription.

Online coaching and generated speech

When an online coach reply is requested, the app sends Fruit Captain’s server the selected coach, the message, up to four recent turns, and only the optional profile, routine, or check-in fields useful for that request. Before contacting OpenAI, the server filters that structured context again based on the conversation subject. The structured first-name profile field is withheld from OpenAI during reply generation and may be added after the reply returns. Message and recent-turn text are sent as written after length validation, however, so they can include a name or other information the user typed; a recent personalized coach reply can also include the name. Users should avoid entering sensitive information. The request format does not accept dedicated fields for height, weight, age, occupation, free-form diet or injury notes, contacts, phone numbers, or photos.

When generated speech is requested, a short-lived server token limits speech generation to the exact coach reply it authorized. That exact reply—which may include a first name added after reply generation—and the server-selected OpenAI voice settings are sent to OpenAI’s text-to-speech service. The validated AI-generated MP3 is returned to the phone. The phone may keep a protected temporary cache so the same line does not need to be generated repeatedly. Built-in iPhone speech remains the offline fallback.

Coach-reply requests use the OpenAI Responses API with response storage disabled. The server also sends OpenAI a pseudonymous safety identifier made from a one-way keyed hash of the app-installation identifier; OpenAI does not receive the plain identifier. The speech request uses OpenAI’s text-to-speech API, which does not use the Responses storage setting. OpenAI may still process or temporarily retain API data for safety and abuse prevention under its API data controls. Fruit Captain’s application code does not write coach request bodies or generated audio to the website database or application logs.

Abuse prevention

Coach and security requests carry a random app-installation identifier. Before rate-limit records are stored in Neon, that identifier and the request’s network address are transformed with a one-way keyed hash. The database does not store those plain values. It does store request identifiers and payload hashes for idempotency, request and usage-unit counts, reserved and actual estimated provider cost, and control timestamps so subscriber quotas and emergency spend limits can be enforced without logging coach conversation bodies or generated audio. Daily maintenance revokes App Attest keys that have been inactive for 180 days and their linked device bindings, reconciles abandoned usage reservations, and prunes older challenges, processed notifications, completed operations, rate limits, and usage buckets. Other retention periods and production deletion procedures will be finalized before launch.

Your choices

Every launch email includes an instant unsubscribe link. You may also ask to access or delete your waitlist record by emailing hello@fruitcaptain.com. App profile data and temporary personalized-media caches can be deleted from the app’s data controls. Delete All Data first suspends and drains background subscription synchronization, then attempts to revoke the current App Attest key and subscription-device binding before clearing the local security identity. Synchronization remains disabled until onboarding is completed again, and the revocation request may not complete while the service is unreachable. Local deletion does not cancel an Apple subscription or automatically delete transaction, notification, integrity, abuse-prevention, or spend-control records that Fruit Captain must retain for security, accounting, legal, or dispute purposes.

Contact

Questions: hello@fruitcaptain.com