Privacy Policy

Shindo is an endurance-coaching app for iPhone. It reads recovery and training data, computes readiness and training-load metrics on your device, and uses an AI model to turn those numbers into readable coaching text.

Because Shindo works with health data, this policy is written to be understood on the first read. It is specific about the parts that are easy to gloss over: some of your health information does leave your device. Where that happens, it is stated plainly below rather than buried.

This policy describes the app as it currently ships.

1. The short version#

2. Who is responsible for your data#

The controller of the personal data described here is:

Aleksandr Kolesnikov
Dimitri Nikolaou 7, Limassol, Cyprus, 4006
the Republic of Cyprus

Contact for any privacy question or request: [email protected]
Website: shindo-app.com

We have not appointed a Data Protection Officer; privacy requests are handled directly at the address above.

3. What stays on your device#

Shindo’s database is a local SwiftData store on your iPhone. It holds your metrics, workouts, sleep, food log, plans, goals, journal entries and the AI reports the app has generated.

• There is no CloudKit or iCloud sync inside the app. The app never uploads this database anywhere.
• There are no user accounts. Nothing links the database to a real identity.
• Meal photos you log are written to a private app folder (Application Support/FoodPhotos) and are best-effort excluded from iCloud backup.
• Raw .FIT activity files downloaded by an earlier version of the app remain stored locally as the on-device source of truth for those workouts. They are explicitly excluded from iCloud/device backup. This version downloads no new ones (§5).
• A small shared container (Apple App Group group.com.shindoapp.shindo) holds a JSON snapshot for the home-screen widgets, the cached feature-flag values and your chosen interface language. It never leaves the device.
• The iOS Keychain (service com.shindo.secrets) holds two items: your analytics identifier and an optional developer analytics key. No third-party service credential is stored there, because the app never asks you for one (§5).

One honest caveat about “local”. If you have iPhone backups enabled, iOS may include Shindo’s local database in your own encrypted device or iCloud backup. The database is not excluded from backup, unlike the meal photos and the raw .FIT files above — so it is the one place your health history can leave the phone without any action by you. That backup belongs to you and to Apple’s backup terms — we have no access to it, but it is not accurate to say the data can only ever exist on the phone itself.

A second honest caveat. iOS Keychain items are not always removed when an app is deleted. The analytics identifier is stored in the Keychain precisely so that it survives reinstalling the app, which means deleting the app does not reset it. What does erase it is turning analytics off in the app: withdrawing that consent destroys the identifier outright (§7).

Earlier versions of Shindo also kept Garmin Connect credentials in the Keychain. That integration has been removed (§5), and the credentials are erased rather than merely left unused: the first launch of this version deletes every one of those items, and the first launch after a reinstall erases anything a previous install left behind, so a fresh install never inherits them.

See §13 for how to exercise each of these.

4. Apple Health#

4.1 What Shindo reads#

With your permission, Shindo reads a deliberately narrow set of channels from Apple Health — only the ones one of its engines actually computes with. You grant these per category in the system permission sheet, and you can change any of them later in Settings → Health → Data Access & Devices → Shindo. Anything you deny simply stays missing — the app degrades rather than blocks.

By category, Shindo asks to read:

• Recovery signals — heart-rate variability (SDNN), resting heart rate, respiratory rate, blood-oxygen saturation, sleeping wrist temperature, VO₂max.
• Sleep — sleep analysis.
• Energy — active energy and basal (resting) energy.
• Body composition — body mass and body-fat percentage.
• Nutrition — five channels: energy consumed, protein, carbohydrates, fat, water.
• Characteristics — date of birth and biological sex.
• Workouts and workout detail — workouts themselves, GPS workout routes, beat-to-beat heartbeat series, plus heart rate, running speed, running power, cycling power, cycling cadence and cycling speed, all read per workout rather than as whole-day figures.

