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: support@shindo-app.com
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 Garmin .FIT activity files, when downloaded, are stored locally as the on-device source of truth for that workout. These files are explicitly excluded from iCloud/device backup.
• A small shared container (Apple App Group group.Letongue.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: your analytics identifier, an optional developer analytics key, and — if you connect Garmin — your Garmin e-mail, your Garmin password, the Garmin session and refresh tokens, the Garmin client id and your chosen two-factor method.

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, so Shindo handles the two kinds of item there differently and deliberately:

• 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).
• The Garmin credentials get the opposite treatment. Signing out of Garmin erases all of them — e-mail, password, two-factor method and all three tokens. In addition, the first launch after a reinstall detects that the app was deleted and erases any Garmin credentials the 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 broad set of channels from Apple Health. 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:

• Heart and circulation — heart-rate variability (SDNN), resting heart rate, heart rate, walking heart-rate average, one-minute heart-rate recovery, respiratory rate, VO₂max, blood-oxygen saturation, body temperature and sleeping wrist temperature, blood pressure (systolic and diastolic), blood glucose.
• Activity and energy — steps, active energy, basal energy, exercise minutes, stand minutes, flights climbed, walking/running distance, cycling distance, swimming distance, swimming strokes.
• Running and gait dynamics — walking speed, running speed, running stride length, running vertical oscillation, ground-contact time, walking asymmetry, walking steadiness, six-minute-walk distance.
• Body composition — body mass, body-fat percentage, lean body mass, body mass index, waist circumference, height.
• Nutrition — fourteen channels: energy consumed, protein, carbohydrates, fat, water, fibre, sugar, sodium, potassium, caffeine, cholesterol, vitamin C, calcium, iron.
• Environment and wellbeing — environmental audio exposure, headphone audio exposure, UV exposure, time in daylight.
• Categories and events — sleep analysis, mindful sessions, stand hours, high heart-rate events, low heart-rate events, irregular-rhythm notifications, low cardio-fitness events, audio-exposure events, handwashing events.
• Characteristics — date of birth, biological sex, blood type, Fitzpatrick skin type, wheelchair use.
• Workouts and workout detail — workouts themselves, GPS workout routes, beat-to-beat heartbeat series, plus cycling power, cycling cadence, cycling speed and running power at per-workout granularity.

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 sleep, HRV, heart rate, workouts and nutrition from Apple Health to compute your personal baselines and coach you.”

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. Garmin Connect (optional)#

Connecting Garmin is entirely optional. If you never connect it, nothing in this section applies to you.

5.1 How the connection works — and what you should know#

Shindo signs in to Garmin Connect using your own e-mail and password, which you type into the app. This is not an official Garmin partner API; it is the same private Connect interface the Garmin mobile app uses. There is no Garmin “authorize Shindo” consent screen, and Garmin has not reviewed or approved this integration.

Practical consequences you are entitled to know before connecting:

• Your Garmin e-mail and password are stored on your device in the iOS Keychain, because the session has to be re-established when its tokens expire. They are stored, never logged, and never transmitted anywhere except to Garmin’s own login endpoints.
• The connection is direct between your iPhone and Garmin. No Shindo server sits in the middle, because there is no Shindo server.
• If you use two-factor authentication, Shindo asks for the code and remembers which 2FA method you chose.
• Garmin may change or block this interface at any time, at which point sync stops working.

The hosts contacted are sso.garmin.com (login), diauth.garmin.com (tokens), connectapi.garmin.com (data and .FIT downloads) and mobile.integration.garmin.com (the service identifier used during login). On connectapi.garmin.com the services called are Garmin’s user-profile, wellness, sleep, biometric, daily-summary and activity endpoints.

5.2 What Shindo fetches from Garmin#

Training Readiness (and its factor breakdown), Body Battery (including the intraday series), stress (including the intraday series), HRV status and nightly HRV series, Garmin’s Sleep Score and detailed sleep metrics (stages, respiration, SpO₂, skin temperature, restless moments, overnight heart rate), VO₂max, and your activities — with per-sample series, laps, GPS route, running dynamics, Training Effect and the raw .FIT files.

Also fetched, and worth naming separately because they are easy to overlook:

