Publishing Best Practices

Releasing a desktop application involves more than just running tauri build. You need to verify security configurations, manage version numbers correctly, sign the binaries, choose the right installer format, and ensure your users can install and update the app without friction. A well-defined release process catches problems before they reach your users and makes subsequent releases predictable. Work through the Release Checklist first.

This guide covers three interconnected areas: a pre‑release checklist that walks through each step from hardening to distribution, a version management strategy that works with Tauri's auto‑updater, and platform‑specific distribution best practices. Each section builds on the previous one, so if you are preparing your first release, start at the beginning and work through the entire document.

Release Checklist

A production release is not a single command. It is a sequence of deliberate checks that verify every layer of the application—from the security model down to the final installer. Running through these steps in order catches mistakes that are expensive to fix after users have already downloaded the software.

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-capability",
  "description": "Core capability for the main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    {
      "identifier": "fs:scope-app-recursive",
      "allow": [{ "path": "$APPDATA/*" }]
    }
  ]
}

{
  "app": {
    "security": {
      "capabilities": ["main-capability"]
    }
  }
}

{
  "app": {
    "security": {
      "csp": "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; connect-src 'self' ipc: http://ipc.localhost"
    }
  }
}

{
  "$schema": "../gen/schemas/remote-schema.json",
  "identifier": "remote-capability",
  "description": "Allow remote development sources",
  "windows": ["main"],
  "remote": {
    "urls": ["https://*.myapp.com"]
  },
  "permissions": ["core:default"]
}

{
  "version": "1.2.0"
}

[profile.release]
codegen-units = 1
lto = "fat"
opt-level = "z"
panic = "abort"
strip = true

npm run tauri build

npm run tauri build -- --no-bundle
npm run tauri bundle -- --bundles dmg

npm run tauri bundle -- --bundles app --config src-tauri/tauri.appstore.conf.json

Version Management

Every release needs a version number, but in Tauri that number is not just cosmetic. It drives the auto‑updater, appears in package metadata, and is visible in system dialogs. Getting versioning right from the start prevents update failures and confused users. See Version Management. See Version Management.

Where the Version Is Defined

Tauri v2 checks tauri.conf.json first. If a top‑level version key is present, that value is used everywhere: in the compiled binary, the installers, and the update manifest. If the key is absent, Tauri falls back to the version field in src-tauri/Cargo.toml.

The recommended approach is to set the version in tauri.conf.json and keep the Cargo version in sync manually or through your release automation. That way, the single source of truth lives in the Tauri configuration, where it is most visible.

{
  "$schema": "https://raw.githubusercontent.com/nickknapton12/tauri-v2-schema/main/schema.json",
  "productName": "MyApp",
  "version": "1.2.0",
  "identifier": "com.mycompany.myapp",
  "build": {
    "frontendDist": "../dist",
    "devUrl": "http://localhost:1420"
  }
}

Semantic Versioning and the Updater

The Tauri updater plugin expects versions that follow semantic versioning: MAJOR.MINOR.PATCH. It compares the user’s current version with the version returned by the update server. If the server reports a higher version, the updater downloads and installs it.

Stick to a predictable versioning scheme:

• MAJOR – Increment when you introduce breaking changes that require users to take action (e.g., a new minimum OS requirement).
• MINOR – Increment when you add backwards‑compatible features.
• PATCH – Increment for bug fixes and small improvements.

Pre‑release tags like 1.2.0-beta.1 are not automatically recognised by the updater. If you want to distribute beta releases through the same channel, configure the updater’s endpoints to accept pre‑release identifiers. Otherwise, stick to plain numeric versions for public releases.

Changelog Discipline

A changelog is not just a list of commits. It is a document aimed at end users who want to know whether they should update now or wait. Write a brief, clear entry for each release that highlights:

• New features and how to find them.
• Bug fixes that affect common workflows.
• Any action the user must take (e.g., “This release drops support for Windows 7”).

Keep the changelog in a CHANGELOG.md file at the repository root. Automation tools can help format entries, but a human should always write the final summary.

Distribution Best Practices

Once the application is built, signed, and versioned, you need to get it into users’ hands in a way that feels native to each platform. The right installer format, code signing workflow, and update mechanism differ significantly between Windows, macOS, and Linux. The Distribution Best Practices page collects those platform notes. Platform-specific notes are on Distribution Best Practices.

{
  "bundle": {
    "active": true,
    "targets": "all",
    "windows": {
      "wix": {
        "language": "en-US"
      },
      "nsis": {
        "installMode": "currentUser"
      }
    }
  }
}

Automate Releases with CI/CD

Manual releases do not scale. A continuous integration pipeline ensures that every tag produces identical, signed artifacts without human variation. A typical GitHub Actions workflow does the following:

• Checks out the code at the release tag.
• Installs the Tauri CLI and system dependencies.
• Runs npm run tauri build with the required signing secrets.
• Uploads the signed installers as workflow artifacts or directly to GitHub Releases.

Because signing certificates and Apple credentials are secrets, store them in the repository’s secrets store and never log them. For macOS notarisation, use an app‑specific password stored in the keychain and referenced through the APPLE_PASSWORD environment variable.

Choose an Update Strategy

The Tauri updater plugin lets you ship new versions after the initial install. It pulls a JSON file from a server endpoint that contains the new version number, release notes, and download URLs for each platform. Configure the endpoint in tauri.conf.json:

{
  "plugins": {
    "updater": {
      "endpoints": ["https://releases.myapp.com/update/{{target}}/{{current_version}}"]
    }
  }
}

The {{target}} placeholder expands to the platform triplet (e.g., windows-x86_64), and {{current_version}} is the version the user is running. Your server must respond with a JSON object that includes version, notes, and platforms containing the download URLs.

If maintaining your own update server is not feasible, services like CrabNebula Cloud handle hosting, update delivery, and analytics. They integrate directly with Tauri’s updater and remove the need to manage infrastructure.

Common Distribution Mistakes

Every successful release is a combination of security review, precise versioning, correct packaging, and thoughtful distribution. The checklist at the beginning of this guide forces you to verify each layer before a single user downloads the app. Once that discipline is in place, version management and distribution become repeatable steps in a pipeline rather than sources of last‑minute stress.