That is the entire list. Shindo does not ask for blood pressure, blood glucose, body temperature, steps, distances, flights climbed, exercise or stand minutes, running and gait dynamics, environmental or headphone audio exposure, UV exposure, daylight time, mindful sessions, height, waist circumference, body mass index, lean body mass, or the nine micronutrient channels (fibre, sugar, sodium, potassium, caffeine, cholesterol, vitamin C, calcium, iron). Earlier versions did ask for most of those, along with blood type, Fitzpatrick skin type and wheelchair use; nothing in the app ever read them back, so they were removed rather than kept “just in case”.

If you used one of those earlier versions, the readings already collected stay in Shindo’s on-device database until you delete them or remove the app (§13). Shindo stops adding to them, and no longer offers them as a chart.

Shindo also registers background app-refresh and background processing tasks with iOS, so the system can occasionally wake the app — with the app closed — to sync new data, recompute your metrics and refresh the home-screen widget. iOS decides if and when that happens; Shindo only asks. Note that the same wake-up is what can trigger a background AI request for notification copy — see §6.1.

The purpose is a single one: computing your personal baselines, readiness score, training load and coaching plan on your device.

The permission text iOS shows you says: “Shindo reads your workouts (with their routes and heart-rate series), sleep, recovery signals (HRV, resting heart rate, respiratory rate, VO2 max, blood oxygen, wrist temperature), energy burned, body mass and body fat, food and water intake, date of birth and biological sex to calculate your training load and daily readiness.”

4.2 What Shindo writes — exactly four things#

Shindo writes back only the daily totals of the meals you log in the app:

Nothing else is ever written. Water is read but never written. Workouts, sleep, heart rate and every other channel are strictly read-only. When Shindo reads those four nutrition channels back, it excludes its own entries so your intake is never double-counted.

One thing you should know about those totals. The daily total is the sum of every food entry you kept for that day — including entries whose macros were estimated by the AI from a photo or from a description you typed. Where that is the case, an AI estimate is what gets written into Apple Health: an approximation, not a measurement. You can edit or delete any entry, and the exported total is recomputed to match.

The permission text iOS shows you says: “Shindo writes the meals you log in the app back to Apple Health, as one daily total each for calories, protein, carbohydrates and fat. Nothing else is written — workouts, sleep and every other channel stay read-only.”

5. Wearables and other services#

Apple Health is the only source of your recovery and training data. Shindo connects to no third-party service account, asks you for no other service’s e-mail or password, and stores no such credential. Data recorded by a Garmin, Polar, Whoop, Oura or any other wearable reaches Shindo only if that device writes it into Apple Health, in which case it arrives through Apple’s own framework as described in §4 and Shindo never contacts the device’s vendor.

The Garmin Connect integration has been removed. Earlier versions of the app could sign in to Garmin Connect with your own e-mail and password and fetch data directly. That integration is not part of this version: there is no sign-in form, nothing is fetched from Garmin, and no Garmin host is contacted.

Two consequences worth stating plainly:

• The credentials are erased, not merely unused. On its first launch this version deletes every Garmin item the previous version had stored in the iOS Keychain — your e-mail, your password, your chosen two-factor method, and the session token, refresh token and client id. Nothing is left behind to be read later. If you want belt-and-braces certainty, change your Garmin password as well.
• Workouts already imported are kept. Activities that an earlier version imported from your Garmin account remain in the local database on your device, together with any raw .FIT files it downloaded. That is your own training history, and deleting it silently would be worse than keeping it. Like everything else in that database it is never transmitted anywhere, and deleting the app removes it.

6. Google Gemini — the part where health data leaves your device#

Shindo’s coaching text, food recognition, journal understanding and the wording of its notifications are produced by Google’s Gemini models. To produce them, information about you is sent to Google.

None of this happens unless you have said yes. AI coaching is one of the two questions asked on the first screen of the app, and every single AI request — without exception, including the ones made in the background — is refused before it is even assembled unless that consent is currently granted. §6.3 describes the control and exactly what turning it off does and does not do.

Those requests do not go straight from your iPhone to Google. Since 14 August 2026 they pass through a small relay we operate ourselves — a Cloudflare Worker at api.shindo-app.com — which attaches our Google API credential and forwards the request to generativelanguage.googleapis.com. The answer comes back the same way.

