[Feature] Auto Updates

[Zonharo]

I'd like to see automatic updates in the next version as soon as a new version is released on GitHub

[momenbasel]

Update: Stage 1 of in-app updates is in flight via #99 (Sparkle SPM integration, opt-in, with a Releases-page fallback when no appcast feed is configured). Once that's rebased onto current main I'll land it, which gives you a 'Check for Updates' menu item that at least opens the GitHub Releases page directly.

Stage 2 — the actual signed-appcast / EdDSA-key / release-workflow integration that makes 'auto-update on new release' real — needs its own design pass and a follow-up PR. I'll track it in a separate issue once Stage 1 lands so it doesn't get conflated with this feature request.

Keeping this open until Stage 2 ships.

[momenbasel]

Status for v2.4.0:

• Permission UX overhaul — the bare "Open System Settings" alert that fired on a failed cleanup is gone. v2.4.0 ships a rich sheet that opens Settings and reveals PureMac.app in Finder side-by-side, polls FDA state once per second, and auto-retries the failed batch the moment you toggle PureMac on — no need to re-select anything.
• Broader TCC registration probes — PureMac now touches Mail, Safari, Messages, AddressBook, Calendars, Containers and MobileSync at launch so macOS catalogs more TCC services against the bundle. That fixes the long-standing "PureMac doesn't appear in the FDA list" complaint on fresh Homebrew installs.
• Sidebar Quick Setup — when FDA is missing the sidebar footer shows a pulsing dot + 1-tap fix button so the prompt is always one click away.

Stage 2 (signed appcast + EdDSA + release-workflow integration) is still tracked in #104 — keeping this open until that lands so the original "auto-update on new release" ask is genuinely fulfilled.

[momenbasel]

Status update (v2.7.0): the user-facing groundwork is in place and the Stage-1 fallback ("Check for Updates" → GitHub Releases) still works, but signed auto-update is intentionally not enabled yet — shipping an untested signed-appcast pipeline into a production updater is the kind of thing that silently breaks updates for everyone if the signature/host/re-sign chain is even slightly off.

What's left for Stage 2 (tracked, next):

1. Generate the EdDSA keypair (generate_keys), store the private key as a repo secret, add SUPublicEDKey to Info.plist.
2. Host a stable appcast.xml (gh-pages) and generate+sign_update it in release.yml.
3. Re-sign Sparkle's nested XPC bundles with Developer ID + hardened runtime and re-notarize.
4. Only then set SUFeedURL, after a tamper test confirms a modified DMG is rejected.

PR #108 is a good conservative start (opt-in UI + appcast generation); I've left review notes there. Keeping this open until the signed feed is live and verified.