You see the phrase on app store pages, on landing pages, in the fine print of privacy policies. "Local-first." "On-device storage." "Stays on your phone." The phrases sound similar, mean slightly different things, and almost no app explains what is actually happening in language a non-technical person can use. This is that explanation.
What "local-first" means
Local-first is a software design pattern. It means the canonical, authoritative copy of your data lives on your device. The device is the source of truth. Anything else (a backup, a sync, a server) is a derivative copy.
For a journal app, that translates to a simple test. When you tap save on a journal entry, where does the entry actually live a second later. If the answer is "on my phone, and only on my phone unless I choose otherwise," the app is local-first. If the answer is "on a company server, and a copy is cached on my phone," the app is cloud-first.
Both designs are valid. They protect against different things and create different tradeoffs.
The three kinds of journal app storage
Almost every journal app on the market falls into one of three storage models.
The first is cloud-first. The company runs servers. Your entries live on those servers. Your phone holds a local cache for offline use. If the company goes away, your data goes away unless you exported it. If the company's database is breached, your data is in the breach. Day One, Penzu, and most mood-tracking apps follow this model.
The second is local-first with optional cloud sync. Your entries live on your device by default. The app offers cloud sync as an opt-in feature, often for cross-device use. The cloud copy is a backup or a sync layer, not the source of truth. Apple Notes and some open-source journal apps follow this model.
The third is local-only. Your entries live on your device. There is no cloud option. If you lose the device without a backup, the entries are gone. Unstuck follows this model. Plain paper notebooks also follow this model.
The differences are not just technical. They produce different privacy postures, different recovery models, and different relationships between you and the company.
What local-first protects you from
Local-first storage protects you from a specific list of risks.
Server breaches. A breach of a cloud-first journal app exposes the entries of every user. There is no way for an individual user to prevent this kind of breach beyond choosing an app that has fewer entries on a server. Local-first reduces the entries-on-a-server count to zero.
Company policy changes. Cloud companies update their privacy policies. The data you wrote under one policy can be governed by a different policy six months later. Local-first journals are not subject to this. The data never left the device.
Acquisitions. A cloud company can be acquired. The acquirer can do things with the data that the original company would not have. Local-first journals are not affected by acquisitions of the app maker, because the journal is not held by the app maker.
Behavioral analytics on journal content. Some cloud apps run analytics over the aggregate text people write. Some train AI models on it. Local-first journals do not allow this, because the company never has the text.
Subpoenas to the company. If law enforcement wants a cloud user's entries, they serve the company. If they want a local-first user's entries, they have to serve the user (or seize the device).
This list is real. It is not theoretical. All of these events have happened to journal apps in the last decade.
What local-first does not protect you from
Local-first is not a complete privacy solution. Five things it does not help with.
Loss of the device. If your phone is lost, stolen, or destroyed, and you have no backup, the journal is gone. The privacy upside is that nobody else has a copy either. The personal downside is that you do not.
Forensic extraction. If someone has physical access to your unlocked device and the right forensic tools, they can recover data from it. App lock and biometric unlock help against casual access. They do not help against a determined attacker with the device in hand.
iCloud Backup. If you have iCloud Backup turned on at the iOS device level, your app data can be included in your encrypted iCloud device backup. That backup is Apple's responsibility to protect. Apple offers Advanced Data Protection, which adds end-to-end encryption for iCloud backups; without that setting, certain Apple categories are encrypted but accessible to Apple under legal compulsion.
Exported files. Once you export a journal to a file and email it, share it, or store it somewhere else, the file is no longer local. The export inherits the privacy posture of wherever it ends up.
Compromised device. Malware on a jailbroken iPhone, a compromised iCloud account, or a person with your device passcode all bypass the protections that make local-first useful. Local-first assumes the device itself is reasonably secure.
These limits are honest tradeoffs, not flaws. They are also smaller in aggregate than the risks a cloud-first app introduces.
The tradeoffs you have to manage
Choosing a local-first journal means choosing to manage three things yourself.
Backups are yours. If you want to be able to recover your journal after a device loss, you have to export periodically and store the export somewhere you control. Once a month is a reasonable cadence for most people. Store the export in a password-manager encrypted note, an encrypted cloud drive, or an encrypted external drive.
Device transfer is yours. When you replace your iPhone, you have two options. Use Apple's Quick Start or iCloud Backup restore, which carries the journal along with everything else. Or export from the old device and import to the new one manually. Both work.
Recovery from mistakes is yours. There is no "I deleted that entry by accident, can support restore it" path on a local-first app. If you delete, the entry is gone unless you have an export from before the deletion. The mitigation is the same as for device loss: periodic exports.
These are real responsibilities. They are also the price of not handing your journal to a company.
A note on what counts as "encrypted"
Many cloud apps advertise that data is "encrypted." That word does a lot of work, and the same word can mean very different things across apps.
Encryption in transit means the data is encrypted while it travels from your phone to the company's server, and then decrypted on arrival. Almost every app does this. It protects against eavesdropping on a coffee-shop Wi-Fi network. It does not protect the data from the company once it lands on the server.
Encryption at rest means the data is encrypted while sitting on the company's database. Most cloud apps do this. The encryption key is held by the company. The company can decrypt the data at will, and the company's employees, vendors, and any subpoena can also reach the data.
End-to-end encryption means the data is encrypted on your device with a key the company does not have, and only your device can decrypt it. Signal-style. Very few wellness or journal apps use this model, because it makes most product features harder to build. When you see "encrypted" without "end-to-end," assume the company can read the data.
Local-first does not require encryption at all in the same way, because the data does not travel anywhere a company-held key would matter. iOS data protection encrypts data on the device when the device is locked, and that is the relevant layer for a local-first journal.
Why this matters for a wellness app specifically
A journal is not a calendar. The entries in a journal are not records of events that already happened in public. They are the actual contents of someone's mind on the days they wrote.
The privacy posture of a wellness journal is not separate from whether the journal works. People write differently when they believe the writing is private. People write more honestly when they trust the writing will not show up somewhere. People stop writing when they discover that the privacy they assumed was not the privacy that actually existed.
A cloud-first journal asks you to trust the company today, the company tomorrow, the company's vendors, the company's database administrators, the company's policy team, the company's future board, the company's potential acquirer, and any law-enforcement agency that decides to ask. A local-first journal asks you to trust yourself with your data.
For a wellness app, the second model is the better fit.
How Unstuck does local-first
Unstuck stores journal entries, check-ins, reminders, routines, and tool history on your iPhone in the app's data store, protected by iOS data protection.
There is no Unstuck-operated server holding a copy. There is no account, no sign-in, no email tied to your data, no public profile. The privacy policy at /privacy describes exactly what the website holds (essential technical logs, support emails you choose to send) and what it does not (your journal, your check-ins, your reminders).
The Consumer Health Data Notice at /consumer-health-data covers state-law-specific rights for Washington, Nevada, and Connecticut. The Privacy Pledge at /privacy-pledge is the plain-English companion to the legal text.
If you want the case for why we built it this way, see /journal/why-a-wellness-app-should-not-need-a-cloud.