Privacy Policy — Rascalorie

Effective date: 7 August 2026 Last updated: 13 September 2026

Rascalorie ("the app", "we", "us") is operated by Yury Atrashkevich, Afrikis 26, 3052 Limassol, Cyprus. Questions, requests, complaints: hello@rascalorie.com.

The operator is an individual, not a company. That changes nothing about the obligations in this policy: an individual publishing a paid app is a data controller in the same way a company is, and the household exemption in data-protection law does not apply to commercial activity.

The short version

We keep as little as we can. Your food log lives on your phone; it only reaches our server if you create an account, and then only so it can sync to your other devices. We do not sell your data and we do not run ads — there is no advertising SDK in this app and no advertising identifier is ever read. We do use two ordinary tools to keep the app working: crash reporting and product analytics, both described in §7, neither of which receives your email, your food log or your photos. Some feature inputs leave your device when you use them: photos you take of meals or menus (sent to our AI provider so it can read them, along with a short summary of your goal and how many calories you have left), food names you search for (sent through our API to Open Food Facts), and your location (sent to mapping services when you open Places). They are explained below. You can export or delete everything from inside the app.

1. What we collect, and why

If you use the app without an account, your profile, food log, weights, sleep, water and settings are not stored by us as account or sync data. Inputs still pass through our API when you deliberately use a connected feature such as AI estimation, food search or Places; §§2–4 describe exactly what those features send.

If you create an account, we collect and store:

• Your email address and a password hash (scrypt — we never store the password itself).
• A session counter that lets us revoke your sign-ins. The session token itself is signed rather than stored: we keep no copy of it, and it lives in your phone's Keychain. Changing your password or deleting your account moves the counter, which kills every existing session at once.
• Your synced app data: profile (sex, age, height, current and target weight, activity level, goal, pace, whether you drink alcohol), your calorie-budget choice (Recommended or Custom, including the Custom value), food journal entries, logged movement, weights over time, sleep and water entries, saved foods, meal templates, food preferences — including any likes, dislikes and allergens you enter — the per-day diary ledger used to remember whether food exists and which calorie target, target mode and status applied to that day, a count of the deals you have accepted, and app settings. (Recipes you generate stay on your device and are not sent to us.)
• Subscription status (free, trial, Pro) — see §5.

We use this only to run the service: to calculate your calorie budget, to show your history and trends, to sync between your devices, and to give you support when you write to us.

Network and security data. Like any internet service, the hosting edge and our API receive your request IP and basic transport metadata when the app or rascalorie.com contacts them. The API validates that address and keeps it only in bounded, in-memory rate-limit buckets to prevent abuse and protect account, AI and lookup endpoints. We do not write those buckets to the application database or turn the address into a city, region or coordinates. Apple's privacy form treats this security use as Device ID / App Functionality; the hosting providers that carry the request are listed in §6.

We ask before any of it leaves your phone, and we enforce that on our side. Creating an account requires you to tick a box naming exactly what will be stored — journal, targets, weights, water, sleep, activity — and the version of that statement is recorded with a timestamp on your account. Simply signing in on a new phone is not treated as agreement: our sync endpoint refuses to send or receive your health data at all until a current agreement exists, and if we ever change the wording materially, you are asked again rather than being assumed to have agreed to the new text. Declining leaves the app fully usable — everything keeps working, it just stays on that device, and a new phone starts empty.

We also confirm the address before any of it leaves the phone. Signing up sends you a six-digit code, and until it is entered your log stays on this device: the cloud copy and the data export are both refused. Everything else works normally. The reason is a plain one — a mistyped address at signup would otherwise put your food diary, your weights and your body data on an address somebody else controls, and that somebody can ask us for a password reset. Buying a subscription is not gated this way; the risk here is your data, not your payment.

You can see the record of what you agreed to, and when, in your data export (§10).

Legal basis (EU/UK): performance of the contract you enter into by using the app (Art. 6(1)(b) GDPR), and your explicit consent for health-related data (Art. 9(2)(a) GDPR).

Withdrawing it does not cost you your account. Settings has a Cloud sync switch: turning it off withdraws that consent, and our server then refuses to send or receive your health data in either direction — the app keeps working, on this phone, exactly as before. Next to it is a separate Delete cloud copy button, because stopping and erasing are two different wishes: one leaves what we already hold in place, the other removes it and leaves your account, your subscription and this phone's journal untouched. Deleting the whole account is still there, and is still the only thing that removes everything at once.

