JST Fitness — Privacy Policy

Last updated: 21 August 2026

JST Fitness is a workout, nutrition and body-weight tracker for Android. This policy explains exactly what the app stores, what leaves your device, and what it never touches.

The short version: your training data lives on your phone. The app has no analytics, no advertising, no trackers, and nothing is sold or shared with third parties. One thing can be shown to other users of the app, and only if you choose it, food by food: a food you added yourself — the product's label facts, never your log and never your name (section 6 below). Everything that leaves your device is listed in full below.

This policy has been corrected several times as the app changed. Every one of those corrections is recorded, in full, in Changes to this policy at the bottom of this page.

Who is responsible for your data

JST Fitness is built and run by one person, who is the "data controller" in GDPR terms — the person responsible for what happens to your data and the person to write to about it:

Tristan Allard Email: [email protected]

There is no company behind the app, no data protection officer (none is required at this size), and no EU representative.

What is stored on your device

By default, everything the app records stays in local storage on your phone and is never uploaded:

• Workouts, routines and workout history (sets, reps, weights, notes)
• Body-weight log, body measurements and BMI history
• Meals, calorie and macro targets, saved foods, water intake
• Goals, achievements, XP and streaks
• Your profile (name, height, sex, activity level, birth date if you entered one) and app settings (theme, units, timezone)
• Meditation sessions you record with the timer
• Your profile photo, if you set one
• Weekly report summaries — the averages and totals the app writes for itself when a week ends, keeping the 26 most recent (the weekly report is on unless you switch it off)

Uninstalling the app removes all of this from your device.

What leaves your device

There are seven. Five happen only when you take a specific action and are entirely optional; one is automatic — a short diagnostic report sent when the app hits an error, so it can be fixed. The seventh is neither optional nor numbered below: the demonstration clips your phone streams while you use the workout library. It is described at the end of section 1, with the rest of the library.

1. Account and cloud sync — only if you create an account

If you sign up or sign in, JST Fitness uses Supabase as its authentication and database provider. Your email address and an account identifier are stored there. Passwords are handled and hashed by Supabase; the app never stores your password.

If you sign in with Google instead, Google returns your email address and basic profile information to create the account.

If you create an account, most of what the app records is synced to the cloud so it follows you between your phone and your computer. That covers:

