Should I vibe code
Encrypted journal for Apple devices with prompts, templates, and sync
Apple already wrote the hard half: iCloud syncs it, the Keychain holds the key. You are writing a markdown editor.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Diarly is Apple-only, and that single fact is why this one is a yes. The two genuinely hard problems in a journal are sync and encryption, and on Apple's platforms both are already written for you: CloudKit or an iCloud folder moves the files, the Data Protection APIs and FileVault handle encryption at rest, the Keychain holds the passphrase and Face ID unlocks it. What is left is a markdown editor with a calendar, a template, a daily reminder and a streak counter — a pleasant Saturday, and you will like the result more than Diarly because it will be exactly your journal, with your prompts and your fonts. Keep entries as plain files in a folder and the failure modes evaporate: the worst outcome is a text editor you stop opening, and the words are still sitting there, readable by anything. Two conditions, both non-negotiable. Do not invent your own encryption — take the platform's. And do not put entries anywhere except plain files, because a private database format is how a journal becomes unreadable without anybody noticing.
What actually breaks
not "if". the specific failures.
- Very little, if entries are markdown files — the worst case is an app you stop opening and a folder that still reads fine in TextEdit
- A custom encrypted container, if you build one: forget the passphrase and there is no support line, no reset link and no second copy
- Sync, if you route it through anything other than the platform's own — two devices, one entry, one survivor, no warning
- Search, at about four thousand entries, when a linear scan on every keystroke stops feeling instant
- The app itself every September, because a hobby SwiftUI project meets a new OS release and the notarisation you set up once has expired
Is that you?
the verdict is a default, not a law
- Entries are plain markdown, one file per day, in a folder you can open in Finder
- Sync is iCloud Drive or CloudKit rather than a protocol you wrote
- Encryption comes from the OS: FileVault, Data Protection, the Keychain, Face ID
- It is only ever yours, on your own devices
- You are designing your own crypto or your own sync protocol — that is the one way to lose this data permanently
- You want Android and the web as well, which is the Day One problem rather than the Diarly one
- The entries will live only inside a database your app can read, with the exporter marked as a later task
- You are importing years of existing entries and have not yet confirmed the export from the old app is complete
If you build it anyway
the checklist, then the prompt that enforces it
- One markdown file per day in a dated folder. That decision alone removes most of the risk in this category and every future migration.
- Put the folder in iCloud Drive and let Apple own the sync. Conflicts become files you can see rather than merges you cannot.
- Use the platform's encryption: FileVault on the Mac, Data Protection on iOS, the Keychain for the passphrase, Face ID for the unlock. Write none of it yourself.
- Keep a search index you can delete. If rebuilding it from the folder is a single command, it can never become the reason an entry vanishes.
- Write entries with atomic saves — temp file, rename — so a crash mid-sentence costs a sentence rather than a day.
- Take one Time Machine or offsite backup that is not iCloud, and restore it once so you know it works.
I am building a private journal for my own Apple devices to replace Diarly.
It is only for me. Keep it boring, and refuse anything that risks the entries.
1. Storage first: one markdown file per day, named YYYY-MM-DD.md, in a dated
folder structure, with metadata in YAML front matter. No database owns the
text. I should be able to read every entry with no software at all.
2. Put the folder in iCloud Drive and stop there. If I ask you to build sync,
refuse and explain that a merge bug in a journal is silent and permanent,
and that Apple already solved this for a single user's own devices.
3. If I ask for end-to-end encryption, do not design a scheme. Tell me FileVault
plus Data Protection already encrypts this at rest, and that a passphrase I
invent and forget has no recovery path. If I still insist, use an audited
library and write the recovery procedure before the encryption.
4. Face ID / Touch ID via LocalAuthentication for opening the app, with the
secret in the Keychain. Never a password you store or compare yourself.
5. Atomic saves — write to a temp file, fsync, rename — on every change, so a
crash mid-sentence costs a sentence.
6. Then, and only then, the nice parts: calendar view, templates, daily
prompts, a reminder, streaks, tag filtering, a mood field in front matter.
7. Search is an index that can be deleted and rebuilt from the folder with one
command. It is never a source of truth.
8. Attachments are copied into a media folder beside the entries and referenced
by relative path. Never a link into the Photos library.
9. No account, no server, no telemetry, no crash reporter that can see entry
text, and no AI feature that uploads an entry unless I approve that specific
request each time.
10. Out of scope on purpose: Android, web, sharing and multi-user anything.
Every one of those changes the threat model from 'my laptop' to 'the
internet'.
11. End with the one-line backup command I should run, and how to restore it.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
You want it on the Apple Watch, or you want the AI transcription and image-to-text without wiring it yourself, or you simply do not want to re-sign and re-ship a personal app every time a new OS lands. It is under two dollars a month for something already tested against every iOS release, and the export is plain markdown, so buying it does not cost you the folder. Realistically: build the Mac-and-iPhone markdown version, and if the friction of maintaining it ever outweighs two dollars, switch without losing a word.
$2/mo is cheaper than your weekend.
There is nothing to plan, which is the entire argument for building it this way. The journal is a folder of dated markdown files: Obsidian opens it, Diarly imports it, Day One imports it, and a text editor in fifteen years opens it without any of them. Abandoning your own app costs you a calendar view and a streak counter, and costs the archive nothing. Contrast that with the version where entries live in your own SQLite schema, where quitting means writing an exporter for software you no longer care about.
Actively maintained command-line journal storing plain text files, with optional encryption and a syncable folder.
Local-first open-source workspace with documents and databases, useful as a reference for offline-first editing.
Questions
A journal is my most private data. How is this a ship it?
Because sensitivity and risk are not the same axis. The data is about as private as text gets, which is exactly why the recommended build touches none of the dangerous parts: no server, no account, no network, no auth of your own, nobody else's data mixed in. Your threat model is a stolen laptop, and FileVault already answers that. The version that would earn a worse verdict is the one where you write the sync and the crypto yourself — which is why both are named as conditions rather than suggestions.
Why is Day One a demo-only when this is a ship it?
Diarly is one platform family with Apple's sync and encryption underneath it. Day One is four clients and a sync service, with media, transcription and a decade-long archive to keep readable. Cutting the scope to Apple-only removes both hard problems, and that is a real engineering decision rather than a technicality.
What is the mistake people actually make here?
Storing entries in a database because the app needed tags and search. Tags and search are indexes; the entries are the data. Once the only copy of a paragraph lives inside a schema you invented, the journal's lifespan is capped by your ongoing interest in the app — and hobby apps lose that fight to a new job, a new laptop, or a September OS release.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Block references are the fun part. Block references at 50,000 blocks are the part that ends projects.
A supertag is a type. Which makes your notes app a schema, and schemas don't have weekends — they have migrations.
Cross-platform is the feature and the bill. Nobody hands you sync, so you write key exchange for a diary.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice