Desktop Installer Design

Installer & First-Run Design

The installer is the very first interaction anyone has with the app, before the app itself even opens — and it's one of the easiest places to accidentally ship the generic default wizard that came with your packaging tool. It deserves the same intent as everything inside the app.

Don't ship the packager's default look

NSIS, Inno Setup, electron-builder, and tauri-bundler all have functional-but-generic default installer chrome. Treat the default as a placeholder, not a finished product:

• Replace default installer icons/banners with the app's own brand art (see desktop-ui-icons for how the app icon should be built to scale down cleanly).
• Set the installer window's own accent color / branding to match the in-app palette (see desktop-ui-color-system) rather than leaving the tool's default blue.
• Keep the installer's own type and spacing consistent with the token scale used everywhere else in this skill family — an installer that looks like a different product than the app it installs is a jarring first impression.

Flow — keep it short, and skip steps that don't need a decision

A good installer asks for only the decisions that actually vary per install. Every extra screen is a chance for the person to bail before they've even seen the app.

Typical minimal flow:

1. Welcome — app name, icon, one line about what it does. No marketing paragraph.
2. License/EULA (only if legally required — many indie/open-source apps can skip this screen or fold acceptance into a single checkbox rather than a full screen)
3. Install location (default to the platform-standard location; only surface this screen if the user is likely to want to change it — power users appreciate the option, most people don't need to see it)
4. Progress — a real, measured progress bar, not an indefinite spinner, since install time is genuinely trackable
5. Finish — confirmation, with a "Launch now" checkbox/button, checked by default

Don't add extra screens for things that don't need a choice (a fixed set of components with no meaningful opt-out, for instance) — bundle those in automatically instead of manufacturing a "choose components" screen.

Platform conventions — don't fight them

• Windows: users expect an install wizard (NSIS/Inno) or an MSIX/Store-style silent install. Respect the standard back/next/cancel button placement and the platform's own window chrome for the installer itself — this is one place where not using a fully custom title bar is usually the right call, since the installer's job is to feel trustworthy and familiar, not to be a brand showcase.
• macOS: the drag-to-Applications-folder DMG pattern is the expected convention — design a custom DMG background (matching the app's brand) showing the app icon with an arrow toward the Applications folder shortcut, sized correctly for the DMG window. Don't replace this with a wizard-style flow; it reads as non-native.
• Linux: AppImage needs no install step at all (make sure this is communicated — "just run it," don't build a wizard for a format that doesn't need one); .deb/.rpm should integrate with the system's own package-manager conventions rather than a custom GUI wizard.

First-run / onboarding wizard (inside the app, after install)

This is a separate concern from the installer itself — it's the first thing the user sees inside the app:

• Keep it to the minimum needed to make the app usable — required setup (an initial config, a workspace/folder pick, a login if genuinely required) — not a marketing tour of every feature.
• Make it skippable wherever the app is still usable without completing every step; don't block someone from seeing the actual product behind a mandatory multi-screen tour.
• If there are optional feature highlights, prefer contextual "hey, you can do X here" hints that appear the first time a relevant screen is visited over a dedicated tour sequence up front — this respects that the user came here to use the app, not to be walked through slides about it.
• Reuse the actual in-app components (real buttons, real color tokens) for onboarding UI rather than building bespoke "marketing site" styling for it — a wizard that looks like a different product than the app itself undermines the very first impression it's trying to create.

Uninstaller

• Should be discoverable through the platform's standard mechanism (Windows "Apps & Features," macOS drag-to-trash or a bundled uninstaller for apps that write outside the .app bundle, Linux package manager) — don't invent a custom uninstall flow the OS doesn't expect.
• Ask before deleting user data/config (projects, settings, cached models) separately from removing the app binary itself — these are very different levels of destructiveness and deserve different confirmation weight (see the destructive-confirmation pattern in desktop-ui-surfaces-overlays).

Accessibility & internationalization

• The installer runs before the app's own UI even loads, often on a freshly set-up machine — use the OS's native installer framework (WiX/MSI on Windows, native pkg/notarized installer UI on macOS) rather than a fully custom-drawn wizard, so keyboard access and screen reader support come from the platform instead of being reimplemented from scratch. See desktop-ui-accessibility-i18n for the baseline.
• License text, step instructions, and button labels are frequently localized before the app's own in-app strings are — leave real headroom for translated text in step titles and buttons, not a layout sized exactly to the English copy.
• Never bake license or instructional text into an image.

Review format