macOS code signing requirement
Code signing is required on macOS to allow your application to be listed in the Apple App Store and to prevent a warning that your application is broken and cannot be started when downloaded from the browser.
building/macos code signing
35 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Apple Developer account requirements for code signing
Code signing on macOS requires an Apple Developer account, which is either paid (99$ per year) or on the free plan (only for testing and development purposes). You also need an Apple device where you perform the code signing, which is required by the signing process and Apple's Terms and Conditions.
Free Apple Developer account notarization limitation
When using a free Apple Developer account, you will not be able to notarize your application and it will still show up as not verified when opening the app.
Certificate Signing Request (CSR) creation
To create a new signing certificate, you must generate a Certificate Signing Request (CSR) file from your Mac computer. This CSR is then uploaded to your Apple Developer account on the Certificates, IDs & Profiles page.
macOS certificate types for signing
Two certificate types are available: Apple Distribution, used to submit apps to the App Store, and Developer ID Application, used to ship apps outside the App Store.
Developer ID Application certificate creator restriction
Only the Apple Developer Account Holder can create Developer ID Application certificates. However, it can be associated with a different Apple ID by creating a CSR with a different user email address.
Finding signing identity on macOS
The name of the certificate's keychain entry represents the signing identity. It can be found by executing: security find-identity -v -p codesigning
Local code signing configuration in Tauri
The signing identity can be provided in the tauri.conf.json > bundle > macOS > signingIdentity configuration option or via the APPLE_SIGNING_IDENTITY environment variable.
Invalid certificate detection
A signing certificate is only valid if associated with your Apple ID. An invalid certificate won't be listed on the Keychain Access > My Certificates tab or the security find-identity -v -p codesigning output. If the certificate does not download to the correct location, make sure the login option is selected in Keychain Access under Default Keychains when downloading the .cer file.
CI/CD certificate export process
To use a certificate in CI/CD platforms: Open Keychain Access, click the My Certificates tab in the login keychain, find the certificate entry, expand it, right-click the key item, and select Export. Select the path to save the certificate's .p12 file and define a password for the exported certificate.
Converting certificate to base64 for CI/CD
Convert the .p12 file to base64 by running: openssl base64 -A -in /path/to/certificate.p12 -out certificate-base64.txt
CI/CD environment variables for code signing
For CI/CD platforms, set APPLE_CERTIFICATE to the base64 encoded .p12 file contents and APPLE_CERTIFICATE_PASSWORD to the certificate password.
GitHub Actions code signing example configuration
Example GitHub Actions workflow for macOS code signing: name: 'build' on: push: branches: - main jobs: build-macos: needs: prepare strategy: matrix: include: - args: '--target aarch64-apple-darwin' arch: 'silicon' - args: '--target x86_64-apple-darwin' arch: 'intel' runs-on: macos-latest env: APPLE_ID: ${{ secrets.APPLE_ID }} APPLE_PASSWORD: ${{ secrets.APPLE_PASSWORD }} steps: - name: Import Apple Developer Certificate env: APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }} APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }} KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }} run: | echo $APPLE_CERTIFICATE | base64 --decode > certificate.p12 security create-keychain -p "$KEYCHAIN_PASSWORD" build.keychain security default-keychain -s build.keychain security unlock-keychain -p "$KEYCHAIN_PASSWORD" build.keychain security set-keychain-settings -t 3600 -u build.keychain security import certificate.p12 -k build.keychain -P "$APPLE_CERTIFICATE_PASSWORD" -T /usr/bin/codesign security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KEYCHAIN_PASSWORD" build.keychain security find-identity -v -p codesigning build.keychain - name: Verify Certificate run: | CERT_INFO=$(security find-identity -v -p codesigning build.keychain | grep "Apple Development") CERT_ID=$(echo "$CERT_INFO" | awk -F'"' '{print $2}') echo "CERT_ID=$CERT_ID" >> $GITHUB_ENV echo "Certificate imported." - uses: tauri-apps/tauri-action@v0 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }} APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }} APPLE_SIGNING_IDENTITY: ${{ env.CERT_ID }} with: args: ${{ matrix.args }} Required secrets: APPLE_ID, APPLE_PASSWORD, APPLE_CERTIFICATE, APPLE_CERTIFICATE_PASSWORD, KEYCHAIN_PASSWORD.
macOS notarization authentication methods
To notarize your application, you must provide credentials for Tauri to authenticate with Apple via either the App Store Connect API or your Apple ID.
App Store Connect API notarization setup
For App Store Connect API notarization: Open App Store Connect's Users and Access page, select the Integrations tab, click Add, select a name and Developer access. Set APPLE_API_ISSUER to the value above the keys table. Set APPLE_API_KEY to the Key ID column value. Download the private key (only visible once and after page reload). Set APPLE_API_KEY_PATH to the downloaded private key file path.
Apple ID notarization setup
For Apple ID notarization: Set APPLE_ID to your Apple account email. Set APPLE_PASSWORD to an app-specific password for your Apple account. Set APPLE_TEAM_ID to your Apple Team ID (found in your account's membership page).
Notarization requirement for Developer ID Application
Notarization is required when using a Developer ID Application certificate.
Skipping stapling during notarization
If you need to skip stapling for an initial notarization pass, append --skip-stapling to the Tauri command, such as: pnpm tauri build --bundles dmg --skip-stapling
Ad-hoc code signing configuration
If you do not wish to provide an Apple-authenticated identity but still wish to sign your application, you can configure an ad-hoc signature by providing the pseudo-identity '-' to Tauri in the signingIdentity configuration: "signingIdentity": "-"
Ad-hoc signing use case
Ad-hoc code signing is useful on ARM (Apple Silicon) devices, where code-signing is required for all apps from the Internet.
Ad-hoc signing Privacy & Security requirement
Ad-hoc code signing does not prevent macOS from requiring users to whitelist the installation in their Privacy & Security settings.
DMG format and purpose on macOS
The DMG (Apple Disk Image) format is a common macOS installer file that wraps an App Bundle in a user-friendly installation window. The installer window includes the app icon and the Applications folder icon, where users drag the app icon to the Applications folder to install it. It is the most common installation method for macOS applications distributed outside the App Store.
Build DMG bundle with Tauri CLI
To create a DMG for your app, run the `tauri build` command on a Mac computer with the `--bundles dmg` flag. Examples: `npm run tauri build -- --bundles dmg`, `yarn tauri build --bundles dmg`, `pnpm tauri build --bundles dmg`, `deno task tauri build --bundles dmg`, `bun tauri build --bundles dmg`, or `cargo tauri build --bundles dmg`.
DMG background image configuration
You can set a custom background image to the DMG installation window using the `tauri.conf.json > bundle > macOS > dmg > background` configuration option. The value should be a path to the image, such as `./images/`. Custom background images can include an arrow to indicate users should drag the app icon to the Applications folder.
DMG window size configuration
The default DMG window size is 660x400. You can change this using the `tauri.conf.json > bundle > macOS > dmg > windowSize` configuration option, which accepts an object with `width` and `height` properties specified in pixels.
DMG window position configuration
You can set the initial DMG installation window position using the `tauri.conf.json > bundle > macOS > dmg > windowPosition` configuration option, which accepts an object with `x` and `y` properties for pixel coordinates.
DMG app and Applications folder icon positions
You can customize the positions of the app icon and Applications folder icon in the DMG window. Use `tauri.conf.json > bundle > macOS > dmg > appPosition` to set the app icon position and `tauri.conf.json > bundle > macOS > dmg > applicationFolderPosition` to set the Applications folder icon position. Both accept objects with `x` and `y` properties for pixel coordinates.
DMG icon positions known issue on CI/CD
Icon sizes and positions are not applied when creating DMGs on CI/CD platforms due to a known issue. See tauri-apps/tauri#1731 for more information.
Info.plist configuration in src-tauri folder
To extend Info.plist configuration, create an Info.plist file in the src-tauri folder with additional key-value pairs. This file is merged with values generated by Tauri CLI. Be careful not to overwrite default values such as application version, as they may conflict with other configuration values and cause unexpected behavior.
Info.plist localization with InfoPlist.strings
To support multiple languages in Info.plist, create InfoPlist.strings files for each language in language-specific lproj directories within the Resources directory of the application bundle. Directory structure must follow the pattern <lang-code>.lproj/InfoPlist.strings, where language codes typically follow BCP 47 two-letter format. Bundle these files automatically using Tauri's resources feature by configuring tauri.conf.json with pattern like {"bundle": {"resources": {"infoplist/**": "./"}}}.
Entitlements.plist configuration location
To define entitlements required by the application, create an Entitlements.plist file in the src-tauri folder with key-value pairs. Then configure Tauri to use it by setting tauri.conf.json bundle.macOS.entitlements to the path like "./Entitlements.plist". Entitlements are applied when the application is signed.
macOS minimum system version configuration
By default, Tauri applications support macOS 10.13 and above. To enforce a newer macOS requirement, configure tauri.conf.json bundle.macOS.minimumSystemVersion to the desired version string, such as "12.0".
Including macOS frameworks in bundle
To include additional macOS frameworks, configure tauri.conf.json bundle.macOS.frameworks as an array. System frameworks can be referenced by name without the .framework extension (e.g., "CoreAudio") if they exist in $HOME/Library/Frameworks, /Library/Frameworks/, or /Network/Library/Frameworks/. Local frameworks and dylib files must be referenced with complete paths relative to the src-tauri directory (e.g., "./libs/libmsodbcsql.18.dylib", "./frameworks/MyApp.framework").
Adding custom files to macOS app bundle
Use tauri.conf.json bundle.macOS.files configuration to add custom files to the application bundle. The configuration maps destination paths to source paths relative to tauri.conf.json. Files are added to the <product-name>.app/Contents folder. Example: {"files": {"embedded.provisionprofile": "./profile-name.provisionprofile", "SharedSupport/docs.md": "./docs/index.md"}}
macOS code signing detects nested dylib, app, xpc and frameworks
In Tauri 1.6.0, the code signing process now detects nested dylib, app, xpc, and frameworks inside the macOS app bundle and codesigns each of them. This ensures that apps using external libraries can be properly codesigned and notarized.