What deleting your account actually does, stated plainly: it removes everything we hold on our servers, and it also clears the app on the phone you did it from — the journal, weights, water, sleep, saved foods and templates. We do it that way because the alternative is worse: a phone that keeps one person's food diary after they have deleted their account, on a device someone else may pick up. The confirmation dialog says the same thing before you tap it, and there is an Export my data button one row above it. Use that first if you want to keep a copy — we cannot give it back afterwards.

There is one deliberate exception, and we would rather name it than have you find it: we keep your email address by itself, with a counter, in a small deletion record. It holds nothing else — no journal, no weights, no profile — and it exists so that a session token issued before the deletion can never be used against that address again if you, or anyone else, registers it later. Ask us at hello@rascalorie.com and we will remove that record too; the only thing you give up by asking is that protection.

1a. The launch waitlist

If you leave your email on rascalorie.com before the app is out, here is the whole row we store: the address, the date, the three campaign tags from the link that brought you (source, medium, campaign), the site that referred you — the domain only, never the page or the search you typed — your browser's language (en, ru: the language alone, not the country, and only so the launch email is written in a language you read), the two consent fields plus the opt-out mark described below, and — because we ask you to confirm the address by clicking a link we email you before it counts — the bookkeeping for that confirmation step: whether and when you confirmed, a one-time confirmation token stored only as a hash and when it expires, when the confirmation email was sent, when its latest delivery attempt began, whether our email provider accepted it, how many attempts have been made, when another retry is allowed, and whether the single immediate human retry has been used. If an address previously opted out and asks to join again, the row also records whether that fresh re-subscription is still waiting for inbox confirmation and whether its retry state has already been reset for that re-subscription. None of that is any more about you than the address you already gave us. Nothing else is added to the waitlist row: no name, no device, no stored IP address or browsing history. The signup request still passes through the network/security handling described in §1, but its IP is never joined to the waitlist record. Rascalorie sets or reads no product or advertising tracking cookie; the hosting edge may still set the strictly necessary security cookie described in §6. The page keeps the campaign tags in your browser's session storage only so they survive you clicking around before you sign up; they are gone when you close the tab.

We use it once, to tell you the app is out. Legal basis (EU/UK): your consent (Art. 6(1)(a) GDPR), given by submitting the form. So that consent is a record and not a claim, we also store which version of the sentence printed under the form you agreed to, and when — that is the only reason those two fields exist.

Taking yourself off it. The launch email carries a one-click unsubscribe link, and it does not expire. You can also write to hello@rascalorie.com at any time. When you unsubscribe we keep the address marked as withdrawn rather than deleting the row outright, for one reason: a deleted address is silently re-added the next time an older copy of the list is loaded, and we would have no way to know you had told us to stop. If you would rather the address were erased entirely, say so in that email and it will be.

The waitlist lives in a separate table from app accounts and is never joined to one — someone who signs up for the app later is a new, unconnected record. Once the launch email has gone out the list has served its only purpose and we delete it by hand, keeping only the withdrawn-address markers described above, so that a list re-imported from an old backup cannot quietly put someone back on.

2. Photos and AI processing — please read this one

When you photograph a meal or a menu, that image is sent to our AI provider so it can estimate calories or read the menu. The same applies to meal descriptions you type.

So that the answer fits your day, the request also carries a small amount of context about you: your sex, your goal (lose, keep, gain), whether you drink alcohol, how many calories you have left today, the tone setting you chose for Cardio, the language the app is set to (so the answer comes back in it), and any food likes, dislikes or allergens you entered. It does not carry your email, your name, your weight history or your food journal.

• The image is transmitted for processing and the result is returned to you. We do not store your photos on our servers.
• Our AI provider processes the image on our behalf as a sub-processor (§6).
• We ask for your consent before the first photo or description is sent. Until you agree, nothing is sent: the app shows you what will leave your device, who reads it, and that we do not keep it. Declining costs you nothing. Manual logging, the barcode scanner, food search and your weight trend all keep working.
• You can withdraw that consent at any time in Settings, under "AI processing consent". Withdrawing stops any further sending; it does not retroactively unsend something already processed, and you will simply be asked again the next time you use an AI feature.

Please do not photograph other people, documents, or anything you would not want processed by a third party.

2a. Food database lookups

