Skip to content

Conversation

@pierrekin
Copy link

@pierrekin pierrekin commented Dec 5, 2025

Summary

Adds support for creating macOS PKG installers with both native and custom signing capabilities. This enables distribution
of Tauri applications via PKG installers and supports HSM-based signing workflows.

Features

PKG Installer Support

  • Creates macOS PKG installers using pkgbuild and productbuild
  • Requires distribution.xml in project root for PKG customization
  • Native signing support via productsign using signingIdentity or APPLE_CERTIFICATE environment variable
  • Respects --no-sign flag

Custom Signing Commands

Adds support for custom signing commands to integrate external signing tools (e.g., HSM-based solutions):

  • appSignCommand: Custom command for signing .app bundles
  • pkgSignCommand: Custom command for signing .pkg installers
  • dmgSignCommand: Custom command for signing .dmg disk images

Custom commands are checked before native signing and use %1 placeholder for the artifact path. Commands run in the
directory where tauri build was executed, allowing relative paths.

Configuration Example

{
  "bundle": {
    "macOS": {
      "appSignCommand": {
        "cmd": "./shims/sign_app.sh",
        "args": ["%1"]
      },
      "pkgSignCommand": {
        "cmd": "./shims/sign_pkg.sh",
        "args": ["%1"]
      },
      "dmgSignCommand": {
        "cmd": "./shims/sign_dmg.sh",
        "args": ["%1"]
      }
    }
  }
}

Test Plan

  • Create PKG installer without signing
  • Create PKG installer with native signing (productsign)
  • Test custom signing commands for .app, .pkg, and .dmg
  • Verify relative paths work in custom signing commands
  • Verify --no-sign flag is respected
  • Test with distribution.xml customization

Modified Crates

  • tauri-bundler: PKG bundler implementation and custom signing logic
  • tauri-utils: Configuration schema for custom signing commands
  • tauri-cli: Schema updates for new configuration fields

Implements support for creating macOS PKG installers using pkgbuild and
  productbuild. Creates component packages from .app bundles and combines
  them into distribution packages using a user-provided distribution.xml
  file from the project root.

  Changes:
  - Add PackageType::Pkg enum variant and register it for macOS
  - Create bundle/macos/pkg module implementing two-level PKG structure
  - Wire PKG bundler into main bundle dispatcher
  - Require distribution.xml in project root for PKG customization
Implements PKG installer signing using productsign. Signs the final
  distribution package with the identity specified in macos.signingIdentity
  configuration or APPLE_CERTIFICATE environment variable.

  Changes:
  - Add sign_pkg() function to macos/sign.rs using productsign
  - Call sign_pkg() after productbuild in PKG bundler
  - Respects --no-sign flag and signing identity configuration
  Adds support for custom signing commands to allow users to integrate
  external signing tools (like HSM-based solutions) for .app bundles,
  .pkg installers, and .dmg disk images.

  Custom commands are checked before native signing, allowing users to
  completely override the signing process. The %1 placeholder is replaced
  with the path to the file being signed.

  Configuration fields added to MacOsSettings:
  - app_sign_command: Custom command for signing .app bundles
  - pkg_sign_command: Custom command for signing .pkg installers
  - dmg_sign_command: Custom command for signing .dmg disk images

  Changes:
  - Add custom sign command fields to MacOsSettings
  - Implement sign_app_custom, sign_pkg_custom, sign_dmg_custom functions
  - Update app.rs, pkg/mod.rs, and dmg/mod.rs to check for custom commands
  - Reuse Windows-style %1 placeholder substitution pattern
Enables developers to specify custom signing commands for .app bundles,
.pkg installers, and .dmg disk images on macOS. This is useful for
organizations that need to use proprietary signing infrastructure
instead of the native codesign/productsign tools.

Configuration example in tauri.conf.json:
```
  {
    "bundle": {
      "macOS": {
        "appSignCommand": {
          "cmd": "./shims/sign_app.sh",
          "args": ["%1"]
        },
        "pkgSignCommand": {
          "cmd": "./shims/sign_pkg.sh",
          "args": ["%1"]
        }
      }
    }
  }
```

The %1 placeholder in args is replaced with the path to the artifact
being signed.
Run custom commands in the same directory as the tauri build
command was run, allowing developers to use relative paths
as expected.
@github-project-automation github-project-automation bot moved this to 📬Proposal in Roadmap Dec 5, 2025
@pierrekin pierrekin changed the title feat(bundler): add macOS PKG installer support with custom signing feat(bundler): add macos pkg installer support with custom signing Dec 5, 2025
Copy link
Member

@FabianLars FabianLars left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adds support for custom signing commands to integrate external signing tools (e.g., HSM-based solutions):

Are there HSM based solutions for macOS? i know of tools like https://github.com/indygreg/apple-platform-rs (which i'd love to integrate into tauri at some point) but didn't hear about hsm ones yet (or many local solutions either).

For the signCommand config, if we keep it, i think it would make more sense to match the Windows behavior and have a single config and leave it to the scripts to handle the file type check if needed.
Also, for the future it would make reviews much easier to have the pkg impl and the custom signing feature in 2 separate PRs :)

Lastly, we also need to check how to make the updater work with this, eg do we still use the .app bundle to update?

}

package_types.sort_by_key(|a| a.priority());
log::info!("Sorted package types: {:?}", package_types);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i won't annotate every line but logs like this one are honestly a bit too verbose, at least for the info level, perhaps tracing or debug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 📬Proposal

Development

Successfully merging this pull request may close these issues.

2 participants