The relay exists for one reason: so that the credential lives on a server we control instead of being shipped inside the app on your phone, where anyone who took the app apart could extract it. It is not there to collect anything about you, and it never stores, reads or logs the contents of a request or a reply — not a summary, not a meal photo, not a line of your journal. What it does receive, record and count is set out in §6.2, §10, §11 and §12.

6.1 What is sent#

Your athlete profile travels with almost every AI request. It is the block that lets the text be about you rather than about a generic athlete, and it is attached to the morning report, the weekly plan, the workout analysis, the Progress-screen insights, the meal plan (a reduced, physical-only version) and, in a cut-down form, to a notification’s wording. It contains:

• age, sex, height, body mass, body-fat percentage and fat-free mass, plus whether the body-composition figures were measured or estimated;
• your training thresholds — maximum heart rate, run and bike threshold heart rate, cycling FTP, swim critical swim speed — and which of them you set by hand;
• your experience level and years in each sport, your weekly available hours, your preferred time of day to train, and your equipment (both what you have and what you do not);
• your ongoing injuries — the body part only. The note you wrote about an injury is never sent;
• your dietary preferences. Two of the options the app offers — halal and kosher — say something about religious practice, so if you select them, that inference is part of what is sent. If you would rather it were not, leave those boxes unset; the app works the same without them.

For the daily morning report — a compact JSON summary of engine-computed figures. Alongside the profile block:

• the date, and your goal: its mode, your free-text goal description in your own words, and the number of weeks until your race;
• your progress toward that goal and the projected trajectory towards it;
• your readiness score, verdict and its drivers;
• your HRV, HRV baseline, z-score and the trailing week of HRV values; your resting heart rate and its change; Body Battery, stress and Training Readiness where your device supplies them;
• last night’s sleep in detail — hours, deep / REM / core / awake minutes, time to fall asleep, efficiency, sleep score, sleep need and accumulated debt, overnight HRV, blood-oxygen average, breathing rate and wrist-temperature deviation;
• your body mass and its 7- and 30-day trend, and body-fat percentage;
• CTL / ATL / TSB (fitness, fatigue, form), their weekly rates of change, your training status, the last 28 days of daily training load, and the engine’s load-risk figures (acute-to-chronic ratio, monotony, ramp rate, early-warning level);
• the week so far: planned against completed load, compliance, key sessions done, your easy/hard split and your current streak;
• yesterday’s planned session versus what you actually did, its status and the effort rating you tapped;
• your recent workouts — sport, duration, load, distance, average heart rate and power, heart-rate drift, efficiency factor, Training Effect and status;
• today’s planned session: sport, title, intensity band, target load, duration, scheduled hour, its structured steps, heart-rate zone ranges and its fuelling targets — plus the rest of the week’s planned days;
• your food diary as numbers — your calorie and macro targets, the day’s fuelling mode, your calorie budget, basal and active energy, what you logged today and over the previous three days (calories, carbohydrate, protein, fat, fluids);
• your energy availability, RED-S flag and metabolic-adaptation read;
• the forecast — projected readiness and fitness for the days ahead, its confidence, your taper start and projected race form;
• the correlations the app has found in your own data (for example carbohydrate intake against HRV), and your subjective self-report as numbers when you gave one.

For the evening day review — the same summary as the morning report, built from the same data; only the instruction to the model differs.

For the weekly plan — the same profile and goal block, plus your availability windows per weekday, your fitness trajectory over 28 days, the full load-risk and early-warning picture, the readiness forecast for the week, how closely you have followed the plan over the last four weeks (including the correction the engine has already applied to this week’s targets), your fuelling frame and dietary preferences, a retrospective of last week, a training-block retrospective when a block ends, and every session of the coming week with its steps, fuelling and equipment fit.

