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
- Loader reads
last_seen_versionfrom disk. - If current version > last seen, parse the bundled changelog.
- Render the modal before the main window appears.
- 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.