App privacy: what our apps send, and what stays on your device

Five of our apps have no sign-up screen. There is no account to create in slotho, badmintho, pluris, FlowMail or formatho, and no red8.io server holding what you log in them. That is the easy half of app privacy, and it is the half every privacy page says. The harder half is the one they tend to skip: the moments an app does reach the network, what goes with the request, and who receives it. This post is that half.

The five — slotho, badmintho, pluris, FlowMail and formatho — do very different jobs: food logging, badminton scoring, contact cleanup and passwords, email, Azure DevOps work items. What they share is an assumption. The interesting data is yours, and the sensible place for it is the device in your hand. The sixth product, Cortex, works the other way round on purpose, and it gets its own section below.

What “no account” actually means

It means there is no sign-up screen because there is nothing to sign up to. No email address to give, no password to choose, no profile to complete, no forgotten-password flow, no settings page on a website somewhere with your name at the top of it.

It also means we cannot restore your data if you lose your phone, cannot look at your logs to diagnose a bug you report, and cannot tell you what you ate last March. Those are real costs and we accept them, because the alternative is holding all of it.

One thing worth saying precisely: your logs are not anonymised on our side, because they never reach our side. Anonymised data is data somebody has. Where an app does send us something — a usage count, a waitlist address, an AI allowance — this post names it.

Where the data actually lives

slotho — food, water, caffeine, sleep, workouts and fasting are stored on your iPhone, iPad and Apple Watch and written into your own Apple Health. They move between your devices through your own iCloud, under your Apple Account, not ours.
badmintho — scores, match history, player names and settings sit on the device, and every match is saved to Apple Health as a badminton workout with the heart rate, energy and movement recorded during play.
pluris — your contacts, photos, calls and messages are read, compared and filtered on the phone itself. Passwords live in the iOS keychain, and reach your other devices only through Apple’s iCloud Keychain, if you have it switched on.
FlowMail — mail is fetched from your provider straight to your device and stored there so you can read offline. Sign-in tokens and app passwords live in the Keychain, the same encrypted store Apple’s own apps use.
formatho — almost nothing is stored at all. Work items and query results are held in memory while the app is running and are gone when you quit; the only things kept between launches are your settings, in formatho’s own sandboxed storage on your Mac.

App privacy, request by request

Now the part that gets left out. Some of these apps talk to the network, because some of these jobs cannot be done otherwise — you cannot look up a food without asking someone who knows about food, and you cannot read email without contacting a mail server. Here is every one of them.

What leaves each app, in one card. The detail follows.

slotho: food lookups, PRO’s AI, and one contribution that becomes public

Searching for a food or scanning a barcode queries two public databases — Open Food Facts and the USDA’s FoodData Central — alongside a library of over 300 common foods built into the app, which needs no request at all. What travels is the search itself: the words you typed, or the barcode number you scanned. No name, no account, no health data, no log goes with it. Results are cached, so looking the same thing up twice makes no second request.

A few smaller requests, easy to miss because they do not look like lookups. When a food has no picture, slotho can find one on the open web: the food’s name goes to a public image search engine — Brave, Bing, DuckDuckGo, Qwant or Yandex, tried in turn until one answers. Tap Find places near me on a meal and slotho asks Apple Maps for venues around a coordinate, never with the meal. Translating a label uses Apple’s own Translation framework. And the app asks Apple’s public iTunes lookup which version is current, which carries the app’s identifier and nothing about you.

Then the AI. Typing “two eggs and a coffee” to log it uses Apple’s on-device model by default, and the sentence stays on your iPhone. Two things go further, and both only when you ask. You can connect an AI provider of your own with your own key, and then what you send goes to them, not to us. And slotho PRO’s AI features — reading a meal photo, drafting a plan, voicing a meditation — run through a small service we operate on Google Cloud. It checks that the request comes from the genuine app and a current subscription, passes it to Google’s Gemini models on Vertex AI, or to Google’s text-to-speech for a voice, and returns the answer. Google processes it as our service provider and does not use it to train its models.

