Why Forge Is Built Exclusively on Apple — And Why That's the Point
Most journal apps treat your private thoughts like any other data — synced to company servers, stored in databases they control, accessible to employees with the right credentials. We built Forge differently, and the reason comes down to one architectural decision.
When you write in a typical journal app, here's what happens: your entry travels from your phone to the company's servers (usually AWS or Google Cloud), gets stored in their database, and syncs back down to your other devices. The company encrypts it "at rest" — meaning it's encrypted on their hard drives. But they hold the keys. Their engineers can read your entries. Their database admins can query them. If they get breached, your journal is in the breach.
Day One, the most popular journal app on the market, uses exactly this architecture. Your entries live on Automattic's AWS infrastructure. They offer end-to-end encryption as an option, but the default sync path routes through their servers. They had to build it this way to support their web app and cross-platform sync.
This isn't a criticism of Day One specifically — it's the standard approach. It's how most apps work. But a journal isn't most apps. A journal is the one place you're supposed to be completely honest. The architecture should reflect that.
Apple's CloudKit provides something unique: a private database tied to each user's Apple ID that we, as developers, literally cannot access. When you write a journal entry in Forge, your entry is stored locally on your device using SwiftData, then syncs to your private iCloud database — a container that only your Apple ID can unlock. With Advanced Data Protection enabled, it's end-to-end encrypted, meaning Apple can't read it either.
We don't have a server. We don't have a database of journal entries. We don't have access to a dashboard where we could look up what you wrote. The infrastructure doesn't exist for us to read your data, even if we wanted to, even if someone compelled us to. This isn't a privacy policy promise. It's an architectural fact.
I'm a security professional. I've spent my career understanding how data gets compromised — and it's almost never through some sophisticated hack. It's misconfigured databases. It's employees with too much access. It's acquisitions where data handling policies change overnight. It's subpoenas served to companies that hold your data because they can be compelled to produce it.
When I built Forge, I asked a simple question: what's the minimum amount of user data I need to touch? The answer was none. Apple's infrastructure handles storage, sync, and encryption. The only time your journal text leaves your device is during AI analysis, which is processed through Anthropic's API — they don't store or train on API inputs, and the text isn't persisted anywhere.
People ask about an Android version. Here's the honest answer: Android doesn't have an equivalent to CloudKit's private database model. Google Drive offers app-specific storage, but it's not end-to-end encrypted by default — Google can read the data. Firebase and Firestore are developer databases hosted on Google's infrastructure, which puts us right back in the architecture where we'd hold your data on our servers.
If we bring Forge to Android, it will likely be local-only — your journal stays on your device with no cloud sync. That's a real limitation, but it's better than the alternative of compromising on the privacy model that makes Forge what it is. We'd rather offer fewer features than make promises about your data that depend on a privacy policy instead of architecture.
There are plenty of journal apps that will sync your entries across every platform and device. Forge does something different: it keeps your entries in the one place where only you can access them. That's not a limitation of being Apple-only. It's the reason we're Apple-only.
Your journal should be the one app on your phone where you don't have to think about who else might be reading.