• Your Garmin profile display name (your Garmin displayName / userName — an account identifier). Garmin’s sleep and daily-summary endpoints are addressed by display name, so Shindo has to ask for it before it can request those. It is fetched once per session and held in memory only; it is not written into the database.
• Your lactate-threshold figures (threshold heart rate and speed) and your functional threshold power / power-to-weight figures.
• Garmin’s daily activity summary for the day.

All of it lands in the same local database as your Apple Health data. None of it is forwarded to any third party.

5.3 Disconnecting#

Signing out of Garmin in Shindo erases every Garmin item from the Keychain: your e-mail, your password, your chosen two-factor method, and the session token, refresh token and client id.

Two related behaviours worth stating:

• Deleting the app does not, by itself, erase the Keychain — that is an iOS property, not a Shindo choice. Shindo compensates: the first launch after a reinstall detects that the previous install was deleted and erases the Garmin credentials it left behind, before anything else runs.
• Deleting the app removes the app’s local database in the ordinary way.

If you want belt-and-braces certainty at any point, sign out in the app and change your Garmin password.

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#

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

• the date;
• your goal: its mode, your free-text goal description in your own words, and the number of weeks until your race;
• yesterday’s planned session versus what you actually did, and its status;
• the week-over-week trend and your progress toward the goal;
• your readiness score, verdict and its drivers;
• today’s HRV, your HRV baseline and z-score, resting heart rate, sleep hours and sleep score;
• CTL / ATL / TSB (fitness, fatigue, form);
• your subjective self-report as numbers, when you have given one;
• today’s planned session: sport, title, intensity band, target TSS, duration, scheduled hour and its structured steps;
• your preferred training time of day.

For the weekly plan — the same kind of engine-computed summary, including your free-text goal description in your own words, plus:

• your training thresholds (run and bike threshold heart rate, swim critical swim speed) and your weekly available hours;
• a retrospective of last week — what was planned against what you actually did;
• the seven upcoming sessions of the coming week, not a single session.

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.

For meal planning — your engine-computed calorie and macro targets.

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%”).

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 or Garmin samples, per-minute or per-second series, and GPS routes are never included in an AI request. Neither is your analytics identifier, your Garmin credentials, your Apple ID or any payment information.

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, and thirty nutrition calls — the nutrition counter is shared between food estimation and the AI meal plan.
• Not every AI feature is metered. Journal understanding, the AI insights on the Progress screen 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 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 support@shindo-app.com 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, garmin_sign_in.
  • 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 — 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).

• Some of those events carry one categorical label, so that a count can be broken down: which sport a session was, which readiness driver or which correlation pair you tapped, which tab or mode you were in, whether a food entry was AI-estimated or manual (source), which AI category hit a cap or failed, and a token from a closed list of failure reasons. It is always a label from a fixed list — never a value, never a measurement, never free text.

  Read plainly, that means PostHog can see things like “this installation skipped a session, swapped a swim for a run, and logged a perceived-effort rating.” We would rather say so than describe this as purely technical measurement.

• Segment properties attached to every event: whether you have an active subscription (is_pro), whether Garmin is connected (has_garmin), 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.

No health values are ever placed in an analytics event — no HRV number, no sleep duration, no readiness score, no weight, no calorie or macro figure. No user id, e-mail, Apple ID, transaction id, price, journal text, goal text, food description or credential is ever sent either.

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.

• Garmin operates globally, including in the United States; that relationship is between you and Garmin under Garmin’s own privacy policy.

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 support@shindo-app.com 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. Two Keychain items behave differently and are worth knowing about: the Garmin credentials are erased for you (on sign-out, and again on the first launch after a reinstall), while 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.

Disconnecting Garmin. Sign out of Garmin inside Shindo. This erases every Garmin item from the Keychain — e-mail, password, two-factor method and all three tokens (§5.3). 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 support@shindo-app.com 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 support@shindo-app.com 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 support@shindo-app.com 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.
• Credentials and tokens are stored in the iOS Keychain, accessible only after the device has been unlocked once since boot, and are never written to logs. In debug builds even the Garmin e-mail is masked in diagnostics.
• 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 send your Garmin credentials anywhere except Garmin’s own login endpoints.
• 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 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 support@shindo-app.com — 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