For the analysis of a finished workout — the profile and goal block, plus that session as recorded: sport, start hour, duration, load, distance, average and maximum heart rate and power, cadence, energy burned, heart-rate drift, efficiency factor, decoupling, aerobic and anaerobic Training Effect, total ascent, the ambient temperature and humidity recorded by your device, stamina, the data source, and the effort rating you tapped. With it go the planned session it fulfilled and how each planned step actually went, the durability and anaerobic- reserve figures, minutes per heart-rate zone, how the session compares with your own recent sessions of that sport, and the readiness / load context of the day it sat in.

For the AI insights on the Progress screen — the profile and goal block, plus the already-computed longitudinal facts: training-block retrospectives, year-over-year and cycle-over-cycle comparisons, the context around a personal record, and the correlations found in your own data.

For the meal plan — a physical-only subset of the profile (sex, age, height, mass, body fat, fat-free mass), your calorie and macro targets and physiological floors, the day’s fuelling mode and energy balance, your energy availability and RED-S flag, today’s and tomorrow’s sessions and their fuelling, your eating window and meal-timing hints, your dietary preferences, the free-text food note you wrote — where allergies typically end up — truncated to 200 characters, and the names and usual portions of the dishes you log most often, so the plan is built from food you actually eat.

For food logging — either the text you typed, or the photo of your meal, optionally with the caption you wrote about what is on the plate. The image is downscaled and compressed, then sent to the model for recognition.

Shindo has no voice feature and never asks for microphone access. If you dictate into that text field using the microphone on the iOS keyboard, the audio is handled by Apple under Apple’s terms; Shindo only ever sees the text that ends up in the field.

For the journal — the note you wrote, verbatim. When you answer “how are you today?”, the entire text you typed is the input to the model; it is not summarised or redacted first. Please keep that in mind when deciding what to write there. Sent with it are a few numbers that let the same word be read correctly — yesterday’s training load, today’s planned load, last night’s sleep hours, today’s readiness and your last few sessions — so that “tired” after a rest day is not read as “tired” after a four-hour ride.

For notification nudges — including when the app is closed. When the engines detect a situation worth a notification, the wording of that notification is written by the AI. The request names the situation the engine detected: for example that you have accumulated several nights of short sleep, that your logged intake has been running low relative to your training for several days, or that a workout has just finished — in the last case the request also carries the engine-formatted analysis line for that session (something like “zones held, decoupling 4%”). Since the nudge copy was made athlete-specific, it also carries four anchors — your body mass, your experience level, today’s readiness verdict and the phase of your plan — plus a narrow slice of the situation at hand (the sleep figures for a sleep nudge, the fuelling figures for a fuelling one). The purely technical notices (a sync problem, an expired connection) carry none of it.

These requests are generated in the background, by a task iOS wakes without you opening the app. Concretely: Shindo registers a background processing task with iOS; when the system chooses to run it, the app syncs, recomputes your metrics, and then — if a nudge is warranted — asks the AI to word it. Your iPhone is therefore talking to Google at a moment you did not choose and cannot see. Most nudge requests contain no numbers at all, but the request itself still discloses a health inference about you to Google by the simple fact of being made.

This background AI request is subject to exactly the same consent gate as every other one: with AI consent off, the background task still syncs and recomputes on your device, and simply sends nothing.

6.2 What is not sent#

Raw HealthKit samples, per-minute or per-second series, workout laps as recorded, and GPS routes are never included in an AI request. Neither is your analytics identifier, your Apple ID or any payment information.

Nor is your date of birth — the engines derive your age from it on the device and only the age is sent. And with one deliberate exception, free text you wrote about yourself stays here: the note attached to an injury, the note attached to a personal record and the “how did that feel” note attached to a workout are never included. The exception is the four fields §6.1 names explicitly — your goal description, your food note, your dish names and your journal entry — and each of them is named there for exactly that reason.

One dependency worth stating plainly, because it is the one place where two otherwise separate things touch. The relay described in §6 authenticates every request with a per-install token, and that token is the same random identifier described in §7.1 — the one PostHog knows you by.

So: Google receives no identifier of any kind, exactly as before. Our relay does receive one, and it is technically the same string that appears in our analytics. We do not correlate the two, and the relay keeps no request contents to correlate — but the link exists, and you should read it here rather than discover it later. If you turn analytics off (§7.1), the identifier is destroyed and the next AI request presents a new one.

