Why Our Apps Keep Your Data On Your Device

Open most of our apps and you can start using them immediately. No account, no email address, no "sign in to continue". What you create stays on your iPhone, and syncs through your own iCloud account if the app supports sync.

This gets described as a privacy stance, and it is one. But the honest version is that it's also the simpler system, and the simpler system is the one a small studio can actually keep running.

What having no server means

If we don't hold your data, a long list of problems stops existing. There's no database to breach, because there isn't one. There's no account recovery flow, no password reset email, no support queue full of people locked out of their own reminders. There's no monthly bill that has to be covered by an app that costs £2.99 once. There's no migration to run at 2am, and no outage that takes an app on your phone offline because something in a data centre fell over.

For a countdown to an anniversary, a lock screen for a toddler, a log of when the fish are biting — none of that data needs to leave the device to be useful. Putting it on a server would add every one of those problems and improve nothing.

What you give up

This isn't free, and it would be dishonest to present it as pure upside.

Losing your phone can mean losing your data. If an app stores locally and you have no backup, that's genuinely gone. iCloud backup covers most people most of the time, but "most" is doing real work in that sentence. Where an app supports iCloud sync, turn it on.

No web version. Data on your device is data on your device. There's no dashboard to log into from a laptop, and there won't be.

Sharing is harder. Anything genuinely collaborative — two people looking at the same list — needs something in the middle. A few of our apps do have that, because the feature can't exist otherwise. Those apps say so.

Where we do collect things

Being clear about this matters more than the principle. Some apps include crash reporting and analytics, which send device model, iOS version, and anonymised usage events. Ad-supported apps show ads, which involves the ad network. Apps with subscriptions use purchase infrastructure to know whether you've paid.

None of that is us reading your content. But "we don't collect your data" would be too broad a claim to make honestly, so we don't make it. The privacy policy sets out what each category covers.

The account question

When an app does need an account — and a couple do — the test is whether the feature is impossible without one, not whether an account would be convenient for us. Sharing something between two phones needs an identity on both ends. Counting days until a date doesn't.

The pattern worth naming is the app that demands an email address on first launch for a feature that runs entirely on-device. That account isn't there to serve the user. Once you notice it, you see it constantly.

Not a moral position

We're not claiming the moral high ground here. Plenty of good software needs servers, and building on-device isn't automatically more virtuous.

It's that for the kind of apps we make — small, single-purpose, used by one person on one phone — local storage is both the more private option and the one that doesn't quietly rot when nobody's paying attention. When the simplest architecture and the most respectful one are the same architecture, the decision makes itself.