This Privacy Policy explains how Kcal Ledger (the “App”) handles information when you use the App. If you do not agree with this policy, please do not use the App.
Your meal, exercise, body-metric, goal, favorite-food, report, and saved analysis records are stored in a local SwiftData store on your device. They are not synchronized to our server, and the App does not use iCloud or CloudKit for these records. Removing the App may remove this local data unless you made a separate backup.
Starting with App version 3.0.0, food catalog downloads use your existing App session to obtain short-lived download authorization and a decryption key. The service processes catalog versions and package identifiers to complete the download. Your meal records, search terms, meal categories, and selected options are not sent through this flow. Downloaded catalog data is cached in encrypted form, excluded from device backups, and decrypted in memory using keys stored in the system’s secure storage. Hosting services may process ordinary connection and security logs. App version 2.2.1 and earlier do not include food catalog downloads. Earlier versions used only for internal testing do not use this download method.
With your permission, the App reads selected Health data on your device, such as date of birth, biological sex, height, weight, and active energy, to prefill profile information, estimate daily energy needs, or synchronize activity energy. The App does not write to Health data, and raw samples are not directly uploaded to our server. Access to HealthKit data follows Apple's HealthKit guidelines. We do not use HealthKit data for advertising or sell it to third parties. You can change Health permissions at any time in iOS Settings › Privacy & Security › Health.
If you request exercise analysis, the request may include selected profile and body-metric values—such as weight, height, body-fat percentage, muscle mass, basal metabolic rate, and a body-metric note—after the App presents the analysis consent disclosure. These values are used only to complete that request.
When you choose an analysis or report feature, the information needed for that request is encrypted in transit, sent through our server, and forwarded to a third-party processing service. Depending on the feature, this may include:
This information is used to identify food or exercise, estimate nutrition or energy expenditure, and generate the analysis or report you requested. Except for the eligible short meal-text cache described below, request text, photos, and submitted report data are not retained as a long-term server-side copy of your records. To deliver a completed request reliably and let the same request retrieve its result after a network interruption, the complete analysis or report result may be stored temporarily in a server-side delivery buffer for up to about 48 hours by default, then cleared.
For eligible short meal-text requests that pass the service’s privacy filters, our server uses a shared analysis cache to reduce repeat processing and wait time by allowing a later equivalent request to reuse an existing result. The cache key uses a non-reversible hash and version information and is not linked to your account identifier. The cache stores the complete reusable analysis result and, when a matched food reference is included in its context, may also contain the short text you submitted. Cache entries currently have no fixed automatic expiration and may remain indefinitely until they are overwritten or removed. Photos, exercise inputs and body metrics, and report inputs are not stored in this shared cache.
Results are estimates for tracking and reference and may be inaccurate. Do not submit highly sensitive identifiers or complete financial account information.
Food catalog authorization uses the existing session activity timestamps and renewal process without creating a personal catalog download history. Download tickets last five minutes and contain no account identifier. Application logs do not record tickets, decryption keys, or complete authorization responses. Hosting platforms may still process download URL query strings and ordinary security logs; complete ticket masking in these platform logs is not guaranteed.
We retain operational product-interaction data linked to your account, such as request time, feature type, usage and cost fields, and success or failure status. This data supports the requested features, credit accounting, abuse prevention, service reliability, and aggregate analytics. We may also use information as needed to comply with law or respond to lawful requests in applicable jurisdictions. The operational record itself does not contain the request text, photo, or complete response. Routing records for meal-text analysis may include the recognized store, item, and serving names and reference source URLs (see Section 7). The temporary delivery buffer described in Section 4 is handled separately.
When you click an App Store button in the navigation, hero, or footer of kcalledger.com, the website sends only the fixed button placement and page language. Our server adds the click to an anonymous daily aggregate using the server’s UTC date. This measurement sets no cookie, creates no user or device identifier, and stores no IP address, browser or device information, or full referrer in the analytics data. Repeat clicks by one person count more than once, so the total is neither an install count nor a unique-visitor count. Daily aggregates are retained for 400 days and then removed in fixed-size batches. These limits describe this website click measurement only; hosting and network providers may still process ordinary connection and diagnostic logs for operations, security, and abuse prevention.
A third-party diagnostics service may receive crash reports, performance data, device type, operating-system version, and App version. These diagnostics are not linked to your Kcal Ledger account.
Daily usage counts. Starting with version 3.0.0, the App sends daily usage counts linked to your account: how many times you opened the App, how many meal records you added by each method (text or photo analysis, manual entry, nutrition-label scan, favorites, recent foods, repeat, or the food catalog), and the App version (including build number) and install source (App Store, TestFlight, or a development build). Our server also records onboarding completion and how many times an AI analysis or report was blocked because of insufficient credits. These records are kept as one row per account per day and contain only the date and counts: no meal content, item names, photos, or nutrition values, and no time of each action (the server keeps only the times it first and last received that day’s counts). We use them to understand feature usage and improve the App, and delete them in batches after 400 days. When you add a record from the food catalog, our server also adds to a daily total per store; this total contains no account identifier and no item.
Store wishes. When you submit a request to add a store in the food catalog, we store the store name and the optional “what you usually order” text you entered, together with your account identifier, the submission time, whether the store name was filled in from your search text, the App version (including build number), the install source, and the language. We use these requests to decide which stores to add next. They are not shown to other users or displayed back in the App, we do not reply individually, and they are deleted in batches after 400 days. Please do not enter personal information or contact details in these fields.
Advertising and cross-app tracking are not used, and no third-party behavioral analytics module is enabled.
Secret keys for third-party processing services are configured only on our server and are not embedded in the App. The App contains only the access key used to connect to our server and public identifiers for third-party SDKs.
You may manually back up and restore your App records using the private app-data area of your own Google Drive account. The App requests only the drive.appdata scope. Backup and restore are user-initiated; the App does not automatically upload records in the background, and the backup does not pass through our server.
When you connect Google Drive, the App reads the email address from your Google sign-in profile and displays it on your device so you can identify the connected account. The email address is used only in the device’s Google authorization state; it is not included in the backup or sent to our server.
The backup is compressed and transferred over HTTPS but is not additionally encrypted by the App. Anyone who can access the relevant private app-data area of your Google account may be able to read its contents. You can use the App without connecting Google Drive, sign out in the App, or revoke access from your Google account.
You can delete individual local records in the App or remove the App from your device. You can delete your account from Settings → Delete Account; after confirmation, the App clears local App data and signs you out, and our server handles account-linked data as follows:
To ask us to delete the content of App feedback, report feedback, or a store wish you already sent (for App feedback, the message and contact information you entered; for report feedback, the feedback text you wrote; for a store wish, the store name and usual-order text you entered), email support@kcalledger.com with enough detail for us to find that feedback, such as the approximate time you sent it and a summary of its content, for report feedback, which weekly or monthly report it was about, and for a store wish, the store name. We will handle the request after confirming it. Some purchase, transaction, security, or legal records may be retained where required for accounting, fraud prevention, dispute resolution, or compliance.
Because the shared analysis cache described in Section 4 is not linked to an account identifier, deleting your account cannot identify and remove a specific cache entry. Its retention follows the cache rules described in Section 4.
Google Drive backups are controlled through your Google account. Revoking the App’s authorization does not necessarily delete an existing backup; manage or remove it using the controls available for your Google account.
The App is not directed primarily to children below the applicable legal age. If you believe we collected a child’s information by mistake, contact us; we will review the request and delete or otherwise handle the information as required by applicable law. Records we must retain by law and the shared analysis cache described in Section 4, which is not linked to an account, are handled as described in Section 7.
We may update this policy. Material changes will be identified in the App or on this page, and the date above indicates the current version.
For privacy questions or requests, email support@kcalledger.com.