When you search the food database by name, the words you type are sent through our authenticated API and then to Open Food Facts so it can return matching nutrition records. Our API can associate that request with the guest session or account that made it; Open Food Facts receives the search term from our server, not your app account identifier. Apple calls searches performed in the app Search History, so our label declares this as linked data used for App Functionality.

We do not add the search term to your journal unless you choose and log a result, and we do not send it to PostHog. It is not stored in our application database. The query string is stripped from every Sentry error report; the hosting edge and origin may still process the requested URL as ordinary transport metadata (§6). A barcode lookup follows the same route, but sends the barcode rather than words you searched for. If Open Food Facts has no match and our optional fallback is configured, the barcode is also sent to USDA FoodData Central. Neither provider receives your app account identifier.

3. Apple Health

If you turn it on, we read three values from Apple Health: step count, active energy burned, and body mass. We never write to Apple Health, and we request no write permission.

Active energy can extend the calories available today. Imported body mass informs your weight trend and may inform the Recommended budget; neither value changes a Custom base that you set. Steps are shown as activity. In line with Apple's rules, health data is never used for advertising, marketing or data mining, and it is never sold or shared with third parties for their own purposes. You can revoke access at any time in iOS Settings.

Where it goes. Two of the three become part of your ordinary log and are therefore synced like the rest of it (§1) if you have an account and have agreed to sync: the day's active energy total, and any weigh-in we import. Step counts are never sent anywhere — they are read to draw a number on your screen and nothing else. Without an account, or without that agreement, none of it leaves the phone.

4. Location

When you open the Places tab, the app uses your device location to find places near you and show how far away they are. Your coordinates are sent to:

• our own server, which forwards a nearby-search to Google Places;
• OpenStreetMap Overpass for place search when Google is unavailable;
• CARTO for map tiles.

These are your actual coordinates rather than a coarse region, because that is what a nearby-search needs, and our App Store privacy labels say so. The app reads your location only while you are using it: it asks for no background location permission and does no background tracking. We do not store your coordinates on our servers and we keep no history of where you have been — including in crash reports, where the address the app called is recorded with everything after the ? stripped off, precisely so that a search you ran cannot ride along inside a bug report.

5. Payments

Subscriptions are billed by Apple, not by us. We never see your card details. We receive from RevenueCat (our subscription infrastructure provider) an identifier and your entitlement status — whether you have an active trial or subscription — so the app can unlock Pro.

6. Who processes data for us (sub-processors)

The application origin and database are located in New York, United States (DigitalOcean, NYC1 region); the CDN may handle a request at an edge location before forwarding it there. We are based in the EU, so for users in the EEA/UK this includes international transfers. Where a transfer safeguard is required, the applicable mechanism is the one documented for that provider and service in its current terms and data processing agreement (for example, Standard Contractual Clauses or the Data Privacy Framework only where it actually applies). Provider-by-provider safeguards remain subject to DPA and legal verification before launch; this policy does not make a blanket claim that every provider uses or is certified under the same mechanism.

App Platform includes its Cloudflare-powered CDN as part of the hosting path. We do not operate a separate Cloudflare DNS zone, analytics product or advertising service for Rascalorie. The edge may set a strictly necessary security/bot-management cookie on browser requests. That operational edge cookie is separate from the optional PostHog product analytics in §7: it may be set before you make an analytics choice, but Rascalorie does not read it for product analytics, advertising, cross-service tracking or user profiling.

7. Crash reporting and product analytics

We use two third-party tools to keep the app working. Both are deliberately configured to receive as little as possible, and neither is used for advertising or shared with advertisers.

Crash reporting — Sentry. When the app or our server hits an error, a report is sent to Sentry containing the error message, the stack trace, the app version, and the device model and OS version. This includes handled or nonfatal failures that would otherwise disappear, plus limited server operational warnings, not only app crashes. Sentry also sends automatic app-session/release-health signals — including an app launch and build — so we can see whether a release stays crash-free. Apple's form classifies those signals as Product Interaction and Performance Data, and the handled/operational reports as Other Diagnostic Data; all are used only for App Functionality. A report does not include your email address, your food journal, your weight, your photos, or the contents of any request you made — request bodies, headers, session tokens and the query string of every address the app called are all stripped before the report is sent. That last one is deliberate and specific: a crash report records which addresses the app had just called, and one of them is the map search that carries your coordinates, so everything after the ? is removed and only the path is kept. We do not enable Sentry's screenshot or view-hierarchy capture, because a screenshot of this app is a picture of your food journal and your weight.

