Release Checklist

A systematic verification sequence to confirm your Tauri v2 application is ready for production distribution, covering builds, resources, external binaries, and installers

Distributing a desktop application without a structured verification process is the fastest way to ship a broken installer to your users. A release checklist turns scattered manual checks into a repeatable, auditable sequence. For Tauri v2 applications, this means confirming that the build artifact is correct, every required asset is bundled, external binaries are present and functional, and the final installer behaves exactly as expected on a clean machine. Capabilities should already follow Permission Best Practices.

The items below walk through what to verify, why each check matters, and how to perform it. Treat this as the final gate before publishing — every “yes” moves you closer to a reliable release, every “not yet” catches a problem before your users do.

Checklists grow with your app:

The checks here form a baseline. As your application adds features, plugins, or sidecars, extend this list with custom verification steps that match your specific setup.

Pre-Release Preparation

Before you run the build command, a handful of housekeeping steps prevent version mismatches and last-minute surprises. These items are not build-specific, but skipping them causes confusion in bug reports and update pipelines.

  • Bump the version number in tauri.conf.json (the version field inside the package object) and in src-tauri/Cargo.toml (the version under [package]). Tauri uses the version from tauri.conf.json for the installer metadata, but keeping the Cargo version in sync avoids drift in CI or when publishing to crates.io.
  • Update your changelog or release notes. Even a brief list of user-facing changes — new features, fixed bugs, known issues — gives downstream testers and early adopters a clear picture of what the release contains.
  • Run a final regression pass on your staging or development build. Verify that every feature planned for this release is present, functional, and does not introduce visible regressions in core workflows.
  • Check for outdated dependencies (Rust crates and npm packages) with cargo outdated and npm outdated. Not every update needs to land in the release, but you should know if a critical security patch is available before shipping.

Version number mismatch causes silent update failures:

If your auto-update mechanism compares the version in the update manifest with the version reported by the app, a mismatch between tauri.conf.json and Cargo.toml can lead to update loops or missed updates. Sync both numbers explicitly.

Release Verification Sequence

The following steps are ordered: each one depends on the previous step completing successfully.

1

Step 1: Build the Release Candidate

A production build compiles the Rust backend with optimizations and bundles the frontend for distribution. Run the build command once, without any leftover development artifacts.

npm run tauri build

This command produces platform-specific bundles inside src-tauri/target/release/bundle. The exact output depends on your tauri.conf.json bundler configuration:

  • Windows: .msi and/or .exe (NSIS installer)
  • macOS: .dmg and .app bundle
  • Linux: .deb, .AppImage, or .rpm

Before moving on, confirm that the build completed without errors, the binary size is within expected range (a sudden jump usually means unintended debug symbols or duplicated assets), and the application launches when you run the executable directly from the output directory. Do not yet rely on the installer; launch the binary to rule out a packaging-specific bug masking a build issue.

Do not ship a debug build:

Running npm run tauri dev or cargo build without the --release flag produces unoptimized binaries that may leak debug symbols, run significantly slower, and expose internal paths. Always use the production build command.

2

Step 2: Verify Bundled Resources

Tauri allows you to include arbitrary files — images, configuration files, database templates — via the resources field in the bundle configuration. These files are packed into the final installer, but their presence is not validated automatically. A missing resource leads to a runtime error only after the user installs the app, so explicit verification here is critical.

Check your tauri.conf.json bundle configuration:

src-tauri/tauri.conf.json
{
  "bundle": {
    "resources": [
      "assets/icons/*",
      "config/default.json"
    ]
  }
}

After the build, navigate to the bundle output directory and check that each listed path exists relative to the installation location. For example, on macOS, inspect the .app bundle’s Contents/Resources/ folder; on Windows, look inside the install directory after running the installer.

What to look for:

  • The files are physically present, not just referenced.
  • Relative paths resolve correctly — Tauri preserves the directory structure from the project root.
  • Binary files (images, fonts) are not corrupted (open them manually).
  • The total size of the installed app matches the sum of the binary and the resource folder sizes.

If you reference a file in resources that does not exist at build time, the build may still succeed silently on some platforms. Always audit the bundle, not just the config file.

Glob patterns can silently skip files:

Glob patterns like assets/icons/* only match files directly inside the folder, not subfolders. Use assets/icons/** to include nested directories. A mismatch here is a common source of missing resources in production.

3

Step 3: Verify External Binaries (Sidecars)

When your Tauri app depends on an external executable — a CLI tool, a Python runtime, a bundled helper — you configure it via the externalBin field. These binaries are shipped alongside your app and invoked at runtime using the shell plugin or the Command API. An incorrect or missing sidecar causes a hard crash, often with a cryptic platform-specific error message.

Example configuration:

src-tauri/tauri.conf.json
{
  "bundle": {
    "externalBin": [
      "binaries/my-helper"
    ]
  }
}

The path is relative to the project root. Tauri will rename the binary with a target triple suffix for the platform (my-helper-x86_64-pc-windows-msvc.exe, my-helper-aarch64-apple-darwin, etc.) during the build. You must provide the correct binary for each target in the source directory.

Verification steps after build:

  1. Locate the sidecar in the bundle output. On Windows, it will be in the same folder as the .exe; on macOS, inside Contents/MacOS/ of the .app; on Linux, alongside the main binary.
  2. Run the sidecar manually from a terminal to confirm it executes and accepts the arguments your app will pass.
  3. From within your app (or a minimal test harness), invoke the sidecar using Command::new_sidecar and check for a successful exit code.
  4. If the sidecar requires specific shared libraries, verify those libraries are either bundled (via resources) or documented as system dependencies.

Missing target triple suffix prevents sidecar detection:

Tauri looks for the sidecar binary with a platform-specific suffix. If you copy only the unsuffixed binary into your project, the build may complete but the sidecar will not be bundled. Always include the correctly named file for each target you plan to support.

4

Step 4: Test Installers on Clean Environments

The installer is your users’ first interaction with the application. It must work on a machine that has never run your app before — no cached dependencies, no development tooling, no leftover registry keys. Testing on your development machine is not enough; the installer might succeed there because of libraries or permissions you already have.

For each platform you distribute, perform these checks on a fresh virtual machine or a dedicated test device:

  • Run the .msi or .exe installer as a standard user (not administrator) when possible.
  • Confirm the app installs to the expected directory (C:\Program Files\YourApp or the user-chosen location).
  • Launch the app. Check that it appears in the Start Menu, creates a desktop shortcut if configured, and opens without DLL missing errors.
  • Verify the uninstaller works: remove the app via Settings → Apps, then confirm no leftover files or registry entries remain in HKEY_CURRENT_USER\Software\YourApp or HKEY_LOCAL_MACHINE\Software\YourApp.
  • If code-signed, right-click the installer and the installed .exe, select Properties → Digital Signatures, and confirm the certificate is valid and the timestamp matches the build time.

After each platform test, document the exact environment (OS version, architecture, fresh install confirmation) so you can reproduce any issues that surface later.

All checks passed:

If the installer works on a clean machine, the app launches, and the uninstaller removes everything cleanly, the packaging pipeline is ready for publication. This is the strongest signal that you can ship the release.

What to Check When Something Fails

Failures during checklist execution usually fall into a few predictable categories. Rather than re-running the entire sequence blindly, look for these patterns:

  • App launches from the bundle folder but not after installation: The resource paths or sidecar paths are resolved relative to the executable, but the installer places them in a different directory structure. Check your resources mapping and how your code resolves paths at runtime (using app.path().resource_dir() vs. a hardcoded relative path).
  • Installer succeeds but app crashes on startup: Missing system dependencies, missing sidecar binaries, or a platform-specific permission error. Run the app from the command line on the test machine to see the error output.
  • Code signing verification fails: The certificate may be expired, the timestamp server unreachable, or the build environment missing the required signing toolchain. Re-run the build with verbose logging (--verbose) to see the exact signing command and its output.
  • Uninstaller leaves files behind: The installer configuration is not cleaning up user data directories. Tauri’s default uninstaller removes only what it installed; any files created at runtime (user preferences, databases) are intentionally left. If you need to remove those, document it for users or provide a custom uninstall script.

Iterate on the checklist itself:

Each release is an opportunity to refine this list. If a failure slipped through, add a new check to catch it next time. Over several releases, the checklist becomes a precise map of your specific application’s requirements.

Summary — The checklist verifies that the produced artifact matches what you intended to ship. It begins with a clean build, then progressively validates that every piece — resources, sidecars, installers — behaves correctly on a pristine system. The verification sequence is structured so that a failure at any step halts the release process with a clear signal rather than a cryptic user-facing error. Once all checks pass, the application is ready for the distribution stage, which involves publishing the installers to a download page or update server.