Most journal apps can read every word you write. Morrow Self can't, even if we wanted to. Here is the architecture behind a private journal app that keeps entries on your phone.
Every journal app I have ever installed could read my journal. That includes the ones with the calmest landing pages, the ones with the locked-padlock icon in the corner of the marketing site, and the ones with privacy policies I actually bothered to read. Some encrypt at rest on their server. Some claim zero-knowledge. None of them can plausibly stop their own engineers from reading a row in a database table.
Morrow Self is built so that the people who run Morrow Self cannot read your journal. Not as a promise. As a property of the system. This piece is the long version of how, and why I think a private journal app is the only kind of journal app worth shipping.
The default state of wellness apps
The boring truth about most wellness apps is that everything you write is sitting in a Postgres table somewhere, joined to your email, joined to your device ID, joined to whatever the company's analytics provider thinks they need. The privacy policy will use the phrase "we may share with trusted partners," and the only trusted partner anyone actually checks for is the AI model the company is hoping to fine-tune on user content.
This is not a conspiracy. It is the path of least resistance. Storing journal text on a server is how you ship cross-device sync in a week instead of a quarter. It is how you build a recommendation engine. It is how you survive a Series A pitch where the investor asks what your data moat is. The companies are not lying. They are doing the obvious thing and writing a policy around it.
The result is that "private journal" has come to mean "you have to trust us." That is not the same as private.
What "on-device" actually means
When I say Morrow Self stores journal text on-device, I mean that the bytes corresponding to the words you write never leave the phone. There is no endpoint in our API that accepts journal content. There is no S3 bucket that contains the raw text. There is no Supabase row in any of our tables with a body field. If you put the app in airplane mode and write for a year, nothing changes except that you have a year of writing on your phone.
Concretely, here is what happens when you tap "save" on an evening review.
- The text is written to
MMKV, which is a fast key-value store backed by mmap on iOS and Android. - MMKV is encrypted at rest with a key stored in the iOS Keychain or Android Keystore. Both are hardware-backed on modern devices.
- The local store fires no network request. There is no "save to cloud" toggle that exists and is silently on.
The streak counter, the win checkmarks, and the journal metadata follow the same rule. None of it ever leaves the device unless you explicitly tap export.
The architecture, in plain English
The trick to making this real, not theatre, is to design the backend such that storing journal content is not even an accident you could make.
The Morrow Self backend is a Supabase project with two tables. One for waitlist signups. One for anonymized streak counters that fire only if you opt in. That is the entire surface area. There is no journal_entries table waiting to be filled in. There is no S3 bucket called user-text-backup. There is no Postman collection on my laptop with a POST /journal route stubbed out for later. If a future version of me wanted to read user journals, future-me would have to add the table, the endpoint, the client-side serialization, and the migration. That is at least three pull requests of obvious changes that I would have to ship through my own conscience.
The architecture is the promise. Engineering for "we cannot read your journal" is different from engineering for "we currently choose not to." The first one is checked at the schema level. The second one is checked at the privacy policy level. Only the first one survives a change of heart.
What that buys you
The thing it buys you is not really privacy. The thing it buys you is permission to be honest in writing. Most people who keep a journal have a censorship layer running quietly in the back of their head. "What if this leaks. What if a future me reads this and cringes. What if some recommendation system is now scoring my mood." That layer is faint, but it is there, and it changes what you write.
The on-device guarantee is the only thing I have found that turns the layer all the way off. You can write a sentence you would not want anyone, including yourself in five years, to read, and know that the only place that sentence exists is on a device you can drop in a sink. That is a different writing posture. The output is different too.
See the privacy page for the short version. See the tech page for the actual library choices.
The trade-offs
I am not going to pretend on-device storage is free. It costs three things, and they are worth naming clearly.
No cross-device sync, today. If you write on your phone and want to read on your iPad, you cannot. There is a sync roadmap that uses end-to-end encryption with a key held only on your devices, but it is not the first ship. If you depend on multi-device, Day One is the better app for you. I wrote a longer Morrow Self vs Day One piece on this.
No cloud-AI insights from journal text. The Pro tier ships pattern detection across wins and journal metadata. The journal text itself is never sent to a model. On-device summarization via small local models is on the roadmap, but the experience today is metadata-only. If you want a journal app that reads your entries and tells you your mood, this is not it.
No password recovery. If you lose the device, you lose the writing. The cloud cannot help, because the cloud genuinely does not have it. You can export to a local file at any time, and you should.
What still gets stored on a server
In the interest of not making this piece a marketing brochure, here is the honest list of what hits the network.
- Your email, if you sign up for the waitlist or a Pro subscription.
- Anonymous device-level event counts (app open, settings opened) if you do not turn analytics off in settings.
- Aggregated streak number (the count, never the contents) if you opt in to cloud streak backup.
- Subscription state via RevenueCat, which is required to verify you have Pro.
None of that is journal text. None of that is win text. The journal stays where the writing happens.
How to verify the claim
The honest test for an on-device claim is whether you can put the app in airplane mode, use it normally for a week, and have nothing break. Try it. Open Morrow Self, switch off cellular and wifi, write a morning intent, check off five wins, write an evening review, do a deep dive on Sunday. Nothing should fail. Nothing should silently queue. Turn the network back on and nothing should sync that should not exist on a server in the first place.
If you find anything that does, malik@aimobilelauncher.com, and I will fix it.
FAQ
Is Morrow Self a fully zero-knowledge journal app?
For journal text, yes. The text never leaves your phone. For account-level metadata like email and subscription state, no. Those are stored on the backend because they have to be for the app to function.
What happens if I uninstall the app?
Everything you wrote is gone. There is no cloud backup unless you exported a file. This is the cost of the model. Export regularly if your writing matters to you.
Will you ever add cloud sync?
Yes, with end-to-end encryption where the key never leaves your devices. The text on the server will be opaque bytes to anyone without the key, including me. That is the only sync model I am willing to ship.
How does this compare to Day One's encryption?
Day One offers end-to-end encryption as an optional feature you have to enable, and the keys are held by the user. Morrow Self does not offer cloud storage of journal text at all, with or without encryption. Both are defensible. Mine is the more paranoid version. See the comparison page.
If a journal app that physically cannot read your entries sounds like the right trade, download Morrow Self.