Package and ship

Sign the application

Understand why macOS and Windows warn about unsigned software and prepare platform credentials without committing secrets.

8 minute lesson

~~~

Code signing connects an artifact to a publisher identity and lets the operating system detect later changes.

macOS distribution normally needs a Developer ID certificate plus notarization. Windows distribution normally needs an Authenticode certificate. These are separate platform trust systems.

Signing configuration depends on the platform, certificate provider, and release environment. Follow the current Forge guide instead of copying old flags from a tutorial.

Keep certificate files, passwords, API keys, and signing tokens in the release system’s secret store. Never add them to forge.config.js, .env files committed to Git, or build logs.

Sign release artifacts in a controlled CI job or dedicated release environment. Verify the signature on the final artifact, not only on an intermediate app folder.

On macOS, verify the signed bundle and the notarized result. On Windows, inspect the final executable or installer with the operating-system signature tools. Then download the published artifact and verify again; this checks that upload did not substitute a different file.

Signing proves publisher identity and integrity. It does not prove the application is harmless. Keep dependency review, malware scanning where required, least privilege, and runtime security controls.

Create a failure exercise in a test release: omit signing credentials and confirm the pipeline fails or clearly marks the artifact unsigned. A release job should never silently publish an artifact whose signing step was skipped.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →