OtaKitChangelogs and release notes for Capacitor OTA updates
Store release notes do not cover over-the-air updates. How to manage changelogs for Capacitor OTA releases, surface them in-app when an update applies, and keep users informed of what changed.
Store release notes only cover store releases. When you ship a dozen over-the-air updates between binaries, none of them show up in the App Store “What's New,” and your users have no idea what changed. This guide covers managing changelogs for Capacitor OTA releases and surfacing them in-app with OtaKit — so silent updates don't mean silent communication.
Two audiences, two changelogs: an internal one (every release, for your team) and a user-facing one (curated highlights, shown in-app). Don't conflate them — users don't want your commit log.
Keep an internal changelog per release
Every OTA release should be traceable: what bundle, what changed, who shipped it. Tie your release to a git tag or commit and keep a running log. Conventional commits make this close to automatic — the release notes fall out of the commit history.
Surface a “What's new” in-app
Since the store notes can't cover OTA updates, show your own. Ship a small “What's new” payload with the bundle and display it after an update applies. Listen for the applied event and check whether this bundle has notes the user hasn't seen:
import { OtaKit } from '@otakit/capacitor-plugin';
OtaKit.addListener('updateApplied', async () => {
const notes = await loadBundledReleaseNotes();
if (notes && !seen(notes.version)) showWhatsNew(notes);
});Because the notes ship inside the bundle, they're always in sync with the code — no separate system to keep aligned. See Events for the applied event.
Match the changelog to the update UX
A silent background update pairs with a subtle “What's new” on next open; a mandatory update can show its notes on the update screen itself. Match the prominence to how the update was delivered — see background vs foreground updates.
Keep user-facing notes human. “Fixed the crash when adding a photo” beats “patch bump; see commits.” The changelog is a small, frequent touchpoint with your users — use it to build trust, not to dump diffs.
Where to go next
See the update strategy checklist for where communication fits, and Channels & runtime version for tracking what shipped where.