Privacy Policy

Last updated: 29 October 2026

MetricBridge ("the app") is designed so that your health data stays under your control. This policy explains what the app does and does not do with your information.

The short version

• The app reads Apple Health data from your device only with your permission.
• If you set up an export, it writes a clean JSON summary to a destination you choose: your own iCloud Drive (synced privately under your Apple ID), a folder you pick, or a network endpoint you configure, so the AI agent you choose can read it. Nothing is exported until you choose.
• The developer does not receive, store, sell, or share your health data.
• The app does not use your health data for advertising, tracking, or analytics.
• The app does include Meta's advertising SDK, so we can tell which adverts lead to installs. It receives app events (that the app was installed, that a trial started, that a purchase happened and for how much) and your device's advertising identifier only if you allow tracking when iOS asks. It never receives health data. Full detail in Advertising measurement.
• The app is read-only: it never writes to or modifies your Apple Health data.
• The app does not send your health data to any cloud AI service: there is no OpenAI, Google or Anthropic SDK or API in the app. When you use Ask or the Weekly Health Brief, the statistics are computed on your iPhone and the language model that phrases the answer runs on the device. On iPhones without a built-in system model, the app can download an optional model file from us once, so that it can also run locally. Your health data is never sent to us or to a cloud AI in any case. If you switch on Your Mac mode (opt-in, off by default), one answer's question and numbers go over your Wi-Fi to Ollama on your own Mac, and nowhere else.
• Separately, if you export, the AI assistant you choose reads the exported file locally, on hardware you control.

The privacy receipt

“Nothing ever touches the internet” would not be true, so here is every data flow, one per row: where it is processed, whether it leaves your iPhone, why, and what you can do about it. The first ten rows are the same ten on the home page; the rest are the website and the smaller flows. Your health data never goes to us, to Meta or to any cloud AI. Each row names the source file in the app or site that makes it true, so a reviewer can check it rather than take our word. The app rows match the App Store privacy label (Tracking: yes, for the three advertising rows and nothing else; a script in the repository fails the build if the label and the app's privacy manifest ever disagree).

The open source MCP server is separate: it runs on your own computer, reads the files you exported and makes no outbound network calls. The Apple Watch app gets a small summary straight from your iPhone over Apple's WatchConnectivity and reads no Health data itself. MetricBridge for Mac reads the same export from iCloud Drive or a folder you choose, with no HealthKit, no account and no network requests. Everything your agent can see through it is listed on the MCP server page.

What data the app accesses

With your explicit HealthKit authorization, the app can read health and fitness metrics available on your iPhone and Apple Watch (for example: steps, distance, energy, heart rate, heart-rate variability, respiratory rate, blood oxygen, sleep, body measurements, mobility, hearing, and workouts). You choose which categories to allow in the Apple Health permission sheet, and you can change this at any time in the Health app (Sharing → Apps → MetricBridge) or in iOS Settings.

How the data is used

The app formats the metrics you allow into JSON. Nothing is exported until you choose where it goes: during setup you pick one destination (your own iCloud Drive, a folder you choose with the iOS folder picker, a device on your local network, or your own server), and none is preselected. If you pick iCloud Drive, the app writes the JSON into its folder in your iCloud Drive, which Apple syncs privately under your Apple ID, and the local MCP server you install reads it on your own computer. If you pick a network destination, the app sends the JSON directly from your device to that endpoint, authenticated with a token you provide. In no case does the data pass through any server operated by the developer. If iCloud Drive is turned off on your iPhone, the file is kept on your device (On My iPhone › MetricBridge in the Files app) and is excluded from iCloud Backup.

What the app stores on your device

• Your settings (endpoint URL, token, schedule) in the app's local storage.
• If you chose iCloud Drive: a JSON cache of your exported metrics in the app's folder in your iCloud Drive, synced under your Apple ID for the AI agent you choose to read.
• A local log of export attempts (timestamps, counts, status) for your reference.
• Once you allow tracking (and not before, because until then the SDK is never started), Meta's SDK keeps its own small bookkeeping in the app's storage: an identifier for this installation and any advert events waiting to be sent. No health data is in it.

You can delete exported files from the app (Settings → Delete all exports), and deleting the app removes its local settings and logs.

Data retention & deletion

For the app, the developer retains nothing server-side: there is no account and no developer server in the data path. (The main thing we do keep is the email address of anyone who joins the early-access list on the website, and only if they ask us to.) Your exported cache lives only on your device and in the destination you configured (your iCloud container, a synced folder you picked, or your own LAN/webhook endpoint). It stays there until you clear it in the app (Settings → delete exports), delete the file at your destination, or delete the app. Revoking Apple Health access or deleting the app stops all further processing immediately. Because there is no app account, there is nothing app-related for us to delete on your behalf. The advert events described below go to Meta rather than to us; we keep no copy of them, and Meta's retention of them is Meta's, not ours.

Data sharing

The developer does not collect or share your health data with anyone. MetricBridge does not send your health data to any cloud AI service: there is no OpenAI/ChatGPT, Google, or Anthropic SDK or API in the app, and the on-device model that phrases Ask answers runs on your iPhone, or, only if you switch on Your Mac mode, in Ollama on your own Mac over your Wi-Fi. The app only writes a JSON file to the destination you choose and explicitly export to. If that destination is a network endpoint or webhook, it is a server you operate and control; the AI assistant you use then reads that file locally, on your own machine. Once data reaches the destination you configured, it has left the app's control and is governed by that destination. Choose destinations you trust. We require HTTPS for any public webhook so your data is never sent in cleartext over the internet.

Optional export encryption. In Settings > Export encryption you can set a passphrase and switch encryption on for any destination (iCloud Drive, a folder, your server, the local network). Exports to a switched-on destination are encrypted on your iPhone (AES-256-GCM, with a key derived from your passphrase) before they leave it, so whoever holds that storage or sees that traffic cannot read them without the passphrase. The app never stores your passphrase or sends it anywhere, and we never receive it: your iPhone keeps only the derived key, in its Keychain, and that key never moves to another device. The MetricBridge MCP server decrypts on your own computer when you give it the same passphrase there. We cannot recover a lost passphrase. It is off by default, it does not cover files you share from Export Now or reports, and it does not protect an unlocked iPhone.

What an AI agent can see. An agent reads only the export files, through the MCP server on your own computer: daily values per metric, workout and sleep summaries, the hourly window, the events and profile fields you entered, time zone changes, and cycle start dates if you switch on sensitive categories. Never workout routes, GPS locations or medication records from Apple Health, and never write access to Apple Health (add_event and remove_event can write only health-events-agent.json beside the export). The full list, and how to revoke an agent's access by regenerating your pairing code, is on the MCP server page and in the app under Settings, What agents can see.

This section is about your health data, and it is unconditional. Data that is not health data is a separate question with a different answer: the app does send a few advert events to Meta, and that is set out in full in Advertising measurement below.

The optional on-device model download

Most recent iPhones already include a system language model, and Ask uses that. Nothing is downloaded. On iPhones without one, the app offers a one-time, optional download of a model file from models.healthexport.dev, so that Ask can still run entirely on your device. You choose whether to download it; the app never does so on its own. How each way Ask runs compares.

That download is an ordinary web request for a public file. No health data, device identifier or account information is sent: the request contains nothing about you or your data. As with any web request, our host necessarily sees the connecting IP address, timestamp and user agent in standard server logs. We do not use those logs to build profiles, track individuals, or link requests to any person, and we do not combine them with anything else. If you never download the model, the app makes no request to our servers at all. (It is not the app's only network activity, though: the advert events in the next section go to Meta, not to us.)

This is an AI system

MetricBridge's Ask feature and the Weekly Health Brief are AI features. When you use them you are interacting with an AI system, not a person, and the text you read is AI-generated. We say so plainly here, in line with the transparency rules in Article 50 of the EU AI Act.

The guides on this site are written with AI help and reviewed by a person before they are published. Each one says so under its byline ("AI-assisted, human reviewed") and carries the same statement in its metadata, so both readers and the tools that index the site can tell.

• How it works. The numbers in an answer are computed on your iPhone from your own Apple Health data. A language model that runs on the device reads your question and phrases the answer: the system model built into recent iPhones, or the optional model file described above on iPhones without one. If you switch on Your Mac mode, a model in Ollama on your own Mac can phrase it instead, over your Wi-Fi. Common questions are handled by a fixed, rule-based parser with no language model involved.
• Answers can be wrong. An AI model can misread a question or phrase a result badly, and your data can have gaps. Every answer shows the metric, date range and sample count it was built from, so you can check it. Treat an answer as a starting point, not as a fact you rely on without checking.
• Not medical advice. Ask describes your own data and how it deviates from your personal baseline. It does not diagnose, detect, treat or monitor any condition, and it declines questions about symptoms or diagnosis. For anything that worries you, talk to a doctor.
• No cloud AI. Your questions and your health data are not sent to us or to any third-party AI service to produce an answer.

AI-assisted writing on this website

Articles in our guides are drafted with the help of AI tools and reviewed by a person before they are published. Each one carries a visible "AI-assisted, human reviewed" label. Each one is also marked in a machine-readable way, using the IPTC digital source type compositeWithTrainedAlgorithmicMedia in the page's metadata and structured data. If you spot an error in an article, email [email protected].

Advertising measurement

We pay for adverts, and we would rather spend that money on the ones that work than guess. The only way to know which ones work is to be told when an install or a purchase follows an advert. So the app includes Meta's SDK (Facebook's advertising kit), which reports a small number of events to Meta.

What it sends. Three things, and this is the complete list. That the app was installed and opened. That a free trial started, with the amount charged to start it (zero) and the currency. That a purchase happened, with its amount and currency. No product name or identifier goes with either: just a number and a currency code, so we cannot tell from Meta's side which thing you bought. And, only if you allow tracking, your device's advertising identifier, which is the part that lets Meta match the install to an advert you saw. As with any network request, it also carries the ordinary technical envelope: your IP address, device model, iOS version, language and region, the app's version, and an identifier the SDK generates for this installation.

What it never sends: any health data. Not a metric, not a value, not a reading, not a date, not a file you exported, not a question you asked Ask, not an answer the app gave. There is no code path from Apple Health to the SDK. The two do not exchange anything. Everything above about your health data holds exactly as written.

iOS asks first, and no is a real answer. Before any of this happens, iOS shows you the App Tracking Transparency prompt. If you decline, the app is unchanged: every feature works, we do not ask again, and there is no lesser version. Declining is not a promise we ask you to take on trust either: until you allow tracking, the app never starts Meta's SDK at all. It is not switched on and quietly held back: no Meta code runs, so there is nothing to send and nothing queued to send later. Turn tracking off afterwards and it goes back to that state.

We say it that way deliberately, because the more comfortable version would be slightly untrue. Meta's SDK declares one collection address as a tracking domain, and iOS does block that address unless you have allowed tracking. But the SDK has a second address that is not declared, which iOS therefore does not block, and an ordinary integration keeps talking to Meta through it after you decline. So the operating system is a useful backstop and not a complete one. Ours does not reach either address, because it never starts.

One thing that does not depend on your answer: the purchase itself. When someone makes a purchase, Apple tells RevenueCat (the purchase-records service we use as a processor), RevenueCat tells our server, and our server can report that purchase to Meta so an advert can be credited with it. Since 11 October 2026 this report is switched off for everyone, and we will update this policy before it is ever switched back on. When it was on, it covered every purchase, including one made by someone who declined tracking: our server is not the app, and it cannot see what you answered on your phone. What it sends is the fact of a purchase, the amount, the currency, and the App Store transaction identifier for that purchase. No advertising identifier, no device identifier, no name, no email, and (as everywhere else here) no health data. It is flagged to Meta as non-tracking, so Meta may count it in aggregate and modelled reporting rather than matching it to an advertising profile of you. We would rather write this down than let the sentence above read as broader than it is.

What you will see in the App Privacy Report. iOS's App Privacy Report (Settings > Privacy & Security > App Privacy Report) lists the domains an app contacts. MetricBridge will appear there. The third-party domain you will see is Meta's, from the advertising measurement above, and only after you allow tracking. If you download the on-device model, you will also see models.healthexport.dev, our own host. That is the complete list. Your health data is not part of any of it: the report shows network contacts, and the app's only network contacts are Meta's ad-attribution SDK (after you allow tracking), Apple's own services, and the model download you choose. If you decline tracking, the app makes no Meta contact at all, so the report shows none.

Changing your mind. iOS Settings > Privacy & Security > Tracking, where you can switch it on or off for this app at any time, or for every app at once. Turning it off stops anything further being sent from that moment; it cannot reach back and unsend what was already sent.

Meta's side of it. What Meta receives, Meta controls. For that data Meta is an independent controller and not something we run on our behalf: it decides how it uses and keeps it, under Meta's Privacy Policy. What comes back to us is aggregate advert reporting (how many installs and purchases an advert produced), not a list of people.

If you are in the UK or the EU. Our lawful basis for advertising measurement is your consent, and the iOS prompt is where we ask for it. Decline and the app does no processing for advertising at all: no Meta code runs on your phone and nothing leaves it. The server-side purchase report described above is the single exception, and it is limited to the purchase: amount, currency, and the App Store transaction identifier, never health data and never an advertising identifier. Since 11 October 2026 this server-side report is switched off, and we will update this policy before it is ever switched back on. You can withdraw consent at any time in the Settings path above, and withdrawing it stops future sending from the app; if you would also like us to stop reporting your purchases, write to us at the address below and we will. For people in the UK and the EU, Meta Platforms Ireland Limited is the controller of what it receives.

Separately from all of this, and whatever you choose here, Apple gives us aggregate App Store statistics (impressions, downloads and the like), and Apple's own attribution reporting may tell an advert network that an install happened. Those come from Apple, not from the app, and carry nothing that identifies you.

This website

Everything above is about the app. This section is about this website, which is separate and never sees your health data. One honest caveat: if you allow tracking in the app and accept the advertising cookie below, Meta may connect the two, because both report to Meta. That is Meta's doing rather than ours, and each is asked for separately.

Our own visitor counter. We count visits with Umami, which we run on our own server rather than paying an analytics company. It sets no cookies and stores nothing on your device. It records the page you opened, the site that linked you here, and your browser, operating system and country, never your name, your email, or anything you typed. To tell one visit from another it makes a one-way hash of your IP address and browser, salted with a secret that rotates. We cannot turn that hash back into an IP address, and we do not link your activity across our different sites. Your browser only ever talks to healthexport.dev; nothing is sent to anyone else. On the page an in-app question opens (/watch-poll/) it also records which answer you tapped and the app version, and nothing more; the app itself sends nothing.

When a program rather than a browser fetches certain pages (/SKILL.md, /llms.txt, or the home page through the link our MCP server gives AI agents), our server adds one to the same counter and notes only the general kind of program, for example “curl” or “python”. It does not pass on your IP address or full browser details, and a normal visit in a browser is not counted this way.

Because it stores nothing on your device, this one runs without asking. If you would rather not be counted, that is one click: Don’t count this browser

The Meta advertising cookie. When we run ads, we want to know whether they work, and the only way to see that here is to let Meta know you arrived. That is a third party: it sets a cookie and reports your visit to Meta, who may join it to what they already hold about you. It is not needed for anything on this site, so it does not load unless you say yes. We ask once, plainly, with the same sized button either way, and we remember what you chose.

You can change your mind whenever you like: Loading…

That is the whole line we draw, here and in the app: the thing that shares something about you with someone else has to be asked for: the cookie here, the tracking prompt there. The thing that does neither does not. If our counter ever starts storing anything, it moves behind the same question.

The early-access email list

Apart from feedback emails you send us and partner accounts, this is the only place we keep anything about you. If you join the list on healthexport.dev/register, we store:

• your email address;
• the option you pick, if you pick one (my own AI agents, coaching clients, a team or club, building a platform, more wearables, or just curious);
• which link brought you (the campaign name in the address you arrived from, if there was one), so we can tell which of our posts are worth writing;
• when you joined and confirmed, and the version of the wording you agreed to, as a record of your consent.

That's all. No health data, no name, no IP address and no browsing history are stored with it.

What we use it for. We use it to email you once when early access opens. Before that we send a single message asking you to confirm the address, and nothing goes to an address that isn't confirmed. Our lawful basis is your consent, which you give by ticking the box and then confirming by email. You can withdraw it at any time.

Who handles it for us. The list is stored in a Cloudflare D1 database, and the form is protected by Cloudflare Turnstile, which checks that a person, not a bot, is submitting it. Emails are sent through Brevo (Sendinblue SAS, France). Both act only on our instructions, as processors. Cloudflare may process data in the United States, under the EU-US Data Privacy Framework and its UK Extension, and Cloudflare's standard contractual clauses. We never sell or share the list, and we don't use it for advertising.

How long we keep it. An address that is never confirmed is deleted automatically after 14 days. A confirmed address is kept until you unsubscribe, or until six months after early access opens, whichever comes first. After that we delete the list.

Your rights. Every email has an unsubscribe link that deletes your address straight away. You can also ask us to see, correct or delete what we hold, or object to it, by writing to [email protected]. If you're unhappy with how we've handled it, you can complain to the UK Information Commissioner's Office at ico.org.uk, or to your local data protection authority.

Feedback emails

Now and then the app may ask three short questions about why you use it. Answering is optional, and the app sends nothing itself: “Share feedback” opens a draft email to [email protected] in your own Mail app, which you can read, edit or discard. If you press Send, the email goes from your own address, so the developer sees that address and what you wrote, and may reply. The draft contains your typed answers plus the app version and language, never your health data. We use replies to understand what to build and who the app is for, and delete an email on request ([email protected]).

Where the law fits

Health data has its own rules in most places you can buy the app. Here is which ones apply to a one-person developer with no server, and which do not, in plain words. None of this changes the receipt above; it says who you can hold to it.

• A wellness app, not a medical device. MetricBridge shows your own values, trends and baselines for sleep, activity and recovery. It names no disease, sets no clinical threshold, calls nothing abnormal, and never recommends a treatment. That is the line the US FDA's general-wellness policy (reissued 6 January 2026) and the UK MHRA's software guidance draw between a wellness product and a regulated medical device, and the app is built to stay on the wellness side of it. Apple now asks Health & Fitness apps to declare on the App Store product page whether they are a regulated medical device (new apps since 26 March 2026, existing apps by early 2027); our answer to that question is no, for the same reason.
• Not "HIPAA compliant", and here is why. HIPAA binds health-care providers, insurers and the companies that work for them. It does not cover a consumer app you install yourself, so a "HIPAA compliant" badge on a page like this would be marketing, not law. What protects you is the design in the receipt, plus the consumer-protection and health-privacy rules below.
• US: FTC Health Breach Notification Rule. We are most likely a "vendor of personal health records" under this rule, because the app can draw health data from multiple sources through Apple Health. Because we never receive your health data, the only way we could cause a breach is a defect in the app itself. If that ever happened, we would notify you and the FTC as the rule requires.
• Washington and Nevada consumer health data laws. These define "collect" broadly enough to include an app reading health data on your own phone, so we treat them as applying. The categories of health data the app reads, why, where it goes and who else sees it are all in the receipt; nothing is sold, and nothing is shared with anyone except the destination you choose. Your rights to see, delete or withdraw consent are exercised on the phone, because that is the only place the data is: revoke access in the Health app, delete exports in Settings, or delete the app. To ask us anything about this, write to [email protected].
• UK and EU: GDPR special-category data. Health data is "special category" data under Article 9. Philip D'Souza is the controller for the app's design: he decides what the app reads and what it does with it, even though he cannot see the result. The lawful bases are the contract with you (Article 6(1)(b)) and your explicit consent (Article 9(2)(a)), which you give in Apple's Health permission sheet and can withdraw there at any time. Your rights of access, correction and erasure are exercised on your own phone, because no copy exists anywhere else. For the small set of non-health data we do hold (the early-access list, feedback emails, partner accounts), the usual rights apply and the contact is below.
• EU AI Act. Ask and the Weekly Brief are AI features; the disclosure above is the Article 50 transparency statement.

We are not lawyers, and this is our reading of the rules as they stand on 27 October 2026. If you think we have one wrong, tell us at [email protected] and we will check and correct it.

Children

The app is not directed at children and does not knowingly collect data from children.

Your choices

• Revoke Apple Health access at any time, change or remove your endpoint, disable background export, or delete the app, which removes all locally stored settings and logs.
• Decline advert tracking when iOS asks, or change your answer later in iOS Settings > Privacy & Security > Tracking. Declining costs you nothing in the app.
• On this website, switch off the visitor counter, and turn the Meta advertising cookie on or off, with the buttons under This website.
• Leave the early-access list at any time with the unsubscribe link in any of its emails, which deletes your address.
• Ask us to see, correct or delete anything we hold about you (the early-access list, a feedback email, a partner account) at [email protected]. For your health data there is nothing to ask: we never had it.

Contact

MetricBridge is made by Philip D'Souza, a sole trader in the United Kingdom, who is the data controller for the early-access list. Questions about this policy: [email protected]