Product analytics — PostHog. Analytics are off until you choose otherwise. We do not interrupt first run with an analytics or tracking prompt. If you want to help improve the product, you can voluntarily enable Settings → Anonymous usage stats later. Nothing at all is sent — not even an "app opened" — before that switch is enabled, and leaving it off costs you no functionality. You can turn it off again at any time.

If you enable it, we record a small, fixed list of events. This is the complete list, and it is the same list the app's own code enforces:

• app opened — the denominator every other rate is measured against
• setup finished — with no profile answers attached
• first food described
• a meal logged — only the broad entry door and whether the estimate or portion was changed; no food, meal slot or calorie figure
• an AI meal request submitted and its request finished — only whether it was text or photo, whether it was an initial request, clarification, correction or retry, its bounded attempt number and elapsed time, whether a photo answer used the primary or fallback route, and a fixed outcome such as food, clarification, timeout, offline or invalid response; never the request, image, answer, recognised food, calories, provider name, model name or provider prose
• a clarification shown or answered, an estimate correction opened or submitted, and a detected component toggled — only the broad action and whether the original input was text or photo
• a camera or photo-library step — only camera/library and whether permission was granted, denied, a picture was selected or cancelled, or local preparation failed; never the picture or its metadata
• a barcode scan started and its catalogue lookup finished — only a bounded attempt number, elapsed time and whether it hit a locally saved item, hit the catalogue, was not found or was offline; never the barcode or product
• a food-database search started, finished and a result selected — only elapsed time, a coarse result-count bucket, whether the request returned results, was empty, offline or superseded by more typing, and whether the selected row was catalogue, saved or frequent; never the query, food or result text
• meal artwork resolved — only whether the AI meal used a matched bundled sticker or the generic fallback; never which sticker or food
• a deal offered, an option chosen, a deal accepted, a deal declined, a declined deal reopened, and a deal reaching its end — never which option, whether it was kept, or any planned/measured activity; an accepted-deal event may carry only its ordinal count (first, second, and so on)
• calorie-target editor opened, calorie target saved, and calorie target rejected — only the entry point (Home or Settings), whether the saved target is recommended or custom, or a fixed rejection reason; never the target you entered, the safety-floor number, your sex, or any profile answer
• day detail opened and past day changed — only a broad recency bucket (today, yesterday or older), the source screen, and for a change whether it was an add, edit, delete or move; never an exact date, food text, meal slot, calorie figure, Health value or journal contents
• came back the next day, and came back a week later
• subscription screen viewed — with which screen led there; and subscription-screen actions such as selecting monthly/annual, continuing, dismissing, loading products, starting/cancelling/failing/verifying a purchase, retrying verification or restoring a purchase — only the action and monthly/annual choice, never a price, storefront, receipt or payment details
• an account-flow action — only start, completion, failure or dismissal and the generic signup, login, verification or password-reset step; never the email, password, code or error text
• places opened and a places action — only that the Places screen was used, and which kind of action followed (a place card opened, a route started, a walk or loop logged, a menu scanned, an external maps app opened); never a place name, an address, coordinates or any other location data
• a coach verdict shown, a verdict changed, and a meal declined after a verdict — only whether the draft fit or exceeded the day's budget, whether a checkbox or portion changed it, and the broad logging door; never the food, its calories or the size of the excess
• a coach-slot state and a coach reply shown — only which generic slot voice appeared; never the food text, budget, remaining calories or journal contents
• an onboarding step reached, a plan budget edited, and a plan surplus warning shown — only the generic step or budget direction; never profile answers, weights, sex, calorie values or target date
• a meal undone and a meal deleted — only that the action happened; never which meal, its text, calories, meal slot or journal day
• a bonus offered, a bonus taken, a bonus collected, a bonus put down, and a bonus dissolved — only which of the app's fixed bonus prompts it was (a generic name such as "walk after breakfast" or "Friday afternoon"); never the minutes, calories, steps, the weekly bank or any journal contents. The one bonus prompt that is triggered by an Apple Health step count is never reported at all, under any name, so no Health-derived fact reaches the analytics service

From our server, and only when Apple tells us a purchase happened, two more: a trial started and a subscription paid. Those purchase events may carry the product or plan identifier, billing period, store, and whether a renewal converted a trial; they do not carry payment-card details.

Events carry only product-flow context such as which app door was used, whether an estimate was corrected, or which screen led to the paywall — plus the app version and build number, so releases can be told apart. They never carry the text you typed, the name or category of a food, a meal slot, calories or macros, a deal option or outcome, planned or measured activity, age, weight, a photo, or a location. We do not use PostHog's automatic event capture, and we do not use session replay or any form of screen recording. Like any internet service, PostHog sees the request IP while receiving an event; every client and server event explicitly disables GeoIP enrichment, so that address is not converted into a city, region, country or coordinates in the event or person profile.

How you are identified in both. Product analytics uses a random identifier generated on your device and — once you have an account — a random account identifier. Sentry has no account identifier before signup and is then given that same random account identifier. Neither is your email address, and neither is an advertising identifier or a device identifier assigned by Apple. Because we read no advertising identifier and do not track you across other companies' apps or websites, this is not "tracking" as Apple defines it. We do, however, hold the mapping between that random account identifier and your account, so under Apple's definitions this data counts as linked to you — and our App Store privacy labels and privacy manifest say so. Apple's privacy form also categorizes the random per-install pseudonym as a Device ID, even though it is not assigned by Apple and is not an advertising identifier. Not being able to link it would be a stronger promise, and it would not be true.

Legal basis (EU/UK): your consent (Art. 6(1)(a) GDPR) for product analytics — the Settings switch is off by default, and enabling it is the affirmative choice that permits the first event. You can withdraw that choice at any time in Settings → Anonymous usage stats, with no effect on anything else in the app, or by writing to hello@rascalorie.com. Crash reporting rests on our legitimate interest in keeping the app from crashing (Art. 6(1)(f)); it carries no journal content, no email and no request bodies.

Retention: crash reports and product events are kept for up to 12 months, then deleted by the providers.

8. What we never do

We do not sell or rent your data. We do not run advertising. We do not use advertising identifiers. We do not use your health data, your photos or your food log for any purpose other than providing the features you asked for. If we ever add another third-party SDK, this policy will be updated before that change ships and the app version notes will say so.

9. How long we keep things

Your food journal is kept on the device for the last 120 days; account data is kept on our server until you delete your account. When you delete your account, your server-side data is removed from the live database — apart from the small deletion record described in §1, which holds your address alone and which we keep until you ask us to remove it. Our database provider takes automatic daily backups with a seven-day recovery window, so a copy may persist in those backups for up to seven days after deletion before rolling off. Email logs held by our email provider follow their own retention.

Three shorter clocks run on their own, without anyone having to ask:

• One-time email codes (password reset, address verification) are deleted as soon as they expire, and in any case within two hours.
• Anonymous "try it free" sessions and the AI-usage counter attached to them are deleted 90 days after they are created. They hold no journal and no email — only a random id and a number.
• Deletion markers inside your synced data — the records that tell your other phone you deleted a saved food, rather than letting it come back — expire after 90 days.

The IP rate-limit buckets described in §1 are never written to the application database. They remain only in the running server's bounded memory: an expired window is replaced if that address returns, least-recently-used entries are evicted as the map reaches capacity, and the whole map disappears whenever the process restarts.

10. Your rights and how to use them

Inside the app, in Settings, you can:

• Export your data — a copy of your account record and all of the synced data listed in §1, in JSON. (It does not include internal counters such as how many AI checks you used today, or records held by the providers in §6, for example email-delivery logs. Ask us and we will supply those too.)
• Delete your account — this removes your account and its synced data from our servers and clears the app on the phone you do it from, for the reason set out in §1. Export first if you want a copy.

You may also ask us to correct data, restrict or object to processing, or withdraw consent, by writing to hello@rascalorie.com. We answer within 30 days. If you are in the EEA/UK you have the right to complain to your local data protection authority; if you are in California, you have rights under the CCPA/CPRA, including the right to know and delete — we do not sell or share personal information as those terms are defined there.

11. Security

Passwords are stored as scrypt hashes. Sessions use signed tokens that we can revoke (a password reset or an account deletion invalidates every existing session). Traffic runs over TLS. No system is perfect, but we keep the amount of data we hold deliberately small so there is less to lose.

12. Children

Rascalorie is for adults. It is not intended for anyone under 18, and the app does not allow an age below 18 to be entered. We do not knowingly collect data from children. If you believe a minor has created an account, write to hello@rascalorie.com and we will delete it and the data behind it.

13. Changes

If we change this policy we will update the date above and, for anything material, tell you in the app before it takes effect.

Contact: hello@rascalorie.com — Yury Atrashkevich, Afrikis 26, 3052 Limassol, Cyprus.