sparkle-mac
Sparkle macOS Auto-Update Framework (v2.x)
You are an expert at integrating the Sparkle framework for macOS application auto-updates. This skill references the Sparkle 2.x official documentation.
Core Principles
- Security first — Always use HTTPS for appcast feeds. Sign updates with EdDSA (ed25519). Notarize and code-sign apps via Apple Developer ID. Never store signing keys on the update server.
- Minimal API surface —
SPUStandardUpdaterControllerhandles most use cases. Only drop toSPUUpdaterdirectly when you need custom UI or non-app-bundle updates. - Info.plist for defaults — Set initial configuration (
SUFeedURL,SUPublicEDKey, check intervals) in Info.plist. Only use runtime APIs when responding to user setting changes. - Appcast-driven — Updates are described via RSS-based appcast XML. Use
generate_appcastto automate appcast creation, delta generation, and signing. - Sandbox-aware — Sandboxed apps require XPC Services (Installer, optionally Downloader) and specific entitlements. Non-sandboxed apps can optionally strip XPC Services to save space.
How to Use This Skill
Before generating code, load the relevant reference file(s):
references/setup-and-integration.md— Adding Sparkle via SPM/Carthage/CocoaPods/manual, creating updater objects (Cocoa, SwiftUI, Qt, Catalyst), core APIsreferences/customization.md— All Info.plist settings (general, security, sandboxing), App Transport Security, system profiling (server-side backends), runtime API expectationsreferences/publishing.md— Archiving apps, signing updates, appcast XML format, delta updates, channels, versioning, release notes (HTML/markdown/plain text/localized/adaptive), phased rollouts, critical/major/informational updates, extending appcast with custom XML
More from zackbart/skills
optimize-prompt
>
10kysely
>
7second-opinion
>
5update-docs
>
5design-system-patterns
>
5ethos
Conduct a structured interview and write a project's ethos.md — the doc that captures vision, principles, personas, non-goals, scope, and constraints. Use this skill whenever the user mentions ethos, vision doc, project principles, project philosophy, guiding principles, non-goals, scope boundaries, target user persona, anti-personas, project charter, "the why behind the project," or wants to prevent feature creep / drift / contributors making wrong assumptions. Also use when the user wants to define what a product is NOT, document who it's for, lock in what makes it special, or onboard contributors with strategic context — even without the word "ethos." Do not write a vision/principles/non-goals doc directly with Write; invoke this skill so the interview runs first.
4