6.3 Controls and limits#

• Successful AI calls are capped per day for the metered features: one morning report (which includes the Today insight cards), one weekly plan, two Progress-screen insight runs, three day-review-or-workout-analysis runs, and thirty nutrition calls. Two of those counters are shared: the analysis counter between the evening day review and the per-workout analysis, and the nutrition counter between food estimation and the AI meal plan. The same table is in section 7.2 of the Terms.
• Not every AI feature is metered. Journal understanding and the copy of notification nudges consume no daily counter today.
• Your AI consent is the switch. It is asked on the first screen of the app, before any data is read, as one of two separate questions. Nothing is pre-selected, and you cannot move past that screen without answering both. You can change your answer at any time in Settings → Data and consent.
• What “off” means, precisely. Every AI request in the app — the morning report, the day review, the analysis of a finished workout, the weekly plan, food estimation from text or photo, the AI meal plan, journal understanding, the Progress-screen insights and the wording of notification nudges — passes through a single point that reads your consent on every call and refuses before the request is built. With AI off, nothing is serialised and nothing is sent. The rest of the app is unaffected: readiness, training load, plans, forecasts and manual logging are computed on your device by deterministic engines and never needed an AI call.
• Three limits of turning it off, stated rather than glossed over.
  1. A request that is already in flight when you flip the switch is not cancelled. It completes.
  2. AI text that was generated earlier and saved on your device is not deleted. That is your own training history, and destroying it silently as a side effect of flipping a switch would be worse than keeping it. Being equally plain about the other half of that: the app does not currently offer a way to delete individual saved reports either, so today the way to remove them is to delete the app, which removes the whole local database. Nothing in that history is transmitted anywhere in the meantime.
  3. Turning AI off does not reach back to Google. What was already sent has already been received; see §12 for retention there.
• We additionally operate a remote kill switch that can disable all AI calls across the app. It is our control, not yours, and it can only ever refuse — it cannot switch AI on for you, and it cannot override your consent. Both conditions must be satisfied for a request to be made, and the daily caps above apply on top of both.
• Google processes these requests under its own terms and privacy policy for the Gemini API. We do not use your data to train any model, and we do not instruct Google to.

7. Product analytics and crash reporting (PostHog)#

If you allow it, Shindo sends product-usage events and crash reports to PostHog, hosted in the European Union (eu.i.posthog.com).

This is off until you say yes, and the “off” is real. Analytics is the second of the two questions on the first screen of the app. Until it is granted, the analytics SDK is not started at all — it is not initialised and then muted, it is simply never initialised, so no request of any kind reaches PostHog, not even the SDK’s own configuration fetch. That distinction matters and is why the app does it this way: an SDK that is set up and then opted out still contacts its server on every launch.

If you never answer — which cannot happen through normal onboarding, but is the state a fresh install starts in — the answer counts as “no”. Silence is never treated as consent.

Withdrawing it later, in Settings → Data and consent, does four things: collection stops; queued events that had not yet been uploaded are not sent; the random identifier described in §7.1 is destroyed; and error reporting reverts to writing to the device’s own system log instead of leaving the phone.

One consequence we would rather name than hide: with analytics declined, the automatic crash reporter is not running either, so we do not learn that Shindo crashed on you. That is the correct trade — a crash report carries a stack trace and error text, which is exactly the kind of open-ended payload consent exists to authorise — but it does mean a crash you hit may go unfixed longer. You can always describe it to us at [email protected] instead.

The only other analytics-related controls in the app are developer fields for pointing a test build at a different project. They are not an opt-out and they do not change any of the above.

7.1 How you are identified#

By a random UUID generated on first launch and kept in the iOS Keychain. It is not your e-mail, name or Apple ID, and it is never linked to one. Because it lives in the Keychain rather than app storage, it survives deleting and reinstalling the app, so reinstalling does not give you a fresh identifier.

