Privacy as architecture: what actually leaves the device in MeteoHealth

A privacy statement usually describes intentions: what a company promises to do with your data, or promises not to do. This is a different kind of description. It's an account of how the app is built — checked against its own source code — and what that construction does and doesn't make possible. It is not a promise, and it isn't a manifesto. Promises can change with a policy update; an architecture is a description of what the code currently does, and that's the level this article stays at throughout.

It also isn't medical advice: nothing below describes what any symptom or pattern means for your health, only where the data about it can and can't go. If you're reading this because you're deciding whether to trust an app with entries about how you feel, that's a reasonable thing to want answered before you type a single word into it — and it's a narrower question than whether the app is any good, which this article doesn't try to answer either.

Nowhere to collect

The simplest question to ask of any app that touches health information is: if someone wanted to collect your data, where would it go? For MeteoHealth, the answer is that there's no address to send it to. The app has no server of its own — not a dormant one, not a backup one, none at all. There's no endpoint under our control that receives anything you log.

That's a different claim from "we decided not to collect data," and the difference matters. A company that runs a server and chooses not to log requests is one policy change away from logging them. An app with no server has no such switch to flip, because there's no machine on the other end waiting for a connection. The absence isn't a setting; it's the shape of the thing.

The same logic applies to accounts. There's no sign-up, no login, no account of any kind — which means there's no place to attach a name, an email address, or a persistent identifier to your entries even if someone wanted to. Nothing you log is tied to an identity, because there's no identity system in the app at all.

Put those two things together and a question that comes up naturally with any health app — "what happens to my data if the company is ever breached, sold, or shut down" — has an unusually short answer here. There's no central store of anyone's entries to breach, transfer, or shut down in the first place, because there was never a place where entries from different people accumulated in one location. Whatever exists, exists only on individual devices and in individual people's own iCloud accounts, not in anything that belongs to us.

What's actually inside

A privacy claim about "no server" only means as much as what's running on the device itself, so it's worth being specific about that too. No third-party library is linked into the app that ships to your phone. There is exactly one external dependency in the project: a library used for snapshot testing during development. It's attached only to the test target, which means it's part of how the app is checked before release, and it never becomes part of the build that lands on your device.

Beyond that one testing dependency, there's no analytics package, no crash-reporting SDK phoning home, no advertising library — not in the iPhone app, not in the Watch app, not in the widgets. No advertising identifier is read anywhere, and nothing in the app calls into the system's own tracking APIs. This isn't a setting you can toggle off in a menu; it's simply absent from every target that ships.

It's worth being clear about what that absence actually removes, because "no analytics" can sound like a small technical detail rather than what it is. Analytics libraries typically exist to answer questions like which screens you open, how long you stay, and what you tap before you leave — the kind of behavioral trail that, over enough sessions, can say almost as much about a person as the content they entered directly. There's no code path in this app that builds that trail, on any of the targets it ships as. Not logging it isn't the same as anonymizing it or aggregating it before storage — there's simply no mechanism collecting it in the first place, anywhere in the codebase.

What actually goes out

None of that means the app is silent on the network — it isn't. There are exactly three outside addresses the app talks to, and each one carries a specific, limited set of information with it.

The weather service receives your coordinates, an access key, and the language your interface is set to. Nothing else goes with that request. The coordinates that leave are full-precision, not rounded to a city or a region — there's no coarsening step in place today. A weather forecast is tied to a specific location, and there's no way to fetch one without saying where you are. That's the one piece of information about you that has to leave the device for this feature to work at all.

The NOAA space-weather feed receives a plain request with no parameters attached — nothing about you travels with it. What comes back is a single shared number, the planetary Kp index, the same value for anyone who asks. There's nothing personal to send in either direction here.

The open food product database receives the barcode of whatever you scan, plus our support email address sent in the request header — a courtesy to the database's maintainers so they know who's making the call, not something about you as a person. Your product searches aren't linked to anything else you log.

