Nerdy stuff

Last updated 3 August 2026

Most health apps are vague about where their numbers come from, because the honest answer is usually "an average, adjusted a bit". This page is the opposite: what the app actually does, where the processing happens, and what it deliberately refuses to do.

The rule everything else follows

No figure is ever invented to fill a gap. If you did not log breakfast, the day's calorie total does not quietly assume one. If your watch was on charge, the sleep tile says the night is missing rather than interpolating it. A number that is absent is shown as absent, with the reason, and it is left out of any score that depends on it.

This sounds obvious and is surprisingly rare. It is also the reason some screens will look emptier than a competitor's: the space where an estimate would go is left visibly empty on purpose.

Where the AI runs

The written summaries — the short paragraph on each tab that reads your week back to you — are generated by Apple's Foundation Models, the language models built into the operating system since iOS 26. They run on the device itself. Your food diary is not sent anywhere to produce them, there is no API key, and it works in aeroplane mode.

This has a practical consequence worth stating plainly: the summaries are produced by a small model, not a frontier one. They are good at "you logged 40g of fibre four days running and your symptoms were milder" and deliberately not asked to do anything resembling diagnosis.

Two other jobs run on-device through the same route: reading a nutrition label from a photograph, and condensing what you have written about yourself into a form the summaries can use. Both were built this way for the same reason — the input is a photograph of your dinner or a paragraph about your health, and neither needs to leave the phone.

On-device only, as a setting

Some processing is currently done on a server: researching an unfamiliar product's nutrition, and the longer analyses that look across months rather than days. These are the jobs a small on-device model genuinely cannot do well yet.

You will be able to switch them off entirely. An on-device-only mode is being built as a toggle at setup and in Settings. With it on, nothing about your health leaves your device: you lose the deeper analyses and automatic nutrition lookup for products nobody has scanned before, and you keep everything else. The trade is stated on the switch rather than buried, because it is a real trade and you should get to make it.

Where server processing is used, Apple's Private Cloud Compute is the intended destination — the same on-device privacy guarantees extended to larger models, with no retention and independent verification. That work is in progress and gated behind an Apple entitlement.

How your data is stored

Every person gets their own database. Not a shared table with a user column and a filter — a separate database, with its own access token. This is a structural choice rather than a policy one: the usual "WHERE user_id = ?" arrangement means one missing clause anywhere leaks somebody else's health record, and no amount of care makes that impossible. Separate databases make it impossible by construction.

The part of the app that reads your data cannot write. It is not that it does not write — the code that serves every screen physically refuses any statement that is not a SELECT, and rejects it before it reaches the database. Writing happens in a separate service that cannot read anything back. A bug in the part you look at cannot corrupt your record.

There is one shared database, and it holds no personal data at all: the product catalogue. When you scan a barcode nobody has scanned before, the product's name and nutrition can be contributed so the next person's scan finds it. What is shared is the packet, never the meal — not when you ate it, not how much, not who you are.

Where the numbers come from

Nutrition targets are not one-size-fits-all. They are derived from your height, weight, age and sex, against UK reference values — the Scientific Advisory Committee on Nutrition's recommendations, and NHS Eatwell guidance. Fat at up to 35% of energy, saturated fat up to 11%, carbohydrate around 50%, free sugars under 5%. Fruit and veg is five portions, with the standard caveat applied properly: juice and smoothies together count once per day and no more, however many you drink.

Free sugars are reported as a range, not a single number. Packaging declares total sugars, which includes the sugar naturally present in fruit and milk. Turning that into free sugars requires knowing the recipe, which is often not stated. Rather than pick a number and present it with false confidence, the app shows the range the label actually supports and tells you which end is certain.

Every score is inspectable. Tap any figure and the app shows the arithmetic that produced it — which components counted, what each was worth, and what was excluded for want of data. If a score looks wrong, you can find out why rather than take it on faith.

What is being researched

The app is being used to answer a real question: what actually predicts a particular set of gut symptoms. That work is ongoing and honest about its own limits — a single person's diary is a case series of one, and correlations found in it are hypotheses, not findings.

What the app does with that is deliberately conservative. It will tell you that two things moved together and how often; it will not tell you that one caused the other. Where a pattern is based on a handful of days, it says how many days, because "on 3 of 4 occasions" and "on 30 of 40" deserve very different amounts of belief.

Sources, and what is coming

Today: Apple Health for sleep, heart rate, steps and workouts, with whatever history your phone already holds — so trends and baselines work from the day you install rather than starting empty. The app also works completely without it, for people who track nothing automatically.

Coming: Fitbit and WHOOP support, and an Android version. The data model was built source-agnostic from the start — each metric records where it came from — so adding a source does not mean rewriting the analyses.

Built on

Native SwiftUI for iPhone, iPad and Mac — one codebase, one purchase, and the layout adapts rather than being stretched. Python and SQLite behind it. No tracking, no analytics SDK, no advertising identifiers, and no third party receives your health data. There is nothing in the app that reports back on how you use it.

None of this is medical advice, and the app is not a medical device. See the terms for what that means in practice.