SparkleValidator.com

[dweekly]

Hey Sparkle community! 👋

I built a free validator for appcast.xml feeds and wanted to share it here in case it's useful to others.

What it does:

• Checks 60+ rules covering signatures, versions, URLs, dates, and feed structure
• Catches common mistakes like invalid Ed25519 signatures, malformed dates, missing required fields, and mixed HTTP/HTTPS URLs
• Available as a CLI, npm library, or web app

Links:

• Web app: https://sparklevalidator.com
• CLI: npx sparkle-validator https://yoursite.com/appcast.xml
• npm: npm install sparkle-validator
• Homebrew: brew install dweekly/sparkle-validator/sparkle-validator
• GitHub: https://github.com/dweekly/Sparkle-Validator

Example:

$ npx sparkle-validator https://sparkle-project.org/files/sparkletestcast.xml

Valid appcast.xml
0 errors, 1 warning, 1 info

Warnings:
W035 [line 5] Feed mixes HTTP and HTTPS URLs; consider using HTTPS consistently

There's also an XSD schema if you prefer xmllint-based validation.

The tool is MIT licensed and independent from the Sparkle project. Feedback and contributions welcome!

[zorgiepoo]

That is pretty cool and like the website design. I tried it out one of my feeds.

Some comments:

Channel is missing a element

Likely legit RSS warning but I believe Sparkle only uses link from the update item.

Delta references version "1171" which does not exist in the feed

This is not a problem. A developer only strictly needs to keep the latest tip of every unique update branch (with one caveat that a later default-channel item can replace a custom-channel item that is otherwise equivalent). Other items can be cleaned up over time as developer sees fit to avoid Feed contains >50 items (performance consideration) (generate_appcast keeps a few items per update branch by default).

Item missing sparkle:version

Note sparkle:version can be specified in the enclosure or in the item, but we recommend specifying it in the item (enclosure is checked first due to compatibility). A warning could be made if it is specified in the enclosure or delta enclosure item (although I don't think NetSparkle supports sparkle:version in the item last time I checked, but many of these are specific to our version of Sparkle so).

Invalid sparkle:os value (must be "macos" or "windows")

We don't recommend using this attribute, and recommend using separate feeds instead. Its presence could be flagged as a warning.

informationalUpdate with enclosure

This is fine in Sparkle 2. There are cases where you may want the update to be conditionally informational based on which version the user is updating from (if the ability to update gets hosed for example).
edit: ok, this is a valid warning/error if there are no version conditions specified.

Items not sorted by date

I think generate_appcast sorts items by version descending rather than date, but I am not completely sure offhand. Sparkle internally sorts by version. See also point below.

Version decreases while pubDate increases

This is not an error if the update branches of the item differ. For example you may have published releases of 2.0 (beta or paid upgrade), but need to later make a backport release to 1.x.

Version missing but deducible from filename (Sparkle fallback)

This is so old and undocumented I hope nobody uses this.

1.9 will also have appcast signing, but I guess that is not that easy to validate without EdDSA key.

[dweekly]

@zorgiepoo This is wonderfully helpful feedback, all specific and actionable. I'll incorporate it into v1.2 of the validator right away. (Anything you can share about exactly what feeds had what undesired outputs - gists or URLs - can help ensure I align quickly to official expectations.)

[dweekly]

@zorgiepoo I have made a best effort to incorporate all of your feedback into the 1.2.0 release, which is now live. Can you try it out again and see if it is now better aligned with your comments and intent? I've given you credit / a hat tip in the docs.