Three destinations, three different reasons, and in each case a specific, limited set of information — not nothing, and not everything either.

Where your records actually live

The entries you make — symptoms, notes, whatever you're tracking — live on your device by default. If they sync anywhere, it's to your own personal iCloud account, the private space tied to your Apple ID, never a shared database or anything visible to anyone but you. There's no wider store any of this passes through on the way there.

Cycle-related entries are handled even more narrowly: they don't leave the device at all, not even to iCloud. The one exception is Apple Health, and only your menstrual flow is written there, and only if you've explicitly granted permission for that. Nothing else about your cycle crosses into Health, and nothing crosses without your say-so first. That's a narrower path than the one the rest of your entries take: general symptom logs can sync to your personal iCloud, while cycle entries stay local, with only menstrual flow ever leaving, and only into Health, and only with permission.

The correlation between weather and how you're feeling — the thing the app actually computes — is calculated on the device itself. That number isn't sent anywhere to be produced; it's generated locally from data that's already local. And on the App Store's own privacy card, the category listed for this app is the strictest one available: Data Not Collected.

What follows from this, and what doesn't

It's worth being precise about what an architecture like this does and doesn't establish, because the two are easy to blur together. Having nowhere to send your data doesn't turn a symptom tracker into a medical device — it says something about where information travels, nothing about what it's for or how it should be used. A correlation the app shows you between a weather pattern and how you've been feeling is still just that: a correlation drawn from your own logged entries, not a diagnosis, and not something to act on without judgment of your own.

It's also worth resisting a tempting shortcut: none of the above makes the correlation itself more trustworthy. An app with no server and no analytics can still show you a pattern that's thin, coincidental, or built from too few entries to mean much — the absence of data collection has nothing to say about the quality of what the app concludes from the data you did enter. Privacy, in other words, is a property of where your information goes. It isn't a property of how good the app's conclusions are. Those are two separate questions, and answering one well doesn't answer the other.

Reading the two questions together is the point of laying out an architecture like this at all. Knowing that your entries stay on your device and in your own iCloud tells you something true and useful about exposure — who else could ever see this, under what circumstances, and the answer here is close to nobody, under close to no circumstances. It tells you nothing about whether a given correlation the app surfaces reflects something real about your body and the weather, or is a coincidence built from a short run of entries. Both questions matter. Keeping them separate, rather than letting one stand in for the other, is what makes either answer worth anything.

The figure above lines up each of the three destinations with exactly what travels there — and its last row is the point that's easy to lose in a list of outbound calls: what stays, and never goes anywhere at all.

What we haven't done yet

Coordinate precision. Right now, full-precision coordinates go to the weather service, even though a forecast only needs accuracy to about a kilometre. Rounding that down is planned. It isn't shipped yet, so it isn't done.

The location-permission wording. The system permission text you see when the app asks for your location is currently phrased more broadly than it needs to be. It's being rewritten to say something narrower and more accurate.

One line of interface copy about sync. A phrase in the app's settings currently describes how syncing works in stronger terms than are actually accurate. It's being rewritten. There's no more detail to add here beyond acknowledging that it's been found and is being fixed.

A review of the App Privacy declaration. Given that coordinates go to a third-party weather service, the declaration on the App Store deserves a second look to confirm it's stated correctly. That question has been raised. There's no answer yet.

This list isn't separate from everything above it — it's the same architecture, described honestly at the point where it's still incomplete. A privacy article that reads as though everything were already finished is worth less than a list of what still isn't.

That's the architecture, as of the date at the top of this page. For a way to check something like this for any app, including this one, the checklist for reading an app's own App Store page before installing it covers that ground. For what the on-device correlation itself does, the weather-correlations feature page describes it directly. And because an architecture described on its own says nothing about whether this is the right app for you, the side-by-side reading of three App Store pages sits next to it — including the cases where that reading lands on someone else's app.