What's New

Publishing a changelog is a small act of transparency that costs us nothing to fake and everything to skip. Anyone can claim an app is constantly improving; a changelog is the receipts. Every entry here is a real, shipped change, grouped by the month it went out, not a marketing wishlist or a roadmap of things we hope to build someday. That distinction matters because trust in a small independent app is built entry by entry: if the changelog says a feature landed, you should be able to open the app and find it, not just find another promise.

Shipping roughly weekly instead of in occasional large releases has a practical upside for you: bug fixes and small quality-of-life improvements reach your device in days, not months, and a feature request that gets picked up does not sit in a backlog for a year before you see it. It also means the changelog itself stays a genuine reflection of active, ongoing work rather than a page that goes quiet for long stretches and then dumps a dozen unrelated changes on you at once.

When you read an entry, look for what actually changed in behavior, not just the feature name: whether it is a new capability you can start using immediately, a refinement to something you already rely on, or a fix for a specific reliability issue. Entries are grouped by month so you can scan back to whichever release cycle you last paid attention to and see everything you missed since, rather than hunting through app-store release notes that often get overwritten the moment the next version ships.

The changelog is also where feedback loops back into visible results. If you request a feature or report a bug through the Support page, the fastest way to see whether it landed is to check here after an update - a fix or addition you asked for shows up the same way any other change does, described plainly rather than buried in generic performance-improvements language. That loop, from request to visible entry, is the point of keeping the changelog honest rather than promotional.