What goes with a PRO request is only what the feature needs: a photo is shrunk and re-encoded first, which strips its location and capture time, and nothing from Apple Health, your logs or your identity is attached. slotho asks before the first photo and the first text request. What we keep is a count of how much of your monthly allowance you have used, stored against the anonymous transaction number the App Store gives your subscription — not your name or your Apple Account. The photos and words themselves are not stored.

There is one exception worth reading twice. If you create or correct a food and it has a barcode, slotho submits it to Open Food Facts, where it is public and permanent under that project’s open licence — and if you attached a photo, the photo is published as that product’s front image. It goes through a shared slotho contributor account, so it is not attributed to you by name, but the photograph is public. Point the camera at the product, not at your kitchen.

badmintho: nothing, unless you switch one thing on

In normal use badmintho makes no outbound requests at all. Playing a shared match with other people uses Bluetooth, directly between the devices in the room — the score and the players’ names travel over that link and nowhere else, with no server in the middle.

There are two exceptions, and both are off until you act. The first is a setting called Share anonymous usage stats, which is off when the app arrives. While it is off, nothing is recorded and no request is ever made. Switched on, it counts a small fixed set of events about the paid features — the upgrade screen appearing, a trial starting, and so on — and sends them to our server once a day as daily totals, with no identifier for you or your device.

The second is the Community waitlist in Settings, where you can leave an email address to be told when badmintho Community launches. That one is identifying — it is an email address, and we hold it — so it is worth naming plainly rather than filing under “anonymous”. It is the only place in these five apps where you hand us something that points back to you. You can leave the waitlist from the same screen, and your address goes with you.

pluris: downloads, and nothing uploaded

pluris touches four of the most personal things on a phone and sends none of them anywhere. The duplicate matching, the number repair, the photo fingerprinting, the message filtering — all of it happens on the device. What the app fetches is a public, community-maintained list of known spam numbers, checked at most once a day, plus any lists you add yourself with Pro, each from the address you gave. Those are downloads: nothing about you goes up with them. The search button beside a number in a contact opens a Google search in your browser, and only when you tap it.

Call blocking is worth understanding, because the design is what makes it private. pluris hands iOS a list of numbers and iOS does the blocking itself, inside the system. The consequence is that pluris cannot see who called you, when, or whether anything was stopped — iOS reports none of that back to an app, deliberately. It is also why the app can tell you how many numbers are on your list but never how many calls it actually blocked.

The next version adds one exception, off until you switch it on. With pluris Pro, the password vault’s organiser can run on Google Gemini through a small service of ours, and what it sends is item titles, groups and notes with every secret replaced by a placeholder first — never a password. The pluris privacy policy already describes it in full.

FlowMail: your mail servers, a public list, and a one-off model download

FlowMail talks to your mail provider, which is what an email client is for. Microsoft sign-in happens on Microsoft’s own page, so your password is typed into them and never into FlowMail. For other providers it may ask the public autoconfiguration service which servers to use; that request carries your email domain, never your password.

To tell which organisation owns a sender’s domain, FlowMail uses the Public Suffix List, a public list of domain endings such as co.uk. A copy ships with the app, and FlowMail fetches the current one at most once a day; the request carries nothing about you or your mail, and you can switch it off in Settings.

The AI features are the part people expect to be a trick. They are not. The model runs locally on your device — your messages are not sent to OpenAI, Anthropic, Google or anyone else, because FlowMail has no such integration to send them through. You pick a model, it downloads once from a public repository carrying nothing about you, and it runs offline from then on.

If you wire up an MCP server yourself, or build a workflow with a step that fetches a page, those requests go where you pointed them. That destination is yours, not ours.

formatho: one destination, and every request a read

formatho sends your credentials to exactly one place — dev.azure.com — as the standard authorisation header every Azure DevOps client uses. Not to us, not to a log file, not to anyone else. Because the Personal Access Token is one you generated yourself, you can revoke it whenever you like and the app immediately loses access, with no involvement from us.

Every request it makes is a read. The app contains no code that creates, edits or deletes anything in Azure DevOps, so a read-only token is enough to run it — and if you would rather not grant more than that, don’t. There is no analytics in it, no crash reporting, no advertising, and in fact no third-party code in the app at all.