Turning analytics off does erase it. Withdrawing analytics consent deletes the identifier from the Keychain outright. If you later turn analytics back on, a brand-new random identifier is generated — the old one is not resurrected, and the two cannot be joined.

7.2 What is collected#

• Explicit product events only, from a fixed and closed vocabulary. Because the list is short and closed, here it is in full:

  • Lifecycle and navigation — app_open, tab_view, settings_open, onboarding_complete, data_refresh.
  • Training behaviour — session_complete, session_skip, session_swap, rpe_logged, food_logged, goal_edit.
  • Screens and cards you drill into — morning_report_view, workout_detail_view, driver_card_tap, correlation_card_tap, insight_card_view.
  • AI — morning_generate, weekly_plan_generate, ai_call_failed, ai_limit_blocked.
  • Reliability — sync_failed.
  • Subscription — pro_gate_tap, paywall_view, subscription_view, trial_start, purchase, restore, expiration.
  • Developer settings — posthog_key_saved, and the legacy ai_key_saved (kept only so historical records still decode; the app no longer has such a field).

• Nothing derived from your health or training data is attached to any of them. Earlier versions of the app sent one categorical label alongside some events — which sport a session was, which readiness band your morning was, which readiness driver or correlation pair you tapped. Those have all been removed. Each of those labels was a fixed, coarse word rather than a measurement, but it was still worked out from your Apple Health data, and we do not think a company that reads your health data should hand any part of it, however small, to an analytics provider. So the events now record only that something happened, never what it was about your body or your training.

• The labels that remain describe the app, not you: which tab you were in, which goal mode you saved, whether a food entry was AI-estimated or manual (source), which AI category hit a cap or failed, which locked feature you tapped, your subscription plan and where a paywall was opened from, a token from a closed list of failure reasons, and the training phase of your plan — which is worked out from the race date you typed in and the calendar, not from any health measurement. Always a label from a fixed list; never a value, never free text.

  Read plainly, that means PostHog can see things like “this installation skipped a session, swapped one session for another, and logged a perceived-effort rating” — but not which sports were involved, and not what the rating was. We would rather spell out what the events do reveal than describe them as purely technical measurement.

• Segment properties attached to every event: whether you have an active subscription (is_pro), a legacy has_garmin flag that is now always false (the Garmin integration is gone — see §5; the property is kept only so that existing analytics queries keep resolving), whether AI is configured (ai_configured, currently always true), your interface language (app_language), your goal type (goal_type), days since install (days_since_onboarding), and the app version and build.

• Crashes, captured automatically: native crashes are recorded and sent on the next launch. This collector only exists when analytics consent is granted; with it declined, no crash reporter is installed at all.

• Handled errors, reported deliberately with the error description and a stack trace. This is the one place the payload is not a fixed vocabulary, and it exists because a closed list of failure codes cannot say what actually broke. Technical error text may include a server’s error response. With analytics declined these are written to the device’s system log and go nowhere.

• Requesting remote feature flags transmits your analytics identifier — and that request is itself made only when analytics consent is granted.

One honest note about feature flags: if you withdraw analytics consent, the feature-flag values already cached on your device are not cleared. They are configuration for the app, not data about you, and clearing them would silently change how the app behaves at the moment you asked us to stop collecting. Nothing new is fetched, so no further request is made.

7.3 What is not collected#

The following are explicitly turned off: interface autocapture, screen views, session replay (your screen is never recorded), and app lifecycle autocapture.

Nothing derived from your health or fitness data goes to PostHog — not a value, and not a category either. No HRV number, no sleep duration, no readiness score or band, no weight, no calorie or macro figure, no perceived-effort rating, no sport, and no name of a recovery metric or correlation you looked at. No user id, e-mail, Apple ID, transaction id, price, journal text, goal text, food description or credential is ever sent either.

This is deliberately stricter than “no health values”. Apple’s rules for apps that use Apple Health forbid passing data gathered in a health or fitness context to a third party for anything other than managing your health — and that rule holds even if you consented. Product analytics is not managing your health, so we removed those labels rather than asking you to agree to them.

