Back to docs

What changed modal after release

Show users exactly what shipped the moment they launch the new build.

Why it matters

Users skip changelogs buried in settings. A one-time modal on first launch after an update guarantees every active user sees what changed — new features, critical fixes, or breaking changes.

Ingredients

  • Version stamp — store last-seen version in a local config key (registry on Windows, plist on macOS).
  • Changelog payload — bundle a small JSON or Markdown file with the release; the loader reads it at startup.
  • Modal window — native dialog or custom overlay with a scrollable body and a single “Got it” button.

Flow

  1. Loader reads last_seen_version from disk.
  2. If current version > last seen, parse the bundled changelog.
  3. Render the modal before the main window appears.
  4. On dismiss, write current version to disk.

Edge cases

  • Fresh install — no last-seen key exists; skip the modal (user has no prior context).
  • Corrupt changelog — fall back to a generic “A new version is available” message; never crash.
  • Downgrade — if current version < last seen, reset the key and show nothing.

Nimbus specifics

The loader already ships a signed payload blob. Append a versioned changelog.json section inside the payload. The UI thread reads it after license validation but before the dashboard renders. Keep the modal under 400px wide with the brand gradient on the dismiss button.