Publishing an update
So you’re ready to release a new version of your app. How do you go about doing that?
Archive your app
Put a copy of your .app (with the same name as the version it’s replacing) in a .zip, .tar.gz, or .tar.bz2. If you distribute your .app in a .dmg, do not zip up the .dmg.
Make sure symlinks are preserved when you create the archive. macOS frameworks use symlinks, and their code signature will be broken if your archival tool follows symlinks instead of archiving them. For creating zip archives, can be used (behaves the same as Finder’s Compress option):
If you can’t use regular app bundles, you can also create an Installer .pkg with the same name as your app and put that .pkg in one of the aforementioned archive formats. By default Sparkle launches Installer without a GUI. If instead of .pkg extension you use .sparkle_interactive.pkg, then installation will run with a GUI and ask user to confirm every step.
Secure your update
In order to prevent corruption and man-in-the-middle attacks against your users, you must cryptographically sign your updates.
Signatures are automatically generated when you make an appcast using tool. This is a recommended method.
To manually generate signatures for your updates, Sparkle includes a tool to help you make a EdDSA signature of the archive. From the Sparkle distribution:
The output will be an XML fragment with your update’s EdDSA signature and (optional) file size; you’ll add this attribute to your enclosure in the next step.
Since 10.11, macOS has App Transport Security policy which blocks apps from using insecure HTTP connections. This restriction applies to Sparkle as well, so you will need to serve your appcast and the update files over HTTPS.
Update your appcast
You need to create an for your update in your appcast. See the sample appcast for an example. Here’s a template you might use:
Test your update, and you’re done!
Downloading from a web site
If you want to provide a download link, instead of having Sparkle download and install the update itself, you can omit the tag and add and tags. For example:
If your app is large, or if you’re updating primarily only a small part of it, you may find delta updates useful: they allow your users to only download the bits that have changed.
Internal build numbers
If you use internal build numbers for your key (like an SVN revision number) and a human-readable , you can make Sparkle hide the internal version from your users.
Set the attribute on your enclosure to the internal, machine-readable version (ie: “1248”). Then set a attribute on the enclosure to the human-readable version (ie: “12.X Sea Lion”).
Remember that the internal version number ( and ) is intended to be machine-readable and is not generally suitable for formatted text.
Minimum system version requirements
If an update to your application raises the required version of macOS, you can only offer that update to qualified users.
Add a child to the in question specifying the required system version, such as “10.8.4”:
Note that Sparkle only works with macOS 10.7 or later, so that’s the minimum version you can use.
Embedded release notes
Instead of linking external release notes using the element, you can also embed the release notes directly in the appcast item, inside a element. If you wrap it in , you can use unescaped HTML.
You can embed just marked up text (it’ll be displayed using standard system font), or a full document with , etc.
You can provide additional release notes for localization purposes. For instance:
Use the attribute with the appropriate two-letter country code for each localization. You can also use this attribute with the tag.
Alternate download locations for other operating systems
Sparkle is available for Windows.
To keep the appcast file compatible with the standard Sparkle implementation, a new tag has to be used for cross platform support. It is suggested to use the following to specify downloads for non macOS systems:
Replace os_name with either “windows” or “linux”, respectively (mind the lower case!). Feel free to add other OS names as needed.
There’s an old description of how to automate the archiving and signing process with a script build phase in Xcode. Find other guides.