What Sparkle is
Sparkle is the de facto update framework for Mac apps distributed outside the Mac App Store. When a direct-download app offers a "Check for Updates…" menu item, there is a good chance Sparkle is behind it: the framework checks a publisher-hosted feed, downloads the new release, verifies it, and replaces the installed app when the update is trusted.
Developers embed Sparkle because it solves a hard problem — shipping updates safely without a store in the middle. It also means each Sparkle app's update path is only as trustworthy as its feed and its signing keys, which is why the mechanics below are worth understanding. Sparkle is one of several channels covered in the update-sources taxonomy.
How it works: SUFeedURL and the appcast
A Sparkle-enabled app declares an SUFeedURL key in its Info.plist. That URL points at an appcast — an RSS-style XML feed the publisher hosts. On each check, Sparkle fetches the appcast, compares the newest item's version against the installed build, and offers the update if it is newer.
Each appcast item carries the essentials: the version, the download (enclosure) URL, a cryptographic signature over the archive, and the minimum macOS version the release supports. A realistic item looks like this:
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle">
<channel>
<title>ExampleApp updates</title>
<item>
<title>Version 2.4.1</title>
<pubDate>Tue, 23 Jun 2026 09:00:00 +0000</pubDate>
<sparkle:version>241</sparkle:version>
<sparkle:shortVersionString>2.4.1</sparkle:shortVersionString>
<sparkle:minimumSystemVersion>13.0</sparkle:minimumSystemVersion>
<enclosure url="https://example.com/ExampleApp-2.4.1.zip"
length="18412032"
type="application/octet-stream"
sparkle:edSignature="7cLBp2kOWr…base64…==" />
</item>
</channel>
</rss>Sparkle downloads the enclosure, verifies the sparkle:edSignature against the public key shipped inside the app, checks minimumSystemVersion against the running macOS, and only then hands the archive to its installer. If any step fails, the update never lands. The appcast is the publisher's single source of truth: it is regenerated with every release, so it always states what the newest version is and exactly where the download lives.
Sparkle 2 vs Sparkle 1
Modern apps ship Sparkle 2, and the differences from the original framework matter for safety:
- Signatures: Sparkle 2 uses EdDSA (ed25519) signatures — the sparkle:edSignature attribute in the appcast above. Sparkle 1 relied on legacy DSA signatures, which are deprecated and weaker by modern standards.
- Installation: Sparkle 2 runs the actual replacement step through a sandboxed XPC installer service, separating the privileged install from the app process. Sparkle 1 performed installation in-process.
- Sandbox support: that XPC architecture is what allows sandboxed apps to use Sparkle 2 at all.
From the outside you rarely see which major version an app embeds. But an appcast whose items carry only legacy DSA signatures — no sparkle:edSignature — is a signal the publisher has not modernized its update pipeline, and it deserves extra scrutiny.
How to tell if an app uses Sparkle
Check for the SUFeedURL key in the app's Info.plist from Terminal:
defaults read /Applications/App.app/Contents/Info.plist SUFeedURLIf the command prints a URL, the app is Sparkle-enabled and that URL is its appcast. If it errors with "does not exist," the app either does not use Sparkle or supplies its feed URL in code through a delegate instead of the plist — so a missing key is strong evidence, not proof.
You can open the appcast URL in a browser to read exactly what the publisher is advertising: version numbers, which host serves the download, and whether items carry EdDSA signatures. The same check is useful before trusting an update prompt — if the feed is served from a host that has nothing to do with the developer, treat the update with suspicion.
What signature verification protects against — and what it doesn't
EdDSA verification guarantees the downloaded archive is byte-for-byte what the publisher signed. That defeats the classic attack: a compromised or spoofed download server, or a man-in-the-middle on a hostile network, feeding you a tampered binary. Even if the enclosure URL is hijacked, an unsigned or wrongly signed archive fails verification and never installs.
It does not protect against a fully compromised publisher. If an attacker controls both the appcast feed and the private signing key, they can publish a malicious update that verifies cleanly. Signature checks also say nothing about whether an update is a downgrade, a rebranded app, or an unwanted major-version jump — catching those requires checking version direction and app identity separately.
That is why defense in depth matters: HTTPS feeds, valid signatures, signed and notarized app bundles, and a review step before install each cover a failure mode the others miss. The broader checklist lives in the safe-update pillar guide.
How macCurrent handles Sparkle apps
macCurrent recognizes appcast-driven updates as one source among several — alongside the Mac App Store, Homebrew, vendor updaters, and direct downloads. Before anything installs, it shows what a Sparkle update actually is: the source it came from, the app's identity, the signing identity, and whether the version moves forward or backward.
It does not replace Sparkle. Apps keep their own update mechanism; macCurrent's job is to surface the update, make the trust signals reviewable, and back up the current app before a direct replacement, with per-app history of scans, backups, updates, and failures. When updating through the app's own updater is the safer path, macCurrent hands off to it. What gets verified before an install is documented in the security model.
If you want that review step across every update source on your Mac — not just the Sparkle apps — install macCurrent. The beta is free through July 31, 2026, and comes as one universal app for Apple silicon and Intel Macs running macOS 15 or later.
Frequently asked questions
Are Sparkle updates safe?
Generally yes, when the feed is served over HTTPS, the EdDSA signature verifies, the app identity matches, and the version moves forward. Updates that fail any of those checks, or that arrive from an unexpected host, should be reviewed before they install.
Does macCurrent replace Sparkle?
No. Apps keep Sparkle as their own update mechanism. macCurrent finds appcast-driven updates, shows the source, signing identity, and version direction so you can judge them, and backs up the app before a direct replacement.
What is an appcast?
An appcast is an RSS-style XML feed a publisher hosts to announce app releases. Each item lists the version, the download URL, a cryptographic signature over the archive, and the minimum macOS version. Sparkle reads the feed to decide whether an update is available.
How do I find an app's Sparkle feed URL?
Run defaults read /Applications/App.app/Contents/Info.plist SUFeedURL in Terminal, substituting the app's real name. If it prints a URL, that is the appcast. Some apps supply the feed URL in code instead of the plist, so a missing key does not always mean the app skips Sparkle.
Do Mac App Store apps use Sparkle?
No. App Store apps update through the store's own mechanism, and store rules do not allow apps to replace themselves with a self-update framework. Sparkle is used by apps distributed directly by their developers outside the App Store.