Why We Publish Our Own Changelog

Most apps hide their version history behind an app store’s “What’s New” box, three bullet points of “bug fixes and performance improvements” that tell you nothing. My Pocket publishes a real changelog instead, and I think that’s worth doing even though almost nobody asks for it.

It’s a form of accountability

Writing down exactly what changed, in plain language, in a place anyone can read at any time, means I can’t quietly ship a change and hope nobody notices. If a decision turns out to be wrong, it’s on the record — including the version where I reverted it. That’s a small discipline, but it keeps me honest about what actually shipped versus what I meant to ship.

It answers “did you fix that yet?” without an email

If you reported a bug three weeks ago and want to know whether it’s fixed, the changelog is often faster to check than waiting on a reply from me. It’s not a replacement for a direct answer, but it means you’re not stuck wondering whether something’s been silently ignored.

It documents the “why,” not just the “what”

A good changelog entry doesn’t just say a button moved — it says why. That context is genuinely useful for anyone paying close attention to how the app evolves, and honestly, it’s just as useful for me six months later when I’m trying to remember why a decision was made in the first place.

Transparency scales better than an FAQ

As a solo developer, I can’t staff a support inbox to answer “has this been fixed” for every open issue. A public, dated record of every real change does a lot of that work on its own, and it costs me a few minutes per release to maintain instead of an ongoing support burden.