Cortex: the one with accounts, on purpose

Cortex is a workspace you share with your team — projects, mail, meetings, notes — and a workspace several people share needs a server and a sign-in. So Cortex is the opposite of the five above, and it says so: your workspace lives on a server we run, in the EU, in a tenant of its own. You can ask for an archive of the whole tenant whenever you like, and a deleted tenant is purged after 30 days, its encryption key included.

Because here we do hold your data, the hosted service has its own privacy policy and a data processing agreement, which is the contract that says what we may do with it. If your data has to stay on your own infrastructure, Cortex can be self-hosted, set up with us on request. Then you are the data controller for everything inside it, and by default a self-hosted instance does not contact us at all.

What stays on the device, every time

A lot of what looks like it must need a server does not. All of the following runs on the device:

Barcode reading and label text recognition in slotho, using Apple’s on-device vision. Only the resulting number is ever sent.
Photo and video fingerprinting in pluris. Your photos are not uploaded or sent for analysis; there is no cloud processing step in that app to send them to.
The decision on every unknown sender’s message in pluris, made from the keyword lists and rules on your phone.
Jump detection and movement measurement in badmintho, sampled a hundred times a second from the motion sensors and turned into statistics without leaving the watch or phone.
Your position, when badmintho offers to tag a match with the court you are at. It compares your location against your own saved favourites on the device — your position is not stored and does not leave the phone. What gets saved with the match is the venue’s coordinates, not yours.
Every contact comparison, number repair and similarity score pluris computes.
The language model behind FlowMail’s summaries, replies and triage.

What this costs us

It is worth being straight about the trade, because “privacy-first” is cheap to write on a landing page and the interesting question is what you gave up for it.

We have no funnel. None of the five apps carries analytics, crash reporting or advertising; the closest thing is badmintho’s opt-in daily counts, and those arrive as a handful of numbers. When something breaks, we find out because somebody emails us — which means the support address is not a formality, it is the instrumentation. We cannot A/B test our way to a decision, so we have to think about it instead. And we cannot show you your own history from a backup, because there isn’t one to read.

The upside is the part that matters. A breach on our side cannot expose your food log, your matches, your contacts or your mail from these apps, because there is no database of them on our side. What we do hold is short, and this post has named all of it: a waitlist address if you gave one, usage counts if you switched them on, and the allowance counts behind slotho PRO’s AI. Not because we are principled about it every quarter, but because the rest was never on our side of the wire in the first place.

Where this changes: badmintho Community

Everything above describes how these apps work today, and it would be dishonest to dress it up as a promise that nothing will ever change. Some things genuinely cannot be built on a device alone. Finding a court near you, being matched with a player at your level, and holding a ranking that means anything all require a server that several people share — and that is exactly what badmintho Community is going to be.

So it will have accounts, because a ranking needs to know whose it is. It will store the results of Community matches, because that is what a ranking is made of. We would rather tell you that now, while it is still a waitlist, than let you find out from a changelog.

What we are committing to is narrower than “never”, and more useful: Community will be a separate thing you opt into, and badmintho will keep working without it. If you never join, nothing changes — no sign-in appears, your matches stay in Apple Health, and the app makes no more requests than it does today. The parts that shape the design are already visible in how it is being built: the court usage counter deliberately carries no user identifier, so it can rank courts by real use without becoming a record of who played where and when; and the analytics counters accept an anonymous token rather than requiring an account.

The rule, then, is not “we will never run a server”. slotho PRO already runs through one, and Cortex is one. It is: what is on your device stays on your device unless you choose otherwise, and we will say plainly when the boundary moves. This post is where that boundary sits in October 2026. When Community ships, the badmintho privacy policy will say exactly what it holds, and there will be a post like this one explaining it.

Read the actual policies

Everything above is a summary, and summaries lose detail. Each product has its own policy, written in plain language and specific about its own edge cases:

If something in this post does not match what an app actually does, that is a bug and we want to hear about it: privacy@red8.io.

What leaves your device, and what never does