A comparison · ~5 min read
Bear vs Evernote Export: Which Survives the App?
The right time to test an export button is before you need it. Both Bear and Evernote export to the same file format (ENEX). The archives look nothing alike, and the story of what happens if the app dies is very different.
Same format, different archives
ENEX is an XML schema Evernote invented. Bear adopted it because it's the closest thing to a common note format. When you open a Bear ENEX and an Evernote ENEX side by side you see the difference immediately:
- Bear ENEX — one
<note> per note, clean HTML body (Bear's markdown compiled to minimal HTML), tags preserved, no attachments unless you opted in. - Evernote ENEX — one
<note> per note, but the body is often wrapped in Evernote-specific HTML (nested tables, inline styles, artifact from web-clipper captures), plus attachments encoded inline (fast way to a 4GB file).
Both are readable by any ENEX importer. Bear's is easier on the tools.
The lock-in question
What actually matters isn't the export button; it's what happens without one. Bear stores notes as individual .md files inside its app container, indexed by SQLite. If Bear shuts down tomorrow you can pull those files off disk with a five-line script. Evernote stores notes inside a proprietary database (.exb) that isn't documented publicly; ENEX export is your only lifeline. If Evernote ever paywalls the export button — which they've done and reversed twice — the archive gets a lot more expensive to reach.
Bear's architecture makes ENEX a convenience. Evernote's architecture makes ENEX a lifeline.
Where Konshus fits
Konshus takes either ENEX at /vault/import/enex and does two things: preserves each note as an artifact (source-of-truth), and distills recurring ideas across notes into atoms. So the tenth time you wrote "I want to work with fewer people, deeper" doesn't get lost among 4,000 notes — it becomes a durable memory the model you're talking to can actually reference.