What is not claimed here: that the events say nothing about you. As §7.2 describes, they do record training behaviour at the level of “a session was skipped”, and we count that honestly rather than calling it non-behavioural.

8. Subscriptions and payments#

Shindo Pro is sold through Apple’s In-App Purchase using StoreKit. Apple is the merchant of record.

We never see, receive or store your card number, billing address or Apple ID. The app only learns whether an active entitlement exists, and mirrors that as a is_pro flag. Manage or cancel a subscription in your Apple ID subscription settings.

9. Why we process each category, and on what legal basis#

Under the GDPR, health data is a special category (Article 9) and needs its own explicit basis. We separate them below rather than lumping everything under one heading.

10. Who receives your data, and in what role#

There is no advertising network, no data broker, no attribution SDK and no other third-party tracker in the app.

11. Transfers outside the EEA#

• PostHog data is sent to the EU region. No third-country transfer is intended for analytics.

• Google Gemini requests are served from Google’s infrastructure, including the United States. This is a transfer outside the EEA. It relies on Google’s Standard Contractual Clauses and the supplementary measures in Google’s data-processing terms for the Gemini API, together with your explicit consent to the specific processing (GDPR Art. 49(1)(a)).

  That consent is a real, separate act, not an inference from your using a feature: the app asks you before it reads any data, names the data categories, names Google as the recipient and names the United States as the destination, and no AI request can be made while the answer is anything other than yes. If you decline — or withdraw later — no transfer to the United States takes place for this purpose at all.

• Cloudflare, which operates the relay in §6, is a United States company running a global edge network, and an AI request is handled at whichever of its locations is nearest to you — which may be outside the EEA. This is therefore also a transfer outside the EEA, covered by Cloudflare’s Standard Contractual Clauses and its data-processing addendum, and by the same explicit consent described above: the relay is only ever used to carry an AI request, so if you decline or withdraw AI consent, nothing of yours reaches it at all.

If you are not comfortable with your health summaries, meal photos or journal notes being processed in the United States, do not use the AI features.

12. How long data is kept#

13. Your rights, and how to use them without an account#

You have the rights to access, rectification, erasure, restriction, objection, portability, and to withdraw consent at any time.

Because Shindo has no accounts and no server, most of these are exercised directly on your device — which is faster than any request to us:

Access and portability. Your data lives on your device. Health data is readable and exportable through Apple’s own Health app. Shindo does not currently offer a one-tap export of its own database; if you need one, contact us at [email protected] and we will tell you what is possible for your version.

Erasure of everything local. Delete the app. The local database goes with it, including every saved AI report. One Keychain item behaves differently and is worth knowing about: the analytics identifier deliberately survives deletion — turning analytics off is what destroys that one. See §3.

Withdrawing Health consent. Open iOS Settings → Health → Data Access & Devices → Shindo and turn off any or all categories, or revoke access entirely. Shindo stops reading those channels immediately.

Garmin credentials left by an earlier version. Nothing is required of you: the first launch of this version erases every one of those Keychain items — the e-mail, the password, the two-factor method and all three tokens (§5). If you want additional certainty, change your Garmin password too.

Withdrawing AI consent — stopping the flow of data to Google. Open Settings → Data and consent and turn AI coaching off. From that moment no further AI request is made, by you or by the background task, and the rest of the app — metrics, load, plans, forecasts, manual logging — carries on unchanged because none of it needs an AI call. Two limits, repeated here because they matter: a request already in flight is not cancelled, and AI text generated earlier and stored on your device is not deleted. There is no per-report delete in the app today, so removing that stored text means deleting the app, which removes the local database with it.

Withdrawing analytics consent. Open Settings → Data and consent and turn Product analytics off. Collection stops, events still queued on your device are not uploaded, and your random analytics identifier is deleted from the Keychain. This is the fastest and most complete route — faster than writing to us — because it removes the identifier itself.

Erasing analytics already collected. Withdrawing consent stops future collection but does not reach records already at PostHog. Because those are keyed to a random UUID we cannot recognise on sight, write to [email protected] and we will delete the records for that identifier. Do this before you turn analytics off if you can, since the identifier is destroyed on withdrawal; you can find it inside the app’s developer information. If it is already gone, describe your situation and we will help as far as we are able.

Objecting. Analytics now runs on your consent (§9), so the direct remedy is to withdraw it in the app — which takes effect immediately and needs no request to us. You may still write to [email protected] about the processing, and we will delete existing records and record your objection.

We answer requests within one month, free of charge.

14. Automated decision-making#

Shindo scores your readiness, computes your training load and generates a plan automatically, and an AI model writes the text that explains them.

This is not automated decision-making producing legal or similarly significant effects under GDPR Art. 22. Shindo recommends; it does not decide anything about you. It does not grant or deny anything, does not price anything based on your data, and does not share an assessment of you with anyone. You remain free to ignore every recommendation.

Shindo is not a medical device and gives no medical advice. Its output is training guidance. See the separate Health & Safety Disclaimer for the full statement.

15. Children#

Shindo is not directed at children. The Terms of Use set the minimum age of use at 16 (higher where your national law requires it), and we do not knowingly collect data from anyone under 16 (or the applicable age of digital consent where you live). If you believe a child’s data has reached us, write to [email protected] and we will delete it.

16. Security#

• Your data stays in the app’s private, OS-sandboxed container, protected by your device passcode and iOS file encryption.
• The few secrets the app keeps of its own — your analytics identifier, and in a developer build an optional test analytics key — are stored in the iOS Keychain, accessible only after the device has been unlocked once since boot, and are never written to logs. Shindo holds no third-party account credential of any kind (§5).
• Every network connection uses HTTPS/TLS.
• Payment details are never handled by the app at all — Apple processes them.

No system is perfect, and an app that stores health data on a phone is only as safe as the phone. Use a strong passcode and keep iOS updated.

17. What we never do#

• We never sell your data. Not to anyone, in any form, ever.
• We never use your health data for advertising, marketing profiling or data mining. Apple’s App Store rules (5.1.3) prohibit it and so do we. There is no advertising in Shindo.
• We never link health data to an advertising identifier. Shindo does not read the IDFA and does not ask for App Tracking Transparency permission, because it does not track you across apps or websites.
• We never share your health data with data brokers, insurers or employers.
• We never record your screen — session replay is switched off.
• We never ask you for the credentials of another service, and never store or transmit any. Shindo has no third-party account sign-in at all.
• We never put your health values, journal text or goal text into an analytics event.
• Shindo sends local notifications only — there is no push server and no notification is delivered to you over the network. The wording of a nudge is a separate matter and is not covered by this bullet: as §6.1 states, it is written by Google’s model from a description of the situation the engine detected, sometimes while the app is closed.

18. Changes to this policy#

We will update this page when the app changes — in particular if we change what is sent to Google, or change who carries it. The lastUpdated date at the top always reflects the current version.

The most recent such change was on 15 August 2026, when the Garmin Connect integration was removed from the app: no credentials are collected any more, the ones a previous version had stored are erased on first launch, and Apple Health is now the only source of your data. §1, §3, §5, §6.2, §7.2, §9, §10, §11, §12, §13, §16 and §17 were revised together to describe it.

The change before that was on 14 August 2026, when the relay described in §6 was deployed and AI requests stopped going directly to Google; §6, §6.2, §10, §11 and §12 were revised together to describe it.

For a change that materially affects how your health data is handled, we will surface a notice in the app before the change takes effect, and where the law requires it we will ask for your consent again rather than assume it. This is not only a promise: the app records which version of the consent wording you answered, so when that wording materially changes — a new recipient, a new data category, a new country — it tells you and asks you to check your answers instead of carrying an old yes over to different words.

19. Complaints#

If you believe we have handled your data unlawfully, please contact us first at [email protected] — most issues are faster to fix directly.

You also have the right to lodge a complaint with a supervisory authority: the data protection authority of the Republic of Cyprus, or of the EU/EEA country where you live, work, or where the alleged infringement occurred.

See also: Terms of Use · Health & Safety Disclaimer · Cookie Notice · Support