// the find
mxcl/AppUpdater
Automatically update open source macOS apps from GitHub releases. Full support for attestations.
A self-update library for Developer ID signed macOS apps: it checks GitHub Releases, validates a DMG against the installed app's signature (or optionally full SLSA/Sigstore provenance), and performs an atomic replace-and-relaunch. It's for indie/small-team Mac developers distributing outside the App Store who currently either hand-roll update logic or reach for Sparkle.
The three-phase API (check -> prepareInstallation -> installAndRelaunch) maps cleanly onto the actual trust boundaries: metadata fetch is unauthenticated and cheap, download/validation happens before anything touches the live bundle, and the install step is a backup-copy-validate-launch transaction that rolls back on any failure. Developer ID validation is thorough - it checks Team ID, signing identifier, bundle ID, nested code, sealed resources, and rejects ad-hoc/self-signed/broad custom requirements, which is more rigor than most hobby updaters bother with. The optional attestation policy is the standout feature: it verifies SLSA provenance v1 through a real Sigstore chain (Fulcio, Rekor inclusion proof, TUF-bootstrapped trust root with rotation) rather than just trusting the code signature, which closes the 'stolen signing key' hole that Developer ID checks alone can't. Download/mount resource caps (size, entry count, timeout) are a sane guard against a malicious or corrupted DMG during enumeration.
Without the attestation policy enabled (the default), there's no binding between the GitHub release and the app's actual version and no Gatekeeper/notarization check - the README is upfront that a compromised Developer ID key fully bypasses the system in that mode, so the security story really only holds if you adopt the attestation path. DMG-only releases with an exact naming convention is a real constraint if your CI already outputs zip or pkg artifacts, forcing extra packaging work just to use this. There's no built-in scheduling, background polling, or update-available UI - you're expected to build all of that yourself, unlike Sparkle which ships the whole user-facing flow. The presence of Tests/MANUAL.md and a live-attestation-smoke.sh alongside the unit tests suggests the attestation verification path - the part doing the actual cryptographic trust work - isn't fully covered by automated CI and needs manual or live runs to exercise.