Burn · A Campflame app
Burn privacy policy
Your personal records stay on your device and, if you use iCloud sync, in your own private iCloud. Burn keeps no copy. Optional sharing, online searches and purchases have separate data flows and choices.
Effective 14 October 2026.
Who is responsible
Burn is a Campflame app. Contact burn.support@campflame.dev with support or privacy questions. This policy explains the Burn app on iPhone and iPad and this information website. Feature availability can vary by app version. A service described as optional is used only when the feature is available and the relevant conditions below apply.
Your food, weight and Health records
Your profile, food diary, saved foods, meals, recipes, weights, water logs and review history are stored on your device. From Burn 1.2, food entries can also hold extra nutrient values (such as sodium, saturated fat, fibre, sugar, vitamins and minerals) and water logs record the amount and time you log; both are stored, backed up and exported like the rest of your diary. Water goal and water reminder settings stay on the device. If you choose to remember a food selected during AI review, its serving and local search association are saved with your foods for later use. These personal choices are included in your exported Burn backup and can be changed or removed through saved foods. Optional AI meal analysis, when available in your version, has the separate data flow described below. Burn does not require a Burn account and does not upload your personal diary to its analytics, crash-reporting or purchase providers. From Burn 1.1, your personal-record database is included in your iPhone’s or iPad’s own device backups (iCloud Backup or a computer backup), as controlled by your backup settings; Burn has no access to those backups. Temporary safety copies and caches are excluded. Earlier versions excluded the database from device backups. Burn keeps no copy of your diary on a Burn server. You can also export a Burn backup through Files for a separate recovery copy.
iCloud sync. In versions that offer it (Burn 1.2 test builds first), iCloud sync keeps your Burn records the same on the iPhones and iPads signed in to your Apple Account. Your records, including water logs and extra nutrient values, are stored in your own private iCloud database using Apple’s CloudKit, not on a Campflame or Burn server, and Burn has no copy. The content of each record is kept in an end-to-end encrypted field. Apple’s CloudKit still holds technical information about each record, such as when it was created or changed and its size. Imported Apple Health data, restore receipts and other device-only records are not synced. Sync is on by default where it is available and needs no Burn account; turn it off at any time in You → Your data. Turning it off keeps your records on this device and in iCloud. Burn shows the iCloud account state and asks before merging with a different iCloud account. With sync on, Delete all Burn records also deletes your records in iCloud and on your other devices when they next sync. Your iCloud data is subject to Apple’s privacy policy; you can also remove Burn’s iCloud data in your iPhone’s or iPad’s iCloud storage settings.
Older Burn versions may have created week-plan or shopping-list records. Those historical records remain local and can stay in an exported backup, but planning and shopping are not features offered in the current app.
Connecting Apple Health is optional. With your permission Burn reads your height and weight from Apple Health to fill in your starting plan, and your weight, dietary energy, steps, workouts, distances and active and resting energy for your diary and daily burn. Burn never writes to Apple Health. Imported Health data and its source information stay on your device, in your own device backups and in any Burn backup you choose to export. It is not sent to Burn, used for advertising, or included in usage statistics. Disconnect stops refreshes while keeping imported copies; Remove imported Health copy removes Burn’s copies without deleting the originals in Apple Health. Restoring a backup does not reconnect Health.
Backups and local history
You choose where to save exported Burn backups and CSV files. They may contain personal information, including imported Health records. Your chosen storage provider may synchronize or retain them. Deleting records in Burn does not delete exported files.
Importing a backup replaces current personal records. Burn separately retains the latest 50 successful restore receipts on the installation, including dates, format, time zone and record counts. Receipts do not contain individual food or weight values or the backup filename. They survive later restores, are excluded from portable backups, can be exported separately, and are cleared by Delete all Burn records.
Camera, label recognition and food searches
Camera access is optional. You can choose an existing label photograph or enter values manually. Label text recognition runs on your device. Burn saves the food values you confirm, rather than attaching the photograph or raw recognized text to the saved food. Selecting a photo does not delete the original in Photos.
Typing a food name searches on your device. When online search is available, pressing Search or Search online sends your search words to Burn’s food-search service hosted by Cloudflare. Your diary, profile, weight and advertising identifier are not included. Burn does not intentionally log raw search text in its Worker application logs. Connection information, including your IP address, is processed to deliver and protect the service.
When online barcode lookup is available, the barcode is sent to Burn’s product service, which requests product information from Open Food Facts. Your photograph and diary are not sent with that request. Product results may be cached by Burn and its service. Checking for an available food-catalog update downloads catalog information and data over HTTPS without sending your personal records. Catalog-update files are hosted on Campflame’s Sevalla site. The host processes connection and security information to deliver them; Burn’s catalog downloader does not retain or send cookies. These online services are separate from optional analytics consent.
Optional AI meal analysis
AI meal analysis is part of Burn Pro. In versions offering it, you can choose a meal photo, take a new photo, or write a meal description. Choosing a photo alone does not send it for analysis. After your permission and when you tap Review my meal, Burn sends the selected photo and any description through Burn’s Cloudflare service to Z.ai (GLM) for food and portion suggestions. Burn resizes the image and removes embedded photo metadata before sending it; visible people, labels and surroundings in the image remain visible to the service. Your full diary, weight history and imported Health records are not included.
As part of the requested analysis, Burn first checks your confirmed foods and its on-device catalog. When needed, it sends only the relevant food or product search words to Burn’s Cloudflare food-search service to find nutrition and serving records. Your personal saved-food library is not sent. This lookup is covered by the AI meal-sharing choice; it does not require a separate approval for each food. Burn does not intentionally record raw search words in its application logs.
Burn uses Apple’s signed app and purchase information, App Attest device evidence and your RevenueCat App User ID to verify access. Its server checks the corresponding subscription status with RevenueCat. These access checks are separate from the meal content sent to Z.ai. Cloudflare and the relevant providers process connection and security information needed to deliver their services.
Burn’s AI service does not save raw meal photos, descriptions, AI answers or purchase receipts in its database or application logs. It keeps pseudonymous device and subscription references, verification keys, request timestamps and usage/replay records to enforce usage limits and prevent duplicate requests or abuse. Apple Sandbox traffic used by TestFlight or App Review and App Store Production traffic use separate service records, keys and usage limits; a request is routed from Apple’s verified purchase environment rather than a choice in the meal itself. These server records are separate from your diary and are not erased by deleting local diary records. Contact us about information we hold. Provider processing is also subject to the Z.ai API Data Processing Addendum; this is not a promise that all provider-held information disappears immediately.
You review the suggested foods, portions and nutrition before saving. Burn uses compatible food records when available; otherwise it can show clearly marked AI-estimated calories and macros for the proposed portion. AI can miss foods or estimate portions and nutrition incorrectly. Estimated entries retain their estimate attribution in your diary. Saving stores the food entries you confirm on your device, without attaching the meal photo. In versions with remembered AI permission, your explicit first-use choice is saved on this device for the disclosed provider and sharing scope. Change it at any time in Privacy and sharing. A material change to that provider or scope requires fresh permission. Earlier versions ask again for each analysis flow. Closing or cancelling a flow stops that flow from sending further requests; it does not turn off a remembered permission for future meals. Cancelling stops Burn from accepting a late answer but cannot recall information already transmitted or necessarily stop provider processing. Manual food logging remains available without AI sharing.
Usage statistics
Usage statistics (on by default). To understand which features help people and to fix confusing screens, Burn sends anonymous usage events to PostHog: the event name (for example “onboarding step viewed” or “meal logged”), a small fixed property such as the step name, paywall page or logging method, the time, the app version and a random identifier created for this installation. Usage events never include your name, food or meal content, photos, weight, body measurements, Health data, targets or any other health values, and they are not used for advertising or sold. Usage statistics and crash reports are on by default in Burn 1.1 and later. If you used Burn before version 1.1 and never changed either switch, Burn turns both on once; if you changed either switch, or Burn cannot confirm that you never did, your choices stay as you left them. Burn never changes a choice you made. Usage statistics are paused in Support and resources and until you confirm how you use Burn. You can turn them off at any time in You → Your data & privacy → Privacy and sharing. Burn works with sharing off. Crash reports are a separate switch. They are on by default and you can turn them off at any time in You → Your data & privacy → Privacy and sharing.
While usage statistics are on and the service is available, PostHog receives a limited set of feature-use events: opening Burn, the setup screens you view and completing setup, starting and finishing the first scan, how you log food (for example search, barcode, label, quick add, saved food, recent, meal, recipe, plan, photo or description — never what you logged), logging exercise and whether it was typed or described, saving a weigh-in (not the weight), using Undo, AI meal analysis started, finished or failed with a general reason (such as no connection, limit reached or service unavailable), whether a barcode or label was found or read, viewing a check-in and whether the suggested target went up, down or stayed the same, viewing and saving a usable review, viewing or closing each paywall page and where it was shown, purchase or restore flow outcomes, starting a trial or purchase with the plan period, catalog search outcomes, use of saved recipes and the meal planner, being asked for a rating, having a Burn widget installed, logging water and how you added it (quick add, custom amount or a reminder’s notification button), changing your water goal, saving your water reminder settings, opening “About heart labels”, viewing the Heart summary on Today, opening the Vitamins & minerals view, the general area of an error message you saw, and coarse logging-time ranges. Events include time, app version and build number, and random installation and event identifiers. Search events describe the outcome, not the words searched. Review events do not include your target or recommendation. Recipe events do not identify the recipe. Logging-time events use broad ranges. Water events never include an amount, your goal, or your reminder times or on/off choice; the only extra detail is how a water entry was added. The heart and vitamins events only show that the information sheet, Heart summary or Vitamins & minerals view was shown, never any value.
Burn does not send food descriptions, calories, macros, weights, water amounts, nutrient values, photographs or Health records in these events. It does not record your screen, create PostHog person profiles, or request location enrichment. Network services still process connection metadata. Turning usage sharing off clears unsent events and resets Burn’s usage identifier; it cannot recall an already delivered event.
Crash reports (on by default)
While crash reports are on and the service is available, Firebase Crashlytics processes technical crash information, such as installation and session identifiers, crash time, app version, operating system and device details, stack traces and exception information. Burn does not add custom user IDs, diary values, photographs or raw application errors to reports. Burn adds only the name of the tab you were on and, for a few failures that do not crash the app (AI meal analysis, purchase or restore, backup or import, and CSV export), a fixed failure type with no details, personal data or diary values. Burn does not use Firebase Analytics.
Previously queued reports may be shared on a later launch when your saved sharing choice is enabled. Newly enabling sharing discards previously pending reports through the SDK. Crash reports are paused in Support and resources and until you confirm how you use Burn. Burn works with crash reports off. Turning sharing off stops future sharing decisions but cannot recall a batch already accepted for delivery. Firebase states that removal of Crashlytics data from live and backup systems begins after 90 days; this is not a guarantee that all copies disappear on day 90.
Purchases and subscription access
When purchases are available, Apple and RevenueCat process product, purchase, restore and subscription-access information. RevenueCat creates a random anonymous App User ID and processes purchase receipts, subscription status and technical app/device information. “Anonymous” here means you do not need to create a Burn login; the purchase record still has an identifier. RevenueCat may determine country from transactions or an IP address and states that it drops the raw IP after determining country.
Burn does not provide custom subscriber attributes or enable automatic device-identifier collection in its RevenueCat configuration. Purchase verification is separate from optional usage/crash sharing and may occur when the app becomes active. Deleting Burn’s local records does not cancel an Apple subscription or erase Apple’s or RevenueCat’s purchase records. Manage subscriptions through Apple.
Reminders, widgets and ratings
Optional daily reminders request notification permission. Their text does not contain food, weight or calorie values. If you start a free trial and notifications are allowed, Burn schedules one local reminder before the trial ends. When widget access is available, Burn shares a limited daily summary with its own widget extension, including calories, protein, target, completeness and timing information. Anyone who can see your widget may see that summary.
Burn keeps small local records of logging days and rating-request attempts to avoid asking too often. They are excluded from exported backups and are not sent to analytics providers. Apple controls its rating prompt; Burn does not receive your rating from that prompt.
Retention, deletion and your choices
Your personal records remain on your device, and in your private iCloud if you use iCloud sync, until you remove or replace them. This includes historical plan or shopping-list records created by older versions. Delete all Burn records removes personal records and imported Health copies, clears the product cache, resets reminders and rating history, invalidates the widget summary, and turns off optional sharing. If iCloud sync is on (in versions that offer it), Delete all Burn records also removes your Burn records from your private iCloud and, when they next sync, from your other devices. Burn first checks iCloud for entries recently added on your other devices, for up to about 10 seconds, so those are deleted too; if that check does not finish, the deletion still runs and Burn tells you some entries may remain. A short deletion marker with none of the record’s content stays in iCloud for each deleted record. If sync cannot run at that moment (for example you are offline, iCloud is unavailable, or you turned sync off), the deletion reaches iCloud and your other devices when sync next runs, and entries added on your other devices since this one last synced may remain, so delete those on that device. Burn reports a cleanup or saving problem rather than claiming success. Exported files, original Apple Health records and provider-held information are separate.
Temporary usage events are held in memory with age and queue limits. Product-cache age limits are checked during use and are not a promise of immediate physical erasure. Provider-held data follows the applicable service arrangements and retention policies. PostHog’s event retention depends on the plan and whether retention enforcement is active; we do not promise a shorter fixed Burn-specific deadline. RevenueCat purchase retention and Cloudflare network-information retention do not have one universal deletion deadline established by this policy.
Email burn.support@campflame.dev to request information, correction or deletion of information we hold or to ask about your privacy choices. We may need enough information to locate a record and verify the request. Do not send your entire diary, backup, Health records, password or identity documents in your initial message. With random installation identifiers, we may be unable to associate an analytics record with your email alone. Deleting provider purchase history does not cancel an Apple subscription. Applicable law and necessary security or transaction obligations may affect what can be removed.
Providers and this website
Burn uses the providers described above for the relevant available features. They may process information in countries outside your own, under their applicable service and privacy arrangements. We do not sell your personal diary or use Health data for advertising.
These privacy and support pages are part of campflame.dev, hosted by Sevalla. We add no analytics script, advertising tracker, contact form or account system to these pages. The hosting provider processes connection and security information needed to deliver the website. See the Campflame website privacy policy. Emailing support shares your email address, message and any attachments you choose to send with our support mailbox provider.
Adults, estimates and contact
We may update this policy when Burn’s features or data practices change. The current version and effective date appear on this page. For privacy or support questions, contact burn.support@campflame.dev. Burn’s guidance features are intended for adults; Support and resources provides a non-prescriptive alternative. Calorie targets and expenditure estimates are guidance, not medical advice or a diagnosis. Ask a qualified clinician about dietary changes for a medical condition.