Blog

Why the AI runs on your phone

4 min read

A food diary is a more revealing document than most people realise. Not holding it turned out to be a design constraint that shaped both apps, and it cost more than it sounds.

What a food diary actually contains

A food log is not a list of calories. Read six months of one and you can work out when somebody was ill, when they stopped sleeping properly, when they started drinking more, when they were travelling, and when they gave up. Add a weight history and you have a medical record nobody asked a doctor for. The photos are of their kitchen, their table, and sometimes the people sitting at it.

Most calorie apps treat all of that as ordinary product data. It sits in a database, it gets backed up, and it gets analysed to improve the product, which is usually true and always vague. One acquisition or one breach later it belongs to somebody the user has never heard of.

We decided early that we would rather not hold it. Policies change when the incentives behind them change. Software is harder to argue with.

Deleting it later is a promise. Never having it is not.

The normal way to build an AI feature into a mobile app is to send the input somewhere. Your photo travels to a GPU in a data centre, a model runs, a result comes back. The app on your phone is a thin client in front of somebody else’s API.

Even when a company is entirely honest about this, certain facts hold. The photo left your device. It was processed on hardware you cannot inspect. It existed, for some period, in somebody’s logs. Every protection you have is a commitment that company has chosen to keep, and commitments last exactly as long as the incentives behind them.

So the model had to run locally. Everything else followed from that.

The cost, which is real

Running a model on the phone means shipping a model to the phone. Ours is about 2.4 GB.

Somebody has to agree to that download, give up the storage, and own a device capable of running it. Below a memory floor the AI features are unavailable and logging stays manual, because the alternative is falling back to a server and undoing the point.

We also went without what a backend gives you. Today there is no sync between your devices, no web version, and no copy of your data anywhere except the phone in your hand. Export exists because of that, not as a checkbox.

Two items on that list we intend to build: backup, so that losing a phone stops meaning losing three years of logs, and sync, for anyone who uses more than one device.

Both cost money to run, so both will be paid. That has a useful side effect: nobody ends up backing up or syncing by accident, since paying for something is difficult to do without noticing. They will stay off until you switch them on, and whatever leaves the phone will be encrypted so that we cannot read it.

A feature that quietly reverses the guarantee is not worth shipping. Opting in has to mean you chose it, not that you failed to find the setting.

Then we built a second app

Burnin came first. Cookin came later, and needed the same kind of local model for its own features.

The arithmetic gets uncomfortable at that point. Two apps carrying a model each is close to 5 GB on a phone, to run two small free apps. Nobody would accept that, and they would be right not to.

So the apps share one copy. Install both and the second finds the model the first already downloaded, and uses it rather than fetching its own. On iOS they share a container and read the same file. On Android sharing the file turned out to be impossible, for reasons that took a test on real hardware to establish, so the apps share the running engine instead: whichever one holds the model does the work for the one that does not.

What we still send

Three things leave the phone.

Both apps send anonymous product analytics: screen names and counts, so we can see which features get used. No content, and no identity.

Food search queries go to public nutrition databases. The word you typed leaves the device. Your log does not.

The model is downloaded once, from a public host, the first time you need it.

Your food log, your weight history, your photos and your recipes are on none of those lists, and there is nowhere for them to go.

Why it was worth it

It makes the product worse in ways you can measure. Our AI is weaker than a frontier model in a data centre. It is slower on an older phone. It cost months of work that an API key would have covered in a week.

What it buys does not show up in a feature comparison. There is no version of this where your food diary appears somewhere you did not expect, because there is no copy of it for anyone to find.