Legal
Privacy Policy
Astyq keeps your saved nutrition diary on your iPhone and keeps advertising attribution separate from health data.
Effective September 4, 2026
The short version.
Your saved diary, frequent foods, goals, and profile are stored locally in the app. If you enable AI processing, the meal text or short voice recording needed for that request is sent through Astyq’s backend to OpenAI. Usage Analytics remains disabled and unavailable in this release. Build 12 adds limited first-party Apple Ads attribution so Astyq can tell which Apple Ads campaign, ad group, and keyword led to a new Production subscription. It does not use IDFA, request ATT permission, or include your meal, diary, profile, goal, or voice data. Astyq does not sell personal data or use it for targeted advertising.
See the separate Consumer Health Data Privacy Policy for the categories, recipients, and rights that apply to meal, nutrition, weight, goal, and related AI-generated information.
1. Who we are
Astyq is operated by Gennadii Dobretsov, an individual developer established in Kazakhstan and identified as the seller of the Astyq application on its Apple App Store product page (“Astyq,” “we,” “us,” or “our”). This policy applies to the Astyq iOS application, the website at getastyq.com, and support communications.
For privacy questions or requests, email privacy@getastyq.com.
2. Information handled by Astyq
Information stored on your iPhone
Astyq stores the following inside the app’s local container:
- meals, ingredients, weights, calories, macronutrients, meal times, and the time zone recorded with a meal;
- frequently used meals and their local usage counts;
- nutrition goals and profile details you enter, such as height, weight, age, sex, average steps, and weight goal;
- language, country, regional formats, appearance, onboarding status, AI-processing permission, and your separate analytics choice;
- a draft of an interrupted AI request, when needed to offer retry after the app restarts.
Astyq does not sync this saved diary, profile, or goal data to the Astyq backend. Apple may include the app’s local container in an iPhone or computer backup depending on your Apple backup settings.
Information used for AI meal analysis
If you explicitly enable AI processing and submit text, Astyq sends the meal description, input type, language/locale, time zone, request time, a random request identifier, a Firebase authentication token, and an App Check token to the Astyq backend. The backend sends the meal description and relevant locale/date context to OpenAI to prepare an editable draft. Firebase tokens, your saved diary, profile, goals, and open request identifier are not sent to OpenAI.
Information used for voice transcription
If you explicitly enable AI processing and record a voice entry, Astyq sends the temporary M4A audio recording, selected language, a random request identifier, a Firebase authentication token, and an App Check token to the Astyq backend. The backend passes the audio and language to OpenAI for transcription. The recording is held in memory by the Astyq backend only for the synchronous request and is not written to Astyq application storage.
Anonymous account and security data
Astyq uses Firebase Anonymous Authentication. Firebase assigns a persistent random user identifier without asking for your name, email address, or password. Firebase App Check and Apple App Attest help confirm requests come from a genuine Astyq installation. Astyq’s backend creates pseudonymous request-control records for duplicate prevention, rate limiting, fraud prevention, and cost protection. These records use keyed hashes rather than raw Firebase identifiers, meal text, audio, or AI results.
Free AI allowance and subscriptions
Astyq provides a limited number of successful AI meal analyses to each Firebase anonymous guest account. The backend keeps a pseudonymous counter and short-lived reservation records so concurrent or repeated requests do not use the allowance incorrectly. Voice transcription does not reduce this counter, but AI access may require either remaining free analyses or an active subscription.
Apple processes subscription purchases and payment details. When you purchase or restore Astyq, the app sends the Apple-signed transaction and, when available, Apple-signed renewal information to the Astyq backend. The backend verifies the signature and stores the minimum normalized subscription state needed to provide access, process renewals, grace periods, refunds or revocations, and restore the subscription after reinstall. Astyq does not receive your payment-card details and does not intentionally store the full signed transaction or notification. Transaction lineage, notification, and guest-account identifiers are stored as keyed hashes rather than raw values. A verified restore may associate the same active Apple subscription lineage with more than one eligible Astyq guest installation without moving access away from an already eligible installation.
Apple Ads attribution
Build 12 uses Apple’s AdServices framework to request an opaque attribution token after the app has established its anonymous Firebase account. Astyq sends that token through its authenticated backend to Apple only to learn whether Apple attributed the installation to an Astyq Apple Ads campaign. The token is handled in request memory and is not intentionally stored or logged. Apple’s response may also contain a campaign country or region and, when available under Apple’s privacy controls, a rounded click or impression time; Astyq does not retain those fields.
If Apple returns an attributed result, Astyq keeps only allowlisted Apple organization, campaign, ad-group, keyword, ad, conversion, claim, and placement identifiers as an immutable first-touch record associated with the pseudonymous guest account. When that guest later starts a newly verified Production subscription, Astyq records at most one conversion for that subscription lineage. TestFlight and other Sandbox transactions, renewals, duplicate notifications, and restores of subscriptions purchased before the attribution are not counted again. If the guest account is deleted, Astyq removes the guest-linked attribution and conversion details but retains a one-way keyed-hash marker for that subscription lineage, without guest, campaign, keyword, or product details, only until the original 180-day expiry so an immediate restore cannot be counted as a second conversion. These records are kept separate from meal, diary, nutrition, profile, goal, voice, and optional PostHog data.
Diagnostics and network information
Google Cloud may process standard request metadata such as IP address, user agent, route, response status, and timing when delivering the backend. Astyq application logs include server-generated request IDs, route/status, timing, model/provider, and token counts, but do not intentionally log Firebase tokens, meal text, audio, prompts, transcripts, or AI drafts.
Optional product analytics remains disabled
Product analytics is disabled and unavailable in this release, so the app sends no PostHog events and shows no Usage Analytics setting. If a later build offers Usage Analytics, it will remain off by default and will not interrupt meal logging with a prompt. Only after you explicitly turn it on may Astyq send a manually selected set of product-interaction events to PostHog EU Cloud in Frankfurt, Germany, under a random identifier created for that app installation. Those events would help us understand the consenting-user journey through meal entry, draft review, confirmed logging, paywalls, purchases, restores, and later app use. Each selected event also includes the app version, build number, and fixed versions of the first-run activation and paywall experiences so we can compare whether a product update improves or harms those flows.
Astyq does not call PostHog’s identify function and does not send your name, email address, Firebase user ID, Apple transaction identifier, advertising identifier, meal text or names, ingredients or notes, voice recordings or transcripts, calories or macros, weights, diary dates, profile or goal values, authentication/security tokens, request identifiers, full error messages, or provider responses. Session replay, automatic event capture, automatic screen capture, interaction capture, crash/error capture, and surveys are disabled. The app marks every selected event to disable GeoIP enrichment, and the PostHog project separately discards the source IP rather than storing it. Astyq does not send the device model, operating-system version, locale, carrier, network, or screen recording as analytics context.
Website and support
The public website is delivered by Cloudflare. Astyq does not use advertising pixels, cookies, forms, or web analytics at launch, and the website does not load PostHog. Cloudflare may process basic network and security information to deliver and protect the site. If you email support or privacy, we receive your email address, message, and any attachments you choose to send. Please do not send medical records or information that is not needed to answer your request.
3. Why we use information
- to store and display your nutrition diary locally;
- to transcribe voice and create an editable meal draft when you request AI processing;
- to authenticate requests and protect the service from abuse, duplicates, and excessive use;
- to enforce the free AI allowance, verify paid access, restore purchases, and process subscription lifecycle events;
- to measure which Astyq Apple Ads campaigns, ad groups, and keywords lead to a new Production subscription and prevent duplicate conversion counting;
- with your separate permission, to measure product flows and improve Astyq using selected non-content interaction events;
- to operate, secure, troubleshoot, and improve reliability;
- to answer support, privacy, and legal requests; and
- to comply with law and protect users, Astyq, and others.
4. Service providers and disclosures
We use the following providers to operate Astyq:
| Provider | Purpose | Information involved |
|---|---|---|
| OpenAI | Meal analysis and voice transcription | Submitted meal text, locale/date context, or submitted audio and language |
| Google Cloud and Firebase | Backend hosting, authentication, app verification, request controls, logs, and secrets | Anonymous user ID, security tokens, request metadata, pseudonymous control records, and the AI request in transit |
| Apple | App distribution, App Attest, device permissions, subscription purchases and lifecycle, Apple Ads attribution, and optional device backup | App/device attestation data; Apple-signed product, transaction, renewal, status, and timing information; an opaque AdServices token and allowlisted Apple Ads identifiers; and information Apple handles under your Apple account, advertising, and payment settings |
| Cloudflare | Website delivery, DNS, security, and email routing | Website request/security metadata and routed email metadata/content |
| PostHog EU Cloud | Optional product analytics for consenting users | Random install-scoped identifier and selected non-content product-interaction events; hosted in Frankfurt, Germany |
We require providers that process personal information for Astyq to protect it consistently with this policy and applicable agreements, and we do not authorize them to use it for unrelated purposes. Providers may perform the limited security, abuse-prevention, or legal processing described in their applicable terms.
We may also disclose information when required by law, to respond to valid legal process, to protect safety or rights, or in connection with a business reorganization. We do not sell personal information, share it for cross-context behavioral advertising, or permit third-party ad tracking in Astyq.
5. Measurement and your choices
Apple Ads attribution is limited to measuring Astyq’s own advertising on the App Store. It does not use IDFA, request ATT permission, follow you across other companies’ apps or websites, or provide Astyq with your Apple ID. It is separate from the optional PostHog feature described below and is not used to personalize advertising.
Product analytics is unavailable in this release. When offered in a later build, it requires a separate, voluntary choice and is off by default. It is not required to use Astyq, AI meal analysis, the local diary, or a subscription. If Usage Analytics is available, you can change the choice later in Astyq Settings. Turning it off immediately stops future analytics collection, then clears events waiting on the device and resets the local analytics identity. If device storage interrupts that cleanup, analytics remains off and cannot be enabled again until the cleanup succeeds. Turning it off does not recall events already uploaded.
Already uploaded events remain subject to the PostHog project’s retention and deletion controls. Because Astyq does not attach an account, email address, or other directly identifying profile to those events, we may be unable to locate a particular installation’s historical events from an email request. No fixed Astyq retention period is stated here until the production project setting is confirmed.
6. AI processing and your permission
AI processing is optional. Before the first AI request, Astyq identifies OpenAI and describes the categories sent. You may choose not to enable it and continue using the local diary and manual/quick entry features. You may turn it off later in Settings. Turning it off prevents new AI requests and cancels local handling of an in-flight response, but cannot recall information already sent for processing.
AI output is an estimate and remains an editable draft. It is never saved without your confirmation and cannot independently edit or delete existing diary entries.
7. Retention
| Information | Retention |
|---|---|
| Local diary, frequent meals, profile, goals, and settings | Until you delete the information, delete your account and data in Astyq, or remove the app; device backups follow your Apple settings |
| Temporary voice and export files | Deleted by Astyq after the operation and during later cleanup; iOS may also clear temporary storage. Copies you share follow the recipient app’s rules |
| Firebase anonymous account | Until you use Delete Account and Data, or Firebase removes it under applicable service settings |
| Free-analysis quota and current guest subscription bindings | Debited request keys are bounded by the applicable allowance and remain with the guest account so the same request cannot consume twice; rare no-debit markers expire logically after 24 hours. Astyq deletes the quota, completed keys, and that guest account’s current subscription binding when in-app account deletion succeeds. Other eligible guest installations linked by a verified restore are not detached. A keyed-hash deletion marker then blocks already-issued tokens for 2 hours and is eligible for asynchronous Firestore TTL deletion |
| Minimal Apple subscription lifecycle record | Kept separately from the current guest account while needed for the active subscription, renewal, grace period, refund or revocation handling, legitimate restore, disputes, and applicable accounting or legal obligations. Astyq currently has no automatic TTL for this lifecycle record |
| Full Apple-signed transaction, renewal, or notification payload | Used in memory for verification and not intentionally stored or logged by Astyq |
| Keyed-hash App Store notification identifier and processing timestamps | 180 days for duplicate and ordering protection; after logical expiry, enabled Firestore TTL deletion may take approximately another day |
| Apple Ads first-touch and Production-subscription conversion records | 180 days, followed by asynchronous Firestore TTL deletion that may take approximately another day. In-app account deletion removes the current guest’s first-touch record and the conversion record owned by that guest |
| Pending new Production-subscription attribution record | Up to five minutes to reconcile the safe race where purchase verification finishes before Apple Ads attribution; removed sooner when resolved or by in-app account deletion |
| One-way keyed-hash subscription-lineage dedupe marker, with no guest, campaign, keyword, ad, or product details | Only until the deleted conversion’s original expiry, no longer than 180 days from first-touch capture, followed by asynchronous Firestore TTL deletion |
| Pseudonymous request-control records | Completed/failed request states expire logically from 10 minutes to 24 hours; rate-limit counters in less than 3 days. Firestore’s asynchronous physical deletion may take approximately another day, so allow up to 4 days |
| Astyq operational logs | 30 days. Provider-required administrator/audit logs may be retained up to 400 days and are not intended to contain meal text or audio |
| Optional pseudonymous product-analytics events | Unsent local events expire after seven days. The local queue and analytics identity are cleared when analytics is turned off or the Astyq account/data is deleted. If device storage interrupts that cleanup, analytics remains off and cannot be enabled again until the purge succeeds. Events already uploaded to PostHog are not erased by that local action and remain until removed under the PostHog project’s retention/deletion controls; a fixed Astyq retention period has not yet been confirmed |
| OpenAI meal-analysis data | Astyq sends Responses API requests with storage disabled. Under OpenAI’s default controls, eligible requests may leave encrypted prompt-cache state for up to 24 hours, and content may still appear in abuse-monitoring logs for up to 30 days, or longer when legally required or reasonably necessary to prevent harm |
| OpenAI transcription data | OpenAI’s published default table lists no application-state or abuse-monitoring retention for the Audio Transcriptions endpoint; service/system metadata may still be processed under OpenAI’s policies |
| Support and privacy emails | For as long as needed to respond and keep necessary support, fraud, or legal records, ordinarily no longer than 24 months |
More information about OpenAI API data controls is available in the official OpenAI documentation. Third-party retention may change; we update this policy when a change materially affects Astyq users.
8. Your choices and rights
- AI choice: enable or disable AI processing in Astyq Settings.
- Analytics choice: product analytics is disabled and unavailable in this release. If a later build offers it, the separate setting will be voluntary and off by default.
- Apple Ads attribution: Astyq does not use IDFA or cross-app tracking. Delete Account and Data removes the current guest’s owned attribution and conversion details before their normal expiry; only the detail-free one-way lineage marker described above remains until its original expiry to prevent duplicate counting.
- Edit and delete meals: manage saved entries directly in the local diary.
- Export: create a Markdown copy and choose where to send it through Apple’s share sheet.
- Delete Account and Data: remove the Firebase guest account and Astyq local data from Settings.
- Subscription: view, restore, manage, or cancel an App Store subscription using Apple’s purchase and subscription controls.
- Privacy request: contact us to ask about access, correction, deletion, or other rights available where you live.
Because the account is anonymous and the diary remains on your device, we may be unable to locate or verify local diary data from an email address. In-app deletion is the direct method. See Privacy Choices for instructions.
Deleting an Astyq guest account does not cancel an App Store subscription. Astyq detaches only the deleted guest account from the subscription and removes that guest’s owned Apple Ads attribution/conversion details, while retaining the detail-free dedupe marker and minimal Apple lifecycle record described above. Other eligible installations remain attached. Manage or cancel the subscription through Apple. A later verified restore may attach an active subscription to a new Astyq guest account.
Account and Data deletion also stops future product-analytics collection, clears queued events on the device, and resets the local analytics identity. It does not automatically erase pseudonymous events already uploaded to PostHog, which follow the retention and deletion limits described above.
9. Children
Astyq is not directed to children under 14, and the current profile flow does not accept an age below 14. Astyq does not knowingly collect personal information from a child below the minimum age permitted by applicable law. A parent or guardian who believes a child provided information may contact us.
10. Security and international processing
Astyq uses encrypted HTTPS connections, Firebase Authentication, App Check/App Attest, restricted service accounts, secret management, body-size limits, and pseudonymous request-control records. No system is completely secure. Optional PostHog product analytics is hosted in Frankfurt, Germany. Other service providers may process information in the United States and other countries under their applicable safeguards and terms.
11. Health and medical information
Food, weight, activity, and nutrition information may be treated as consumer health data in some jurisdictions. Astyq handles it as described in this policy and the separate Consumer Health Data Privacy Policy. Astyq is a nutrition logging tool, not a healthcare provider, and is not represented as a HIPAA-covered service. Do not use Astyq for emergencies, diagnosis, or treatment decisions.
12. Changes to this policy
We may update this policy as Astyq changes. We will update the effective date and provide additional notice in the app when required. If a material change affects optional analytics or AI recipients, data categories, or purposes, Astyq will request permission again before new collection where required.