Do you have an app that uses appcast / Sparkle technology? Did you ever wonder if there was a better way to make & serve the appcast? This idea could save thousands of developers thousands of hours of time.
This is an idea - what I want to know is “would you use this?”.
Provide feedback and join the discussion on the project page in GitHUb .
Background
I recently released an app on Windows - and I wanted my users to have a way to be notified that there was a new version of the app and make installation a breeze.
Nothing new here - this has existed for years in the world of Mac apps, it’s called Sparkle , and on Windows I’ve used NetSparkleUpdater .
The Problem
The problem is not appcasts, they are an excellent way to encourage customers to update to the latest version - appcast libraries make this trivial to achieve for the customer.
The problem is the effort involved in getting it done. Let me try to elaborate.
To make use of Sparkle - developers need to build the relevant client library into their code, and for each release they must:
- Have some storage space somewhere to publish assets to
- Publish (at least) both a binary asset and usually also a change log
- Re-generate the appcast.xml feed - this likely requires an appcast signing key
- Store the resulting binaries + change logs and appcast files on a web server / storage account.
- Make the “latest” version available on their website
- [Optional] List archived versions on their website
Depending on the library used; generation of the appcast might require the existing application assets to be available on disk. This isn’t always the case, but if it is then this can make the build pipelines not only less efficient - but you run the risk of turning your dev machine into a “build box”, because you just happened to have all the binaries there.
Then there is the process of setting up the app cast generation process itself - none of which is particularly difficult, there are lots of flavours I suppose they mostly go something like this:
- Installation of the appcast generator on a machine (or in the build pipeline)
- Generation of signing keys - along with the responsibility to keep these safe
- Integration of the appcast generation process into your build process/pipeline
- Start thinking about having a beta channel, and not just stable… oh crap
So what’s my problem?
I’m lazy - there is a lot I don’t like about this process so far:
- Most of this, if not all of it, is just technical infrastructure that developers need to repeat for each piece of software they ship.
- While the cusomters get “value” in the form of automated updates - its a complex set of tasks, there are lots of moving pieces to get it right: storage, tool installs, generation, channels and security.
- It’s boring, error prone work and could become a security hole - you are after all injecting code into your customers computer. Should anyone be able to generate and ship an appcast? Are those signing keys protected?
- Now you have to deal with hosting the appcast - and nothing I’ve read at the Sparkle site, nor on the NetSparkleUpdater site suggests this is “standard” in any way - great - lets reinvent this again .
The Vision / Proposal
So I’m asking myself - isn’t this a ripe opportunity to make something better?
What if it was possible to automatically create a production ready, secure appcast generation system in seconds?
What if this system made it childs play to expose different release channels, add releases to a channel, move a release to a different channel, and can automatically archive older versions of your published software?
If that system also provided a way to query for information via REST or GraphQL, then it would also be relatively simple to get a product web page populated with the latest build information - even with static site generators.
Introducing: Necklace
Necklace is an open source project that provides developers with a ready to run appcast generation system.
Necklace stores appcast meta data, handles separate channels for you, takes care of the generation as well as secure storage of your signing keys - and generates Sparkle/NetSparkleUpdater compatible appcast.xml files on-the-fly.
There is no need to install app cast generator tools, copy/move/sync binaries or change logs or publish the resulting app cast.
What’s it made of?
Docker. I’d like to make an Azure Functions version too - zero infra maintenace is a good thing, and since it wouldn’t be called that often it would cost just cents.
Pull the image, configure it - expose it on a public HTTPS URL and you are ready to publish releases.
How do I use it?
Assuming you have a website hosted on a linux machine somewhere - to get up and running with Necklace, you would:
- Install the Docker based version of Necklace, you will want to bind mount a single directory to your local host in order to back up its configuration and database. This is also where the signing keys will be exposed/set.
- Set up the private appcast signing key configuration - the keys are automatically generated if they don’t exist within the directory that has been mapped. You can simply overwrite them to use your own keys.
- Add your ChangeLog rendering template (a future feature)
- Add configuration for the base hostname of the appcast binaries / packages.
Then, when you have a new build to release to your customers (lets say it consists of a .pkg file and an .md change log file); you would then:
- Store the .pkg / .md file somewhere accessible to Necklace - this could be GitHub, Azure Storage, AWS S3 and so on - you are probably already doing this
- Make a REST call into Necklace to add the app version
- There is no 3, you are DONE.
The new app version is now available to all your customers (on whatever channel you placed it). If you re-publish the same version number in a different channel, the appcast system automatically reflects this.
Where do I get it?
It doesn’t exist yet - its just an idea, what I want to know is: is it attractive, shall I build this thing?
Provide feedback and join the discussion on the project page in GitHub .