• Body — your weight log, your waist/chest/arm measurements, your saved BMI/BMR/TDEE figures and the height/age/sex you entered to calculate them.
• Training — your workout history (every exercise, set, rep and weight you log — and, for timed intervals, the seconds you worked), your saved routines, any custom exercises you create, and your weekly training schedule. If you fill in the optional "Following" line on a session — a class, a channel, a video title or a link you paste — that text is part of the session and syncs with it. The app only stores and shows it: it never loads the page, never fetches a thumbnail, and never tells anyone you watched anything.
• Food — your meal and water log, your daily water goal, your saved foods, any homemade recipes you build (their names, ingredients and yield), and your calorie and macro targets.
• Progress — your goals, unlocked achievements and when you unlocked them, your XP and level, and the list of days you opened the app (which is what your streak counts).
• Profile — the name you entered, your date of birth, and display preferences: your step goal, which graph the home screen shows, whether the rest timer is switched on, and your measurement units (kilograms or pounds — added 7 August 2026; before that, units stayed on each device). (The rest timer's sound, vibration and notification switches stay on the device — see below.) Profile basics — sex, date of birth, height, weight — are asked for by the setup quiz because the calorie and macro maths cannot run without them; they stay on your device unless you make an account and consent to sync.
• Your consent record — which version of the sync-consent wording you agreed to and when. Stored with your account as the legal proof the consent was given (GDPR Article 7(1)).
• Your plan — whether your account is a beta founder, when your free trial started and ends, and — once subscriptions launch — whether a subscription is active and which tier. This record lives on our server and the app can only read it; writes from the app are refused, which is what makes founder status and trial dates unforgeable. The app keeps a small copy on your device so your plan still shows when you're offline. This record is about your account, not your body: it holds no health data.
• Appearance — the theme and colour scheme you chose, so the app looks the same on every device you sign in to.

These stay on your device and are never uploaded: your step counts from Health Connect, your meditation log, your profile photo, the weekly report summaries listed above, and your device settings — timezone, accessibility mode, the rest-timer sound, vibration and notification switches, the follow-along runner's countdown sound and buzz, and whether a new set's boxes start pre-filled with what you lifted last time. Two marks the app keeps about its own walkthrough stay here too: whether it has already offered the walkthrough to you, and which of its chapters you have ticked off. They record what has been read on this phone, and they are not in your backup file either, so a new phone simply offers the walkthrough again.

The meditation log deserves its own sentence, because it is the one thing here we decided to keep off our servers rather than merely happening not to send. Every meditation you record — its length and the day you sat — stays on the phone it happened on, even if you have an account and sync is switched on. It is in your backup file, so it is still yours to keep and move. Nothing is asked about how you felt, and there is nowhere in the app to say.

One honest exception, because leaving it out would make the paragraph above a promise we do not keep. Three achievements are earned from that log — your first sit, ten days sat, and five hundred lifetime minutes — and unlocked achievements do sync, along with the date each one unlocked. So while the log itself never reaches us, the fact that you have passed one of those three marks does, with a date. Nothing else about your practice reaches us: not a single session, not its length, and not which days you sat.

One small side effect, named rather than hidden. Sitting earns XP like everything else in the app, so the number of days you have sat is part of your level — and your level is one of the counts attached to a feedback message. That only happens if you tick the "include usage" box, which is off unless you turn it on, and the app shows you every number before you send it. Your level is a single figure that adds workouts, active days, completed goals, unlocked achievements and days sat together; it is not a record of your practice, and one number that several things went into cannot be unpicked back into any of them.

If you never create an account, none of the data described above is sent to Supabase — your fitness data stays on the device.

Two other things do leave it, whether or not you have an account, and both are described in full below: the demonstration-clip requests in the next paragraph, and the automatic error diagnostics in section 4. Neither carries your fitness data. The diagnostics are on by default, and you can switch them off.

The first of those: exercise demonstration videos are streamed from our hosting (Supabase) when you open an exercise in the workout library, show the demo during a workout, or run a follow-along circuit — which streams the clip for each station in turn, and fetches the next one a few seconds early so it is ready when that interval starts. Like any video stream, each request necessarily carries your IP address. It is not linked to an account, and we build no record of which demos you watch. Like every request, they appear briefly in our hosting provider's routine server logs, which age out on their own; because a circuit fetches its clips in order, those short-lived logs would briefly reflect the shape of a session. Nothing reads them and nothing is kept.

2. Barcode lookups — only when you scan a product

When you scan a food barcode, the barcode number is sent to Open Food Facts (openfoodfacts.org), a free public food database, to retrieve that product's name and nutrition information. The request carries nothing that identifies you or this app — just the barcode.

The request carries no account information or other app data — but like any request your device makes over the internet, it does reveal your IP address to Open Food Facts, along with the barcodes you choose to look up. Open Food Facts is a French non-profit and its own privacy policy applies to what it receives.

Nutrition data returned by Open Food Facts is contributed by its community and is used under the Open Database License (ODbL).

3. Password safety check — only when you choose a password

When you create or change a password, the app checks whether it appears in known public breach datasets using Have I Been Pwned.

This uses the k-anonymity range API: the app computes a SHA-1 hash of your password locally and sends only the first five characters of that hash. Your password, your full password hash, your email address and your identity are never sent. The service cannot determine which password was checked.

You can decline to use an account at all, in which case this never runs.

4. Error diagnostics — automatically, when the app hits an error

If the app hits an error, it sends a short diagnostic report to our own Supabase database so we can find and fix the problem — including for people we can't otherwise reach, like someone testing the web version. Unlike the three above, this one is not something you trigger; it runs automatically whenever something goes wrong.

A report contains:

• the error message and its technical stack trace
• which screen it happened on, the app version, and whether it was the web or Android build
• your browser's user-agent string (device/OS context)
• a randomly-generated diagnostic id, used to tell one device's errors apart from another's

It is not designed to include your name, email, or anything from your weight, workout, meal, or goal data — none of those are ever attached on purpose. One honest caveat: a stack trace is whatever text the failing code produced, and in rare cases an error message can embed a fragment of something you typed (for example, a value that failed to save). That is a side effect, not a collection channel: reports exist solely to fix bugs — never for advertising, profiling, or sale — and they age out quickly (below).

A word about that id, because "anonymous" would be too strong a word for it. The id is a random string that contains no name, no email and nothing about you — but it is stored on your device and reused, which makes it pseudonymous, not anonymous. If you later send feedback with your email attached, the same id rides along with it, and the account-deletion sweep uses exactly that link to find and delete your crash reports. Data that can be connected to you is personal data, and it is treated as such.

You can turn this off. Settings → Preferences → "Send crash reports" stops the app sending any error report from that device. Reports age out and are deleted after 30 days.

5. Feedback you send us — only when you use "Send Feedback"

Settings → Send Feedback sends us what you type, plus the app version, whether you're on web or Android, your browser's user-agent string (the same device/OS line section 4 describes), and the same diagnostic id described above. Nothing is sent unless you write a message and press Send.

The form shows you exactly what is attached before you send, and you can remove either extra with one tap:

• Your email address, if you are signed in, so we can reply to you. This one is attached by default — a bug report we can't reply to helps nobody. The form carries a "Send without my email address" tick box, left unticked, and tells you underneath exactly which address is going with the message. Tick it and no email address is attached, and we won't be able to reply. If you are not signed in, there is no email to attach.
• How you use the app — off by default, attached only if you tick the box: counts and settings only — number of workouts logged, routines, custom exercises, scheduled days, your level, your units/theme choices, and whether accessibility mode is on.

The usage option never includes your weight, measurements, meals, goals, or the contents of any workout — counts only, never what you logged.

Feedback is kept until your message has been dealt with, and for at most 12 months; once a message is marked handled, an automatic purge deletes it 90 days after it was sent.

6. Foods you choose to share — only when you switch sharing on

If you have an account, a food you add to the food list yourself can be shared with every other user of JST Fitness. Sharing is off for every food unless you switch it on, one food at a time, and only a packaged food with a barcode can be shared. Nothing here happens without an account, and nothing happens for a food you never switched on. A food you looked up from Open Food Facts cannot be shared this way — it already lives there, under its own licence.

What is published — the product, and only the product: its name, brand, serving size, barcode and the calorie and nutrition figures you typed from its label. Other users see it in their food list marked "Community", the way they see the app's own catalogue rows, and they can log it and report it. What they do with it never comes back to you.

What is never published: your name, your email address, your account, the fact that you were the one who shared it, whether you have ever eaten it, or anything from your food log — no dates, no quantities, no meals. There is no profile, no contributor name and no "shared by" line anywhere in the app.

What we keep privately, and why. Beside each shared entry our database keeps an internal reference to the account that shared it — not your email address and not your account id, but a scrambled value derived from it. It exists so that we can act on a report, correct a pattern of bad entries, and block an account that keeps submitting them (sections 5 and 10 of the Terms). It is never shown to anyone, inside or outside the app, and it is cut when you delete your account: the entry stays in the list, because other people's logs may already use it, and nothing on our servers connects it to you any more. The same happens if you switch sharing off again for a food you already shared. Because we could trace a scrambled reference back to you while your account exists, it is personal data, and it is treated as such — the same footing as the diagnostic id in section 4. Earlier versions of an entry are kept when it is corrected, so that what changed can be seen; they carry the same reference and lose it the same way.

What you agree to when you switch sharing on is set out in section 9 of the Terms: you dedicate the entry to the public, so it can be used by anyone, corrected, passed on to public food databases such as Open Food Facts, and kept after your account is gone.

Reports. Any user can report a shared entry from the food list. A report sends us the entry's identifier, the reason you picked, any note you typed, the app version and the same diagnostic id a feedback message carries. Your email address goes with it only if you type it in: leaving it lets us tell you what we did; leaving it blank means you will not hear back. Reports are kept and deleted on the same schedule as feedback (below).

The legal bases, if you're in the EU or UK

The GDPR requires a stated legal basis for each thing done with your data. Here they are, purpose by purpose:

• Cloud sync of your fitness and health data — everything the account section above lists, including your weight, measurements and meals — rests on your explicit consent, given when you create an account and agree to sync. Health data gets the strictest treatment the GDPR has (Article 9), which is why nothing syncs unless you choose to make an account. You can withdraw the consent at any time: Settings → Preferences → "Sync my data to the cloud" pauses all uploading without deleting anything, and deleting your account withdraws it permanently. So that we can prove the consent was given (Article 7(1)), your account's cloud data includes a small consent record — which wording you agreed to and when.
• Creating and running your account — your email address, password handling, sign-in — rests on performance of a contract: it is the thing you asked for by signing up.
• Error diagnostics rest on our legitimate interest in finding and fixing bugs. The reports are minimal, deleted after 30 days, and Settings → Preferences → "Send crash reports" turns them off.
• Feedback you send, and a report you make about a shared food, rest on your consent, given by pressing Send after the form has shown you exactly what goes with the message.
• Sharing a food you added with other users rests on your consent, given by switching sharing on for that food after the app has told you, beside the switch, what is published and what is not. You can withdraw it by switching sharing off again or by deleting your account; either cuts the link between you and the entry, which is the only part of it that is about you. The entry itself — a product's label facts, dedicated to the public under the Terms — carries nothing about you once that link is cut, and stays.
• Barcode lookups and the password safety check rest on performing what you asked for: each runs only when you trigger it, sends the minimum described above, and stores nothing about you.

Who processes your data, and where

These are the companies that handle data for this app, or that receive requests directly from your device — and, last, the one group of people who can see something you chose to share:

• Supabase (a US company) — runs the database and sign-in system that hold your account and everything you sync. Supabase is our processor: it stores and serves your data so the app works, on our instructions and not for its own purposes. The formal contract that belongs underneath that — Supabase's standard data processing agreement — is not signed yet. Signing it, and naming the hosting region here, are both on the list before the app leaves private beta. The transfer paragraph below says the same thing about the same gap.

• Vercel (a US company) — hosts the web version of the app and these policy pages. Like any web host, it receives your IP address and standard request logs when you open the web app.

• Resend (a US company) — delivers the emails the app sends about your account: the password-reset link, and the address-confirmation link when you create an account. It receives your email address and the contents of those messages, and nothing else. It is never sent your weight, your food log, your workouts, or anything else the app holds. Resend is our processor: it sends on our instructions and not for its own purposes.

• Google — if you sign in with Google, Google processes that sign-in and returns your email address and basic profile to the app. On Android, Google also provides the barcode-scanning screen and Health Connect, both described elsewhere in this policy.
• Open Food Facts (a French non-profit) — receives the barcode you scan and, as with any web request, your IP address. It is an independent service you choose to query, not a processor working for this app.
• Have I Been Pwned — receives the first five characters of a hash of your candidate password, and nothing else.
• Other users of JST Fitness — not a company and not a processor, but the one place data goes because you chose to send it there: a food you added and switched sharing on for is shown to every other user of the app, as the product's label facts and nothing about you (section 6). Nobody outside the app receives it from us; if we ever pass shared entries on to a public food database, it will be under the public-domain dedication the Terms describe, still with nothing about you attached.

International transfers. Supabase and Vercel are US companies, so data they handle may be stored in, or accessible from, the United States. The mechanism for that transfer is the standard contractual clauses in each provider's data processing agreement, and the EU-US Data Privacy Framework where the provider is certified. Those agreements are not yet in place; completing them is on the pre-launch list, and this paragraph will name the date once they are.

Health Connect and step counts

If you grant permission, JST Fitness reads your daily step count from Android's Health Connect (which is where Samsung Health and other fitness apps share their data).

Before the app asks Android for permission, it shows you a screen setting out exactly what follows. In summary:

• What is read — your step counts, and nothing else. Not heart rate, sleep, weight, workouts or any other health data. For earlier days this is the daily total. For TODAY, while the hourly breakdown is open, the app also reads the individual step entries your phone or watch recorded, so it can show you which hours you moved in. Those hourly entries are read while you are looking at them and are not saved — only the daily totals are kept.
• How far back — today and the previous 29 days, read in one go rather than repeatedly.
• What it is for — showing you your own steps inside this app: the step ring and daily total on the home screen, the last-7-days chart, today's hour-by-hour breakdown when you tap the ring, and the daily numbers in your history calendar. The distance and calorie figures beside them are rough estimates derived from the step count.
• How long it is kept — each day's TOTAL is saved in the app's own storage on your device and is not trimmed. The hour-by-hour detail is never saved at all: it is read from Health Connect while you have that view open and is gone when you close it. That is deliberate: Health Connect only keeps about 30 days, so after that our copy is the only record of your history. It stays until you uninstall the app or clear its data, and it is included if you export your own backup file.
• Never uploaded, never shared — your step data is never sent to our servers. It is excluded from cloud sync even when you have an account, it is never shared with anyone, and it is never used for advertising or sold.

The app requests read access to steps only. You can revoke this at any time in Health Connect's settings, and the app continues to work without it. JST Fitness does not write any data back to Health Connect.

Barcode scanning and the camera

JST Fitness itself holds no camera permission at all. When you scan a barcode, the scanning screen that opens is Google Play Services' own on-device scanner: Google's software runs the camera, and the app receives only the decoded barcode number. No photo is ever captured by or handed to the app, so there is nothing camera-related for it to store or transmit.

Locking the app with your fingerprint

If you switch on Lock the app, JST Fitness asks Android to check your fingerprint before it opens. Android does the checking, not the app. Your fingerprint was enrolled with your phone, it is held in secure hardware on the device, and no app can read it. JST Fitness is handed one of two answers — it matched, or it did not.

The app never receives your fingerprint, never asks for it, and has no way to reach it. So there is nothing fingerprint-related for it to store, sync, upload or put in your backup file. Nothing about this feature reaches our servers.

Two limits worth stating plainly, because it would be easy to assume otherwise:

• It is a shutter, not a safe. It keeps the app closed until the check passes. It does not encrypt anything, and it does not change what is stored on your phone or what syncs to your account.
• The check is your phone's, so any fingerprint saved on that phone will open it. If someone else's fingerprint is enrolled on your device, it opens JST Fitness too.

The setting is off unless you turn it on, it only appears if your phone has a fingerprint enrolled, and it applies to that phone alone — it does not follow your account to another device.

What the app does not do

• No advertising and no ad identifiers
• No third-party analytics, and no usage or behavioural tracking
• No location tracking
• No sharing or selling of personal information — a food you choose to share carries none (section 6)
• No contact list, SMS, or call log access

Your data and your choices

• Export — the app can export a full backup file of your data.
• Delete local data — uninstalling removes everything stored on the device.
• Delete your account and your data — from inside the app at Profile → scroll to the bottom → Delete Account. You are asked to type DELETE to confirm. This immediately and permanently removes your account and sign-in credentials; all synced data on our servers (weights, workouts, routines, custom exercises, measurements, meals, goals, achievements, streaks and profile details); any feedback you sent with your email address attached, including that address; and crash diagnostics linked to the devices that feedback came from. The app also erases its copy on the device you delete from.

Three limits on that, stated plainly:

• Feedback sent "without my email address" is deleted when we can find it — and we usually can. Every feedback message carries the device's diagnostic id even when your email doesn't. If any other message from that device did carry your email, the deletion sweep uses that link to find and delete the email-less messages too. A message from a device that never sent identified feedback is one we cannot connect to you, and it stays in our feedback list as unattributed text — email us a description if you want a specific one removed.
• Your other devices are not wiped remotely. We have no way to reach out to a phone or laptop and erase it. Once the account is gone, those devices simply stop syncing — but whatever was already downloaded stays on them until you sign out, uninstall the app, or use your system's "clear app data".
• A food you chose to share stays shared. The entry — the product's name, brand, serving, barcode and label figures — stays in every user's food list, because their logs may already use it and because you dedicated it to the public when you shared it. What deletion removes is the private link between the entry and your account, so nothing on our servers connects it to you.

There is no grace period and no archive — a deleted account cannot be restored. If you want to keep your data, use Profile → Settings → Backup & Restore → Back Up Data first.

Crash diagnostics that were never linked to any feedback of yours contain no name or email, cannot be matched to you (the diagnostic id is the only hook, and nothing ties it to your account), and may be kept for stability analysis until they age out at 30 days.

Some older accounts were created before the app required sign-in, and exist only on the device that made them. Nothing about those accounts is sent to our servers, and deleting one erases it immediately. The app no longer offers a way to create one.

• Anything else — contact the email below to request deletion of the account and any synced data.
• Revoke permissions — Health Connect access can be withdrawn at any time in Android's settings. (There is no camera permission to revoke — the app never holds one; see the barcode section above.)

Your rights

If you are in the EU/EEA or the UK, the GDPR gives you the rights below. They are honoured here for everyone, regardless of where you live:

• Access — ask for a copy of everything held about you. The in-app backup export covers the fitness data you synced; your consent record, your plan record (founder / trial / subscription status), feedback and crash reports held on the server, and the list of foods you have shared, can be requested by email.
• Rectification — correct anything that is wrong. Everything the app syncs is directly editable in the app. A shared food is corrected by sending a new version, or by emailing us; earlier versions are kept as a record.
• Erasure — delete your account and its data, from inside the app or by email, as described above (a shared food's link to you is cut — section 6).
• Restriction — ask for your data to be held but not used while a dispute or correction is being sorted out.
• Objection — object to processing based on legitimate interest. In this app that means the error diagnostics.
• Portability — receive your data in a machine-readable format. The backup export is a plain JSON file you can take anywhere.
• Withdraw consent — at any time, without affecting the lawfulness of what was done before. Deleting your account withdraws the sync consent entirely. Switching sharing off for a food withdraws that consent.
• Complain to a supervisory authority — you can lodge a complaint with your local data protection authority. That right is yours no matter what this page says — though writing to the address below first will usually get things fixed faster.

To use any of these, email the address at the bottom of this page. Requests are answered within one month.

How long data is kept

• Everything stored on your device — until you uninstall the app or clear its data. It is your copy, on your hardware.
• Your account and synced data — until you delete your account. Deletion is immediate and permanent; there is no archive. The one exception is an account being wound down (see "Children and under-18s" and section 10 of the Terms): during that notice period the data is kept, and only so that you can still export it.
• One thing outlives every deleted account, and this is it. When the paid tier launches, every new account gets one 10-day free trial. To make "one" mean one, we keep a record that the email address you signed up with has already had its trial — otherwise deleting an account and signing up again would hand out an endless supply of free trials, and everyone else would be paying for it.

We do not keep your email address to do this. What is stored is a one-way keyed hash of it: a scrambled value that cannot be turned back into your address, produced with a secret key that never leaves the database. It can answer exactly one question — "has this address had a trial before?" — and nothing else. It is not linked to your name, your account, or anything you recorded in the app, and none of your fitness data survives with it. These records are deleted after 400 days.

We considered doing this by IP address instead and decided against it: an IP is shared by everyone in a house, an office or on public wifi, so it would wrongly refuse trials to people who had never had one — and an IP tells us far more about you than the hash does.

• A block outlives a deleted account too — but only where a block was placed. An account, a device or a network can be blocked for attacking or abusing the service, which is the case section 10 of the Terms describes. The block list keeps the identifier that was blocked and a short note about why. It has to outlive the account, or deleting the account and signing up again would lift the block. It holds no name, no email and nothing you recorded in the app, and if you were never blocked there is no record of you in it at all.
• A food you chose to share outlives it too — without the link to you. Shared entries stay in the community food list for as long as that list exists, after the account that shared them is deleted, with the internal reference to that account removed. They are product facts, and they carry no name, no email and nothing from your log. Reports about a shared entry follow the feedback schedule below.
• Error diagnostics — deleted automatically after 30 days.
• Feedback — kept until your message has been dealt with, and for at most 12 months. Both limits are enforced automatically in the database, not by hand: a nightly job deletes handled messages 90 days after they were sent, and deletes anything at all once it is 12 months old.

California residents (CCPA)

JST Fitness is a free app run by one person. The rights the CCPA grants to California residents are honoured here:

• Nothing is sold or shared, as the CCPA defines those words. The app carries no advertising, no ad identifiers, no data brokers and no cross-context behavioural advertising, so there is no "Do Not Sell or Share" link — there is nothing for it to switch off. That describes the app as it stands on this page's date; it is not a promise about every version that will ever exist. If it stops being true, this page will say so before it takes effect, the link will appear, and anyone with an account will be asked to agree again first.
• Choosing to share a food you added is not a sale or a share in the CCPA's sense either: no money or other value changes hands, nothing is used for advertising, and what other users see is a product's label facts, not information about you.
• What is collected is exactly what this policy lists. There is no second, longer list.
• Know, delete, correct — the access, deletion and correction routes described above are open to everyone, California included.
• No discrimination — exercising any of these rights costs you nothing and changes nothing about how the app works for you.

Requests: the email at the bottom of this page.

Children and under-18s

JST Fitness is for adults: you need to be 18 or older to use it. The app is not directed at children or teenagers and does not knowingly collect information from anyone under 18.

The reason is what the app does. It sets calorie and macro targets and can be pointed at losing weight, and those are not things it can do safely for someone who is still growing.

If we learn that an account belongs to someone under 18, it is closed. What happens to the data depends on their age, because the two situations are governed by different rules:

• Under 13 — the account and its data are removed promptly and without notice, as required by the US Children's Online Privacy Protection Act (COPPA). COPPA obliges us either to obtain verifiable parental consent or to delete promptly; we are not set up to verify a parent, so we delete. The law does not offer a grace period and does not let us keep the data in the meantime.
• 13 to 17 — this is not COPPA. They are simply not eligible under our Terms, so the account is wound down rather than deleted on the spot: they are told, and they get at least 30 days to export their data before it is removed, exactly as section 10 of the Terms of Service promises everyone. Their data is retained for that window for the sole purpose of letting them take a copy of it.

If you believe a child or teenager has an account, email the address at the bottom of this page and we will remove it.

Contact

Questions about this policy or requests about your data: [email protected]

Changes to this policy

If this policy changes, the "last updated" date above will change with it. If you have an account, a material change brings this policy back up and asks you to agree again before you carry on. If you use the app without an account there is nothing for us to record an agreement against, so that prompt does not appear — the "last updated" date is how you tell.

Earlier versions of this policy contained statements that were wrong or out of date, and each was corrected as it was found. Those corrections are recorded here in full, in the words they were written in, newest first. Nothing has been removed from them.

21 August 2026

Change — you can now lock the app with your fingerprint. A new setting, off unless you turn it on, asks Android to check your fingerprint before JST Fitness opens.

Three things worth being precise about, because this is the first time the app has involved anything about your body that is not a number you typed in yourself:

• The app never receives your fingerprint. Android does the checking in secure hardware on your phone and tells the app only whether it matched. No fingerprint, image or template exists anywhere in the app, on our servers, or in your backup file. Nothing new is collected, uploaded, synced or shared, and no answer on our Google Play Data Safety disclosure changes as a result.
• It is a lock, not a way of telling who you are. The check belongs to your phone, so if more than one fingerprint is enrolled on that phone, any of them will open the app.
• It locks the screen, not the data. Nothing is encrypted that was not encrypted before, and what syncs to your account is unchanged.

Change — account emails are now delivered by Resend. The emails this app sends about your account — the password-reset link, and the address-confirmation link when you create an account — are now handed to Resend, a company that delivers email on our behalf, instead of going out through our database provider's built-in mailer.

• What Resend receives is your email address and the contents of those messages, and nothing else. It is never sent your weight, your food log, your workouts, or anything else in the app.
• Nothing new is collected from you. We already had your email address in order for you to have an account at all. This changes who carries the message, not what is in it, and no answer on our Google Play Data Safety disclosure changes as a result.
• Resend is now named in "Who else is involved" above, alongside the other companies that handle data for this app.

We are telling you this because adding a company that handles your data is worth naming, even when the data itself does not change.

18 August 2026

Change — a food you add can now be shared with other users, if you choose. Until today nothing you put into the app could reach another user of it, and this policy said so in its second paragraph. That is no longer the whole truth, and the difference is written out in full in a new section 6 of "What leaves your device": a food you add to the food list yourself can be switched to shared, one food at a time, off unless you switch it on, and only if it is a packaged food with a barcode. What other users then see is the product — name, brand, serving, barcode and the label figures you typed — marked "Community", with nothing about you: no name, no account, no "shared by", nothing from your log. Beside each shared entry we keep a private, scrambled reference to the account that shared it, so that reports can be acted on; it is never shown, and it is cut when the account is deleted or sharing is switched off, while the entry itself stays. That last part narrows the deletion promise, and it is stated where the promise is made — in "Delete your account", in "How long data is kept", and on the Delete Your Account page — not only here. The headline paragraph, the count of things that leave your device (now seven), the legal bases, the list of who receives data, and the California section all changed to match. Nothing about how the app treats what you log changed: your meals, weights and workouts are as private as they were yesterday, and sharing a food does not touch them.

Why this entry re-prompts you. The Terms gained a section on what you agree to when you share a food — you dedicate the entry to the public, and it can outlive your account — which changes what happens to something you create, so both documents ask you to agree again.

14 August 2026

Correction — "nothing is sent to Supabase" was not true, and the sentence after it made that worse. If you never created an account, this policy said the app "works fully offline and nothing is sent to Supabase", and then said one exception applied: streamed demonstration videos. Naming a single exception is a claim that there are no others, and there was one — the automatic error diagnostics described in section 4. Those are switched on by default and are not gated on having an account, so an account-less reader was told something about their own device that was wrong.

Both paragraphs are rewritten. The first now says that none of the fitness data described above is sent; the second names both things that leave the device without an account, points at where each is described in full, and says plainly that the diagnostics default on and can be switched off. Nothing about the app's behaviour changed — this is the description catching up with what the code has always done.

Also on 14 August: eight places where this policy did not match the app. These documents were read against the app's own source code, and eight lists turned out to have stopped keeping up with it. Nothing the app does changed — each of these is the description catching up. Two are the harmless kind, where something that never leaves your device was simply missing from a list. The rest are places where this policy said less than the truth: about what leaves the device, what survives a deletion, what a feedback message carries, or what paperwork is actually in place.

• "What leaves your device" said there were five things. There are six. The demonstration clips your phone streams are described inside section 1 rather than numbered with the rest, which left the count above them wrong. The count now says six and says where the sixth is described.
• Your daily water goal syncs, and the Food list did not name it. It is named there now, beside the water log it sits with.
• The weekly report summaries were missing from the device list. When a week ends the app writes itself a short summary of it — averages and totals — and keeps the 26 most recent. They stay on the device and are never uploaded, and both lists now say so. The Consumer Health Data notice already described them; this policy did not mention them anywhere, which is a hole in a list that presents itself as everything the app records.
• The "never uploaded" sentence had not caught up with the follow-along runner. It now also names that runner's countdown sound and buzz, and the preference for whether a new set's boxes start pre-filled with what you lifted last time. All three are device settings, like the rest-timer cues already listed beside them.
• Feedback carries your browser's user-agent string. Section 4 already disclosed that for crash reports; section 5 listed everything else a feedback message carries and left this one out. It is listed now.
• The Supabase data processing agreement is not signed yet, and the "who processes your data" section now says so plainly, in the same words the international-transfer paragraph below it was already using.
• A block placed on an abusive account outlives the account. The retention section said one thing outlives a deleted account — the free-trial record. The block list is a second one. It has existed since 28 July 2026, it holds nothing unless a block was actually placed, and what it holds is the blocked identifier and a short note about why — never anything you recorded in the app. The 5 August entry below calls the trial record "the first and only thing" that survives deletion; that was written without the block list in mind, and it is left standing as written, because this log records what was said at the time rather than editing its own history.
• The backup export does not contain quite everything you sync. Your rights section said the export "covers all of your synced data". Your consent record syncs and is not in the export file, so that was too broad. The sentence now says the export covers your synced fitness data, and names the consent record among the things you can ask us for by email.

Also on 14 August: the app walkthrough, and the two marks it keeps. The app now has a walkthrough — a set of short written chapters about how to use it, offered once when you first open the app. It keeps two marks about it on your phone: whether it has already offered the walkthrough to you, and which chapters you have ticked off. Both are named in the "never uploaded" list above. Neither is synced to an account and neither is in your backup file, so nothing about which parts of the app you have read reaches us, and nothing about it follows you to another device.

This one is not a correction — nothing said here before was wrong, because the two marks did not exist before. It is written down because the list it joins presents itself as everything the app keeps to itself on your phone, and a list like that stops being worth anything the first time something is added to it quietly.

And two repairs to this log itself. There was no entry at all for 4 August 2026 — the day this policy first disclosed that the demonstration clips stream from our hosting and that each request carries your IP address. It is written above, marked as added late. And the 13 August entry, whose subject is two withdrawn promises, named only one of the three phrases that came out of the Consumer Health Data sale paragraph; the other two are named there now.

Why this entry re-prompts you. The version stamp on this policy and on the Terms moved to 14 August, so you are asked to agree again. The honest reason is a mistake in our own bookkeeping: the 13 August versions of both documents were edited again just after midnight, and the stamps were left on 13 August in the belief the change was same-day. It was not. The re-assent sheet compares stamps, so it never fired, and anyone who agreed during the 13 August window was using the app under Terms whose section 2 had since been rewritten. Moving both stamps to the true date is what makes the sheet fire. The Terms change in question restored a protective clause and made two others clearer; nothing in it took a protection away.

13 August 2026

Change — follow-along circuits, and what streaming them means. The app can now run a timed circuit: it counts work and rest intervals and plays each station's demonstration clip in turn. Two honest consequences for this policy, neither of which adds anything new about you to what we hold — and then a third change, made the same day, which has nothing to do with circuits and which took two promises away rather than adding a description. It is written out in full below, because a change that narrows what we have promised you is the one a change note must never be quiet about:

• Streaming, described properly. This policy already said the demo clips are streamed from our hosting and that each request carries your IP address, the way any video does. A circuit fetches a clip per station rather than one on demand, and fetches the next a few seconds early. The requests still appear only in routine server logs that age out on their own — but because a circuit fetches in order, those short-lived logs would briefly reflect the shape of a session. Nothing reads them and nothing is kept. We still build no record of which clips you play.
• Seconds, alongside reps. A timed station records how many seconds you worked instead of how many reps you did. That is the same workout history described above, in a different unit — no new category of information.
• Two "never again" promises withdrawn. On the same day, and for a reason unconnected to circuits, two forward-looking absolutes were taken out of the documents:
• This policy's California section used to say the app has no "cross-context behavioural advertising — ever". The word ever is gone. What replaced it says the same thing about the app as it stands today — no advertising, no ad identifiers, no data brokers, no cross-context behavioural advertising — and then says plainly that this describes the version on this page's date rather than every version that will ever exist.
• The Consumer Health Data notice used to say there is no authorization to sell your health data on file because "we have never asked for one and never will". And never will is gone. Two more words left the same paragraph on the same day, and this entry did not name them until 14 August 2026: it opened "no consumer health data is ever sold — not now, not for a price…", and both ever and not now came out with the rest. What replaced it says there is no such authorization on file, that we have never asked for one, and that if that ever changed the law would require a separate, specific authorization you would have to sign for that one purpose — one that cannot be folded into anything you have already agreed to.

Why. This app may one day use what it already holds for features built on top of it, or carry advertising to pay for itself. Neither is planned and neither is built. But a promise made for all time is either kept forever or broken, and a broken "ever" is worse for you than an honest statement of today with the date on it — because it is the sentence you would have relied on. So the documents now state the present accurately and describe what would have to happen first.

What did not change. Nothing in the app. Nothing is sold, nothing is shared, there is no advertising, no ad identifier, no third-party analytics and no data broker anywhere in it. Both withdrawals are forward-looking only: they permit nothing to be done with data you have already given us, and they are not a consent to anything. If either ever stops being true you will read it on this page before it takes effect, and anyone with an account will be asked to agree again.

Nothing about steps or meditation changed: both still never leave your device.

11 August 2026

Change — the app can now show you today's steps hour by hour. Tapping the step ring opens a breakdown of when you moved today. To draw it, the app reads the individual step entries your phone or watch recorded for today, rather than only the daily total it read before. It is still only steps — nothing new about you is read, and nothing here is uploaded, synced, shared or sold.

Two things worth being precise about, because this policy previously said "your daily step totals, and nothing else":

• The hourly detail is never saved. It is read from Health Connect while you have that view open and is gone when you close it. Only the daily totals are kept, exactly as before.
• No new permission was needed or asked for. This uses the same Health Connect steps permission you already granted; the app simply asks for the same data at a finer grain while you are looking at it.

The old wording was true when it was written and is no longer, so it has been corrected above rather than quietly left to drift.

7 August 2026

Change — yoga, meditation and a "Following" line. Three additions, one of which is a deliberate limit rather than a collection:

• Yoga sessions are ordinary workouts and sync with the rest of your training, like any other session.
• Meditation does not sync, and that is on purpose. The log — how long you sat, and on which day — never leaves your device, even with an account and sync switched on. It is in your backup file, so it is still yours. There is no mood question anywhere in the feature, because we would rather not hold the answer. One exception is stated in full above: three achievements are earned from that log, and unlocked achievements do sync with the date they unlocked.
• Sessions gained an optional "Following" line for people who train along with a class or a video. It is free text you type. The app stores it and shows it back to you and does nothing else with it: no page is loaded, no thumbnail is fetched, and nobody is told what you watched. There is no video player inside the app, and adding one would mean embedding another company's tracking in an app that promises it has none — so we did not.

Change — measurement units now sync. Whether you use kilograms or pounds now syncs with your account, the same road the theme took on 29 July: a real user restored onto a wiped device got every personal fact back from the cloud except this one, and landed in the wrong units for their own body weight. The setting is a single word — "imperial" or "metric" — stored in the same place as the rest of your synced data. It says nothing about you beyond how you like your numbers displayed. If you never consented to sync, it still stays on your device.

5 August 2026

Change — one record now outlives a deleted account. When the paid tier launches, each new account gets one 10-day free trial. To make "one" mean one, a record that a given email address has already had its trial now survives deletion of the account — otherwise deleting and re-signing-up would produce unlimited free trials. The address itself is NOT kept: what is stored is a one-way keyed hash that cannot be turned back into an email, holds no name and no fitness data, answers only "has this address had a trial", and is deleted after 400 days. This is the first and only thing in the app that deliberately survives account deletion, so it is called out here rather than buried in the retention list. An IP-based alternative was considered and rejected — it would wrongly refuse trials to everyone sharing a household or office connection, and would tell us more about people, not less.

4 August 2026

This entry was added on 14 August 2026, ten days late. It was never written on the day. The sentence at the top of this log promises that every correction is recorded here in full, and a log with a hole in the middle cannot keep that promise — so it is written now, from the change itself, rather than left out for being late. The automatic check that guards this log only looks for an entry matching the date at the top of the policy, so a gap further down in it was invisible to that check.

Change — the demonstration clips, and what streaming one carries. This is where this policy first told you that the exercise demonstration videos are streamed from our hosting (Supabase) rather than shipped inside the app, and that — like any video stream — each request necessarily carries your IP address. It said then, as it says now, that the request is not linked to an account and that we build no record of which demos you watch, but that the requests do appear briefly in our hosting provider's routine server logs, which age out on their own. That last clause matters: a flat "nothing is stored" would have been false against a host that keeps ordinary request logs for a few days.

The version stamp moved to 4 August with it, so everyone with an account was asked to agree again. Nothing about the app changed that day — the clips already streamed. It was the description catching up.

1 August 2026

Correction — what happens to a 13-to-17-year-old's data. This policy said that if we learn an account belongs to someone under 18, "we close it and delete the information it holds" — with no exception. That was not what the app does, and it was not what the Terms promise. Only under-13s are deleted on the spot, because COPPA requires it. Someone aged 13 to 17 is not eligible under our Terms but is not covered by COPPA, so their account is wound down instead: they are told, and section 10 of the Terms gives them at least 30 days to export their data before it is removed. The policy now describes that split, and the retention section names the wind-down window as the one case where data outlives the decision to close an account.

Nothing about the app's behaviour changed. The code has worked this way since the minimum age moved to 18 on 31 July 2026; it was this document that described it wrongly, promising a deletion faster than the one actually performed.

31 July 2026

Change — the allergy feature. The allergy feature has been removed from the app, so this policy no longer lists allergies among the things that sync. There is nowhere left in the app to record an allergy, and no allergy information is collected any more. The feature was withdrawn because its warnings were guessed from a food's name and missed too much to be safe to rely on.

30 July 2026

Change — four things caught up with the app. Four things in this policy caught up with the app, and one sentence you agree to got wider. The crash-report switch and the sync-pause switch both exist now — earlier versions of this policy said they were still being built, which stopped being true the day they shipped. The consent record your account stores is now named in the sync list. The feedback tick box was renamed from "send anonymously" to "send without my email address", because the message carries a device id either way and calling that anonymous was too strong a word. And the retention promise now says plainly that both purges run automatically rather than "are being added".

The consent wording changed too, so the app will ask you again. The old sentence listed six kinds of health data, but agreeing to it is what lets the app upload anything at all — including your name, your date of birth and your app settings, which are not health data. The sentence now says so. Nothing new is being collected; the question is simply being asked honestly. Until you answer it, your data stays on your device.

The crash-report switch (Settings → Preferences → "Send crash reports") was added 30 July 2026 — earlier versions of this policy said no switch existed, which was true at the time.

The feedback tick box used to be labelled "send anonymously" — renamed 30 July 2026 because the message still carries the diagnostic id either way, and a message that can be connected to a device is not anonymous.

Feedback sent without an email address. The earlier wording called these messages "anonymous" and said nothing linked them to you, which overstated both.

The 12-month feedback limit. Until 30 July 2026 the retention section said the 12-month bound was "being added" — it is running now.

29 July 2026

Change — the formal GDPR sections. This policy gained the formal sections that EU data-protection law expects: who is responsible for your data, the legal basis for each use, your rights, how long things are kept, who the processing companies are, and a section for California residents. The substance of what the app does did not change, but four corrections did: the Profile sync bullet now names your date of birth and the rest-timer on/off switch (both synced, neither was listed); the diagnostic id is no longer called "anonymous", because it isn't quite (section 4 explains); the barcode section now says plainly that Open Food Facts sees your IP address; and the camera section no longer implies the app holds a camera permission — it never has.

Correction — the Profile sync bullet. The Profile bullet previously read "the name you entered, and display preferences like your step goal and which graph the home screen shows". Two synced things were missing from it: your date of birth (stored with your profile since the age check was added on 28 July, and synced with the rest of the profile) and the rest-timer on/off preference. A birth date is personal data and should never have been absent from this list; it is named now, and deleting your account deletes it like everything else.

Correction — what a barcode lookup reveals. An earlier version of the barcode section said "no personal data" was included; that was true of the request's contents but ignored what any web request inherently carries.

Correction — the camera permission. This policy previously told you camera access could "be withdrawn at any time in Android's settings". There is no such toggle for this app, because the app never held the permission — anyone who went looking for it found nothing, and that instruction is now gone. The error was in the safe direction (the app has less access than it described), but it was still wrong.

Change — theme and colour scheme now sync. The theme and colour scheme now sync with your account. Before this they stayed on each device. Nothing else changed: the two settings are a colour name and the word "dark", "light" or "auto" — they say nothing about you, and they are stored in the same place as the rest of your data.

28 July 2026

Correction — two limits on account deletion. Two limits on account deletion are now stated plainly, because the previous wording overstated both. On other devices, the earlier wording said copies "are removed the next time each one connects", and that was never true.

27 July 2026

Correction — what actually syncs. The cloud-sync section previously said only the body-weight log was synced and that workouts, meals, measurements and goals "remain on the device only". That stopped being true when cloud sync was extended beyond the first store, and the policy was not updated at the time. It was wrong, not vague, and anyone who read it was misled about where their data was. Nothing was ever sold, shared or used for advertising — the data went only to this app's own Supabase database — but the description was inaccurate and this corrects it.

Correction — how far back Health Connect is read. The Health Connect section said "seven days" until 27 July 2026, which was wrong: the code has always requested 30.