How does Sparkle sign macOS app updates with EdDSA?

Sparkle, a widely used update framework for macOS apps, uses EdDSA (ed25519) signatures to confirm that a downloaded update is intact and came from the app's author. You generate a key pair once, ship the public key inside the app, and sign each update archive with the private key.

What the signature covers

According to the Sparkle documentation, the EdDSA signature is its update integrity mechanism. The page recommends signing update archives such as dmg and zip files, binary delta updates, and installer packages. The app checks the signature against the public key it already holds before it installs anything.

This is separate from Apple code signing. Sparkle recommends Developer ID code signing and notarization alongside EdDSA, so a release normally carries two kinds of proof.

The setup steps

1. Run generate_keys from the Sparkle distribution, once. The private key is saved in your login Keychain and the tool prints the public key as a base64 string. Running it again shows the public key again.
2. Add the public key to your app's Info.plist under the key SUPublicEDKey.
3. Sign each archive you publish. The documentation describes generate_appcast, which builds the appcast from a folder of archives and generates delta files.
4. Back up the private key. The -x and -f options export and import it, for example when you move to a new Mac.

Where the private key should live

The Sparkle page gives one clear rule: keep signing keys off the machine that hosts your product. If a web server holds the key, anyone who breaks into that server can sign updates that every installed copy will accept. The Keychain on a build or release machine you control is a better home than the server that serves downloads.

What EdDSA does not tell you

A valid signature proves the archive matches what the key holder signed. It does not prove the code is free of vulnerable dependencies, and it does not prove the build machine was clean. A compromised build step can sign a bad archive with a perfectly good key. That is why signing sits beside dependency review and build controls, not in place of them.

Try it yourself

Update signing protects the delivery path, but the app still ships third party packages. Open the demo, find a component with a known advisory, and note how a signed release can still carry an issue that signing never checks.

Click through it at your own pace, or open it full screen.

Quick check

Safeguard's SBOM and dependency scanning lists the packages inside a desktop build so you can see what a signature does not cover. You can try a free scan at gold.safeguard.sh/scan.

Sources

• Sparkle documentation

Last reviewed: 19 October 2026.