Signing the archives is the baseline, and signing the appcast feed is an extra layer worth considering. Sparkle can require that the feed and release notes are signed too, using the SURequireSignedFeed setting, so someone who edits the feed cannot quietly change what users see or are pointed to.
Archive signature versus feed signature
The archive signature answers one question: is this file the one the key holder signed? The appcast is a different object. It is the list that tells the app which version is newest, where to download it, and what the release notes say.
Per the Sparkle documentation, generate_appcast signs the appcast and release notes only when the app opts into SURequireSignedFeed. Without that opt in, an attacker who can edit the feed cannot forge an archive signature, but can still mislead the app in other ways, such as withholding news of a newer release.
What you need to turn it on
The documentation lists these pieces:
SURequireSignedFeedsigns the feed and release notes.SUVerifyUpdateBeforeExtractionmust also be enabled.- The page says signed feeds are validated as of Sparkle 2.9.
- If you edit a signed appcast or its release notes by hand, you must regenerate the signatures.
That last point is an operational detail that bites teams. A hotfix to release notes in a text editor will break verification until the signatures are rebuilt.
The fallback window
SUSignedFeedFailureExpirationInterval sets a fallback period. When it expires, Sparkle strips some information, such as release notes and links. Think of it as a graceful degradation setting for apps that already shipped before the feed was signed. Choose the interval deliberately and write down why.
A short decision guide
| Situation | Suggested step |
|---|---|
| New app, no installed base | Turn on signed feed from the first release |
| Existing app, mixed Sparkle versions | Check each shipped version supports it before requiring it |
| Hand edited appcast in your process | Move to generated feeds first, then enable signing |
| Feed hosted on shared storage | Treat signed feed as more important, since many people can write there |
Try it yourself
A signed feed is a policy that has to hold on every release. The gate demo shows how a rule can block a change before it ships. Click through it and think about which of your release steps could carry a similar check.
Click through it at your own pace, or open it full screen.
Quick check
Does a signed feed replace archive signing?
No. The documentation treats EdDSA signing of archives as the main integrity mechanism and the signed feed as an optional addition.
Is HTTPS required for Sparkle feeds?
The documentation recommends serving updates over HTTPS and following Apple's App Transport Security requirements. It does not state HTTPS as a strict requirement, but there is little reason to skip it.
Safeguard's policies and gates can check a build before release, and its SBOM and dependency scanning shows what a desktop app ships. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
