{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-05-code-signing-and-notarization-sparkle-and-tears/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "![](https://steipete.me/assets/img/2025/code-signing-and-notarization-sparkle-and-tears/header.png)\n\n*Or: How I Learned to Stop Worrying and Love the XPC Services*\n\nIf you’ve ever tried to implement automatic updates in a sandboxed macOS app using Sparkle, you know it can feel like trying to solve a Rubik’s cube while wearing oven mitts. After creating way too many beta releases and spending countless hours debugging cryptic authorization errors, I finally cracked the code. Here’s my step-by-step guide to code signing, notarization, and Sparkle auto-updates in sandboxed macOS apps.\n\n## The Setup: Vibe Meter Meets Sparkle\n\n[Vibe Meter](https://vibemeter.ai) is a sandboxed macOS menu bar app that tracks AI service spending. When I decided to add automatic updates using Sparkle 2.x, I thought it would be straightforward. After all, Sparkle is the de facto standard for macOS app updates, right?\n\nOh, sweet summer child.\n\n## Act 1: The Mysterious Authorization Failure\n\nI’d already mastered code signing and notarization (its own nightmare), so I just told Claude: “Look at this repository and do what we did there.” It nailed the signing and notarization process.\n\nMy first attempts seemed promising. The app built, signed, and notarized successfully. But when users tried to update, they were greeted with:\n\n```plaintext\nError: Failed to gain authorization required to update target\n```\n\nThis error is Sparkle’s polite way of saying “I can’t talk to my XPC services, and I have no idea why.”\n\n## Act 2: The Entitlements Enigma\n\nAfter digging through [Sparkle’s documentation](https://sparkle-project.org/documentation/sandboxing/) and Console logs, I discovered my first issue: missing mach-lookup entitlements. In a sandboxed app, Sparkle uses XPC services to perform privileged operations, and these services need special permissions to communicate.\n\n### The Missing Piece\n\nMy entitlements file was missing a critical entry:\n\n```xml\ncom.apple.security.temporary-exception.mach-lookup.global-name\n\n com.steipete.vibemeter-spks\n com.steipete.vibemeter-spki\n\n```\n\nBut here’s the kicker - I initially only added `-spks`, thinking it stood for “Sparkle Server.” Turns out, you need BOTH:\n\n- `-spks`: Sparkle Server (for the InstallerLauncher.xpc service)\n- `-spki`: Sparkle Installer (for the Installer.xpc service)\n\nMissing either one results in the dreaded authorization error.\n\n## Act 3: The Code Signing Circus\n\nNext came the code signing adventures. My notarization script was doing what seemed logical:\n\n```bash\ncodesign --deep --force --sign \"Developer ID\" VibeMeter.app\n```\n\nBut Sparkle’s documentation specifically warns against using `--deep`. Why? Because it can mess up the XPC services’ signatures. Instead, you need to sign components in a specific order.\n\nHere’s the correct approach from my [codesign script](https://github.com/steipete/VibeMeter/blob/main/scripts/codesign-app.sh):\n\n```bash\n# Sign XPC services first\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/Installer.xpc\"\n\n# Preserve entitlements for Downloader.xpc (Sparkle 2.6+)\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime --preserve-metadata=entitlements \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/Downloader.xpc\"\n\n# Sign other Sparkle components\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/Autoupdate\"\n\n# Then sign the framework\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework\"\n\n# Finally, sign the app WITHOUT --deep\ncodesign --force --sign \"$SIGN_IDENTITY\" --entitlements VibeMeter.entitlements \\\n --options runtime VibeMeter.app\n```\n\n## Act 4: The Bundle ID Bamboozle\n\nAt one point, I thought I was being clever (or rather, [Claude Code](https://steipete.me/posts/claude-code-is-my-computer/) thought…) by trying to manually modify the XPC services’ bundle identifiers. Big mistake.\n\nFor sandboxed apps, Sparkle requires specific bundle ID suffixes:\n\n- Use `-spks` suffix for the InstallerLauncher service\n- Use `-spki` suffix for the Installer service\n\nThe framework expects these exact suffixes. Use anything else, and you’ll get cryptic XPC connection errors that will make you question your career choices.\n\n## Act 5: The Build Number Blues\n\nEven after fixing all the sandboxing issues, I hit another snag. Users were seeing “You’re up to date!” when updates were clearly available. The culprit? My appcast[^1] generation script was defaulting build numbers to “1”.\n\nSparkle uses build numbers (CFBundleVersion), not version strings, to determine if an update is available. If your build numbers don’t increment, Sparkle thinks there’s nothing new.\n\nMy [appcast generation script](https://github.com/steipete/VibeMeter/blob/main/scripts/generate-appcast.sh) now properly handles this:\n\n```bash\n# Extract build number from Info.plist\nBUILD_NUMBER=$(plutil -extract CFBundleVersion raw \"$INFO_PLIST\")\n\n# Ensure build numbers increment correctly\nif [[ \"$BUILD_NUMBER\" -le \"$PREVIOUS_BUILD_NUMBER\" ]]; then\n echo \"Error: Build number must be greater than previous release\"\n exit 1\nfi\n```\n\n## The Grand Finale: It Works!\n\n![Sparkle update dialog working perfectly](https://steipete.me/assets/img/2025/code-signing-and-notarization-sparkle-and-tears/sparkle.png)\n\nAfter two days of intense debugging, I finally had a working setup. My complete automation pipeline is now rock-solid, with [comprehensive scripts](https://github.com/steipete/VibeMeter/tree/main/scripts) that handle every aspect of the process.\n\n### The Magic Recipe\n\n1. **Entitlements**: Include BOTH `-spks` and `-spki` mach-lookup exceptions\n2. **Bundle IDs**: Never change Sparkle’s XPC service bundle IDs\n3. **Code Signing**: Sign XPC services individually, never use `--deep`\n4. **Build Numbers**: Always increment them, and verify your appcast\n5. **Info.plist**: Set `SUEnableInstallerLauncherService = true` and `SUEnableDownloaderService = false`[^2]\n\n### The Working Configuration\n\nThe XPC services themselves keep their original Sparkle bundle IDs (`org.sparkle-project.InstallerLauncher` and `org.sparkle-project.Downloader`). What we configure in the entitlements are the mach-lookup communication channels:\n\n```xml\n\ncom.apple.security.app-sandbox\n\ncom.apple.security.network.client\n\ncom.apple.security.temporary-exception.mach-lookup.global-name\n\n com.steipete.vibemeter-spks\n com.steipete.vibemeter-spki\n\n```\n\n## The Scripts That Saved My Sanity\n\nMy complete build pipeline consists of several specialized scripts:\n\n- **[preflight-check.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/preflight-check.sh)**: Validates environment and prerequisites\n- **[codesign-app.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/codesign-app.sh)**: Handles the complex code signing process\n- **[notarize-app.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/notarize-app.sh)**: Manages notarization and stapling\n- **[create-dmg.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/create-dmg.sh)**: Creates and signs distribution DMGs\n- **[generate-appcast.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/generate-appcast.sh)**: Generates Sparkle appcast files\n- **[release.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/release.sh)**: Orchestrates the entire release process\n\nLook at this beauty! Now even Claude can do releases without messing up 🎉 I just tell it “Create a new beta release, see release.md” and it handles everything.\n\n```bash\n# Now create the release\n./scripts/release.sh stable # For stable 1.1.0\n# OR\n./scripts/release.sh beta 1 # For 1.1.0-beta.1\n\n# Use the version script to bump versions\n./scripts/version.sh --minor # 1.0.0 -> 1.1.0\n./scripts/version.sh --major # 1.0.0 -> 2.0.0\n./scripts/version.sh --set 1.1.0 # Set specific version\n```\n\nEverything happens automatically - from building to GitHub release creation. These scripts are tuned for [Tuist](https://tuist.dev/) and can easily be adapted for simpler setups.\n\n## The Notarization Nightmare\n\nApple’s notarization process adds another layer of complexity. Notarization verifies your app is safe - you upload it to Apple’s servers for scanning, and if approved, they “staple” a ticket to your app. The process typically takes a few minutes in Apple’s notarization queue (officially called the “processing queue”). The [notarization script](https://github.com/steipete/VibeMeter/blob/main/scripts/notarize-app.sh) uses the modern [`notarytool`](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution) approach:\n\n```bash\n# Create ZIP for notarization (not DMG!)\nditto -c -k --keepParent \"$APP_BUNDLE\" \"$ZIP_PATH\"\n\n# Submit for notarization\nxcrun notarytool submit \"$ZIP_PATH\" \\\n --key \"$API_KEY_PATH\" \\\n --key-id \"$API_KEY_ID\" \\\n --issuer \"$ISSUER_ID\" \\\n --wait\n\n# Staple the ticket\nxcrun stapler staple \"$APP_BUNDLE\"\n\n# Verify everything worked\nspctl -a -t exec -vv \"$APP_BUNDLE\"\nxcrun stapler validate \"$APP_BUNDLE\"\n```\n\nOf course this needs [certificates from Apple](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution). Luckily Claude is smart enough to guide you through the whole process of downloading those files and adding them to the keychain and your environment.\n\n## Pretty Changelogs in Sparkle\n\nOne challenge I hadn’t anticipated was making the update dialogs actually useful. Sparkle can display rich HTML changelogs, but getting from my Markdown changelog to properly formatted HTML required some creativity.\n\nThe [changelog-to-html.sh script](https://github.com/steipete/VibeMeter/blob/main/scripts/changelog-to-html.sh) extracts version-specific sections from `CHANGELOG.md` and converts them to HTML with what I call the “Poor Man’s Markdown Parser”:\n\n```bash\n# Extract version section and convert Markdown to HTML\nawk \"/^## \\\\[$version\\\\]/{flag=1;next}/^## \\\\[/{flag=0}flag\" CHANGELOG.md | \\\nsed 's/^### \\(.*\\)/

\\1<\\/h3>/' | \\\nsed 's/^- \\(.*\\)/
  • \\1<\\/li>/' | \\\nsed 's/\\*\\*\\([^*]*\\)\\*\\*/\\1<\\/strong>/g'\n```\n\nThe result? Users see properly formatted changelogs with headers, lists, and styled text instead of raw Markdown. Note: This parser has limitations - it doesn’t handle nested lists, images, or links. Keep your changelogs simple or extend the parser for more complex formatting.\n\n## The Complete Architecture\n\nWhat emerged is a surprisingly elegant zero-infrastructure solution that leverages GitHub’s existing services:\n\n### GitHub-Centric Distribution\n\n- **Releases**: [GitHub releases](https://github.com/steipete/VibeMeter/releases) host the actual DMG files\n- **Appcast Hosting**: [Raw GitHub URLs](https://raw.githubusercontent.com/steipete/VibeMeter/main/appcast.xml) serve the XML feeds\n- **Dual Feeds**: Separate appcasts for [stable](https://github.com/steipete/VibeMeter/blob/main/appcast.xml) and [pre-release](https://github.com/steipete/VibeMeter/blob/main/appcast-prerelease.xml) channels\n- **Version Control**: Appcast files are versioned alongside the code\n\n### Dynamic Channel Switching\n\nThe app includes runtime logic to switch between update channels without reinstallation. Users can choose “stable” for production releases or “pre-release” for beta access, and the app dynamically points to the appropriate appcast URL.\n\n![Vibe Meter settings showing update channel options](https://steipete.me/assets/img/2025/code-signing-and-notarization-sparkle-and-tears/vibemeter-settings.png)\n\n### Automated Everything\n\nThe [release.sh script](https://github.com/steipete/VibeMeter/blob/main/scripts/release.sh) orchestrates the entire pipeline:\n\n1. Build and sign the app\n2. Create GitHub release with DMG\n3. Generate both appcast files with proper signatures\n4. Commit and push everything\n\nNo separate hosting, no Jekyll setup, no additional infrastructure - just GitHub doing what it does best. The key is that [`release.sh`](https://github.com/steipete/VibeMeter/blob/main/scripts/release.sh) is the master orchestrator that calls most other scripts in sequence for a complete automated release.\n\nView the complete script flow architecture\n\n```plaintext\n🚀 Main Release Flow (release.sh)\n\nrelease.sh\n├── 1. preflight-check.sh ────────────── Validates everything ready\n├── 2. generate-xcproj.sh ────────────── Generates Xcode project\n├── 3. build.sh ──────────────────────── Builds app with IS_PRERELEASE_BUILD flag\n├── 4. sign-and-notarize.sh ──────────── Signs & notarizes app\n│ ├── codesign-app.sh ─────────────── Code signs app bundle\n│ └── notarize-app.sh ─────────────── Notarizes signed app\n├── 5. create-dmg.sh ─────────────────── Creates & signs DMG\n├── 6. GitHub CLI (gh) ───────────────── Creates GitHub release\n├── 7. generate-appcast.sh ───────────── Updates appcast XML files\n└── 8. verify-appcast.sh ─────────────── Validates appcast (optional)\n\n✅ Verification Flow\n\npreflight-check.sh ───────────────────── Pre-release validation\n└── verify-prerelease-system.sh ──────── IS_PRERELEASE_BUILD system check\n\nverify-app.sh ────────────────────────── Post-build verification\nverify-appcast.sh ────────────────────── Appcast validation\n\n🔐 Manual Signing Flow\n\nsign-and-notarize.sh\n├── codesign-app.sh ──────────────────── Code sign app\n├── notarize-app.sh ──────────────────── Notarize app\n└── create-dmg.sh ────────────────────── Create distribution DMG\n\n🛠️ Utility Scripts (Called by others)\n\n- changelog-to-html.sh ← Called by update-appcast.sh\n- version.sh ← Standalone version management\n```\n\n## Lessons Learned\n\n1. **Read the documentation carefully** - But also know that it might not cover every edge case\n2. **Console.app is your friend** - Filter by your process name and watch for XPC errors\n3. **Don’t be clever** - Follow Sparkle’s conventions exactly\n4. **Test updates, not just builds** - A successful build doesn’t mean updates will work\n5. **Automate everything** - Manual processes lead to human errors\n6. **Version control your scripts** - Build automation is as important as your app code\n\n## Final Thoughts\n\nImplementing Sparkle in a sandboxed app is like solving a puzzle where the pieces keep changing shape. But once you understand the rules - respect the XPC services, get your entitlements right, and sign everything properly - it works beautifully.\n\nThe irony? The final solution is actually quite simple. It’s getting there that’s the adventure. I don’t know how anyone manages to ship working macOS apps at all, honestly.\n\nNow go download [Vibe Meter](https://vibemeter.ai) and read my dev diary on how I built it with Claude Code: [Vibe Meter: Monitor Your AI Costs](https://steipete.me/posts/vibe-meter-monitor-your-ai-costs).\n\n## Resources\n\n- [Sparkle Sandboxing Documentation](https://sparkle-project.org/documentation/sandboxing/)\n- [Apple’s Code Signing Guide](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution)\n- [VibeMeter Source Code](https://github.com/steipete/VibeMeter)\n- [VibeMeter Build Scripts](https://github.com/steipete/VibeMeter/tree/main/scripts)\n\n* * *\n\n*Special thanks to the Sparkle team and Claude Code - without them, this automation pipeline wouldn’t exist.*\n\n**P.S.** Just [steal my scripts](https://github.com/steipete/VibeMeter/tree/main/scripts). It’ll save you days of debugging. ☕️\n\n[^1]: An appcast is an RSS-like XML feed that Sparkle uses to check for updates. It contains information about available versions, download URLs, and release notes. See [Sparkle’s documentation on appcasts](https://sparkle-project.org/documentation/publishing/) for more details.\n\n[^2]: The Downloader service is only needed if your app doesn’t have network access. Since Vibe Meter includes the `com.apple.security.network.client` entitlement, we can disable SUEnableDownloaderService. This simplifies the setup and avoids the Downloader service’s limitations. See [Sparkle’s sandboxing documentation](https://sparkle-project.github.io/documentation/sandboxing/) for details.\n", "authors": [], "captured_at": "2026-09-27T19:29:15.293681927+00:00", "category": "programming", "content_html": "

    \"\"

    \n

    Or: How I Learned to Stop Worrying and Love the XPC Services

    \n

    If you’ve ever tried to implement automatic updates in a sandboxed macOS app using Sparkle, you know it can feel like trying to solve a Rubik’s cube while wearing oven mitts. After creating way too many beta releases and spending countless hours debugging cryptic authorization errors, I finally cracked the code. Here’s my step-by-step guide to code signing, notarization, and Sparkle auto-updates in sandboxed macOS apps.

    \n

    The Setup: Vibe Meter Meets Sparkle

    \n

    Vibe Meter is a sandboxed macOS menu bar app that tracks AI service spending. When I decided to add automatic updates using Sparkle 2.x, I thought it would be straightforward. After all, Sparkle is the de facto standard for macOS app updates, right?

    \n

    Oh, sweet summer child.

    \n

    Act 1: The Mysterious Authorization Failure

    \n

    I’d already mastered code signing and notarization (its own nightmare), so I just told Claude: “Look at this repository and do what we did there.” It nailed the signing and notarization process.

    \n

    My first attempts seemed promising. The app built, signed, and notarized successfully. But when users tried to update, they were greeted with:

    \n
    Error: Failed to gain authorization required to update target\n
    \n

    This error is Sparkle’s polite way of saying “I can’t talk to my XPC services, and I have no idea why.”

    \n

    Act 2: The Entitlements Enigma

    \n

    After digging through Sparkle’s documentation and Console logs, I discovered my first issue: missing mach-lookup entitlements. In a sandboxed app, Sparkle uses XPC services to perform privileged operations, and these services need special permissions to communicate.

    \n

    The Missing Piece

    \n

    My entitlements file was missing a critical entry:

    \n
    <key>com.apple.security.temporary-exception.mach-lookup.global-name</key>\n<array>\n    <string>com.steipete.vibemeter-spks</string>\n    <string>com.steipete.vibemeter-spki</string>\n</array>\n
    \n

    But here’s the kicker - I initially only added -spks, thinking it stood for “Sparkle Server.” Turns out, you need BOTH:

    \n
      \n
    • -spks: Sparkle Server (for the InstallerLauncher.xpc service)
      • \n
    • -spki: Sparkle Installer (for the Installer.xpc service)
      • \n
    \n

    Missing either one results in the dreaded authorization error.

    \n

    Act 3: The Code Signing Circus

    \n

    Next came the code signing adventures. My notarization script was doing what seemed logical:

    \n
    codesign --deep --force --sign "Developer ID" VibeMeter.app\n
    \n

    But Sparkle’s documentation specifically warns against using --deep. Why? Because it can mess up the XPC services’ signatures. Instead, you need to sign components in a specific order.

    \n

    Here’s the correct approach from my codesign script:

    \n
    # Sign XPC services first\ncodesign -f -s "$SIGN_IDENTITY" -o runtime \\\n    "$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/Installer.xpc"\n\n# Preserve entitlements for Downloader.xpc (Sparkle 2.6+)\ncodesign -f -s "$SIGN_IDENTITY" -o runtime --preserve-metadata=entitlements \\\n    "$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/Downloader.xpc"\n\n# Sign other Sparkle components\ncodesign -f -s "$SIGN_IDENTITY" -o runtime \\\n    "$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/Autoupdate"\n\n# Then sign the framework\ncodesign -f -s "$SIGN_IDENTITY" -o runtime \\\n    "$APP_BUNDLE/Contents/Frameworks/Sparkle.framework"\n\n# Finally, sign the app WITHOUT --deep\ncodesign --force --sign "$SIGN_IDENTITY" --entitlements VibeMeter.entitlements \\\n    --options runtime VibeMeter.app\n
    \n

    Act 4: The Bundle ID Bamboozle

    \n

    At one point, I thought I was being clever (or rather, Claude Code thought…) by trying to manually modify the XPC services’ bundle identifiers. Big mistake.

    \n

    For sandboxed apps, Sparkle requires specific bundle ID suffixes:

    \n
      \n
    • Use -spks suffix for the InstallerLauncher service
      • \n
    • Use -spki suffix for the Installer service
      • \n
    \n

    The framework expects these exact suffixes. Use anything else, and you’ll get cryptic XPC connection errors that will make you question your career choices.

    \n

    Act 5: The Build Number Blues

    \n

    Even after fixing all the sandboxing issues, I hit another snag. Users were seeing “You’re up to date!” when updates were clearly available. The culprit? My appcast1 generation script was defaulting build numbers to “1”.

    \n

    Sparkle uses build numbers (CFBundleVersion), not version strings, to determine if an update is available. If your build numbers don’t increment, Sparkle thinks there’s nothing new.

    \n

    My appcast generation script now properly handles this:

    \n
    # Extract build number from Info.plist\nBUILD_NUMBER=$(plutil -extract CFBundleVersion raw "$INFO_PLIST")\n\n# Ensure build numbers increment correctly\nif [[ "$BUILD_NUMBER" -le "$PREVIOUS_BUILD_NUMBER" ]]; then\n    echo "Error: Build number must be greater than previous release"\n    exit 1\nfi\n
    \n

    The Grand Finale: It Works!

    \n

    \"Sparkle

    \n

    After two days of intense debugging, I finally had a working setup. My complete automation pipeline is now rock-solid, with comprehensive scripts that handle every aspect of the process.

    \n

    The Magic Recipe

    \n
      \n
    1. Entitlements: Include BOTH -spks and -spki mach-lookup exceptions
      2. \n
    2. Bundle IDs: Never change Sparkle’s XPC service bundle IDs
      3. \n
    3. Code Signing: Sign XPC services individually, never use --deep
      4. \n
    4. Build Numbers: Always increment them, and verify your appcast
      5. \n
    5. Info.plist: Set SUEnableInstallerLauncherService = true and SUEnableDownloaderService = false2
      6. \n
    \n

    The Working Configuration

    \n

    The XPC services themselves keep their original Sparkle bundle IDs (org.sparkle-project.InstallerLauncher and org.sparkle-project.Downloader). What we configure in the entitlements are the mach-lookup communication channels:

    \n
    <!-- VibeMeter.entitlements -->\n<key>com.apple.security.app-sandbox</key>\n<true/>\n<key>com.apple.security.network.client</key>\n<true/>\n<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>\n<array>\n    <string>com.steipete.vibemeter-spks</string>\n    <string>com.steipete.vibemeter-spki</string>\n</array>\n
    \n

    The Scripts That Saved My Sanity

    \n

    My complete build pipeline consists of several specialized scripts:

    \n\n

    Look at this beauty! Now even Claude can do releases without messing up 🎉 I just tell it “Create a new beta release, see release.md” and it handles everything.

    \n
    # Now create the release\n./scripts/release.sh stable        # For stable 1.1.0\n# OR\n./scripts/release.sh beta 1        # For 1.1.0-beta.1\n\n# Use the version script to bump versions\n./scripts/version.sh --minor       # 1.0.0 -> 1.1.0\n./scripts/version.sh --major       # 1.0.0 -> 2.0.0\n./scripts/version.sh --set 1.1.0   # Set specific version\n
    \n

    Everything happens automatically - from building to GitHub release creation. These scripts are tuned for Tuist and can easily be adapted for simpler setups.

    \n

    The Notarization Nightmare

    \n

    Apple’s notarization process adds another layer of complexity. Notarization verifies your app is safe - you upload it to Apple’s servers for scanning, and if approved, they “staple” a ticket to your app. The process typically takes a few minutes in Apple’s notarization queue (officially called the “processing queue”). The notarization script uses the modern notarytool approach:

    \n
    # Create ZIP for notarization (not DMG!)\nditto -c -k --keepParent "$APP_BUNDLE" "$ZIP_PATH"\n\n# Submit for notarization\nxcrun notarytool submit "$ZIP_PATH" \\\n    --key "$API_KEY_PATH" \\\n    --key-id "$API_KEY_ID" \\\n    --issuer "$ISSUER_ID" \\\n    --wait\n\n# Staple the ticket\nxcrun stapler staple "$APP_BUNDLE"\n\n# Verify everything worked\nspctl -a -t exec -vv "$APP_BUNDLE"\nxcrun stapler validate "$APP_BUNDLE"\n
    \n

    Of course this needs certificates from Apple. Luckily Claude is smart enough to guide you through the whole process of downloading those files and adding them to the keychain and your environment.

    \n

    Pretty Changelogs in Sparkle

    \n

    One challenge I hadn’t anticipated was making the update dialogs actually useful. Sparkle can display rich HTML changelogs, but getting from my Markdown changelog to properly formatted HTML required some creativity.

    \n

    The changelog-to-html.sh script extracts version-specific sections from CHANGELOG.md and converts them to HTML with what I call the “Poor Man’s Markdown Parser”:

    \n
    # Extract version section and convert Markdown to HTML\nawk "/^## \\\\[$version\\\\]/{flag=1;next}/^## \\\\[/{flag=0}flag" CHANGELOG.md | \\\nsed 's/^### \\(.*\\)/<h3>\\1<\\/h3>/' | \\\nsed 's/^- \\(.*\\)/<li>\\1<\\/li>/' | \\\nsed 's/\\*\\*\\([^*]*\\)\\*\\*/<strong>\\1<\\/strong>/g'\n
    \n

    The result? Users see properly formatted changelogs with headers, lists, and styled text instead of raw Markdown. Note: This parser has limitations - it doesn’t handle nested lists, images, or links. Keep your changelogs simple or extend the parser for more complex formatting.

    \n

    The Complete Architecture

    \n

    What emerged is a surprisingly elegant zero-infrastructure solution that leverages GitHub’s existing services:

    \n

    GitHub-Centric Distribution

    \n
      \n
    • Releases: GitHub releases host the actual DMG files
      • \n
    • Appcast Hosting: Raw GitHub URLs serve the XML feeds
      • \n
    • Dual Feeds: Separate appcasts for stable and pre-release channels
      • \n
    • Version Control: Appcast files are versioned alongside the code
      • \n
    \n

    Dynamic Channel Switching

    \n

    The app includes runtime logic to switch between update channels without reinstallation. Users can choose “stable” for production releases or “pre-release” for beta access, and the app dynamically points to the appropriate appcast URL.

    \n

    \"Vibe

    \n

    Automated Everything

    \n

    The release.sh script orchestrates the entire pipeline:

    \n
      \n
    1. Build and sign the app
      2. \n
    2. Create GitHub release with DMG
      3. \n
    3. Generate both appcast files with proper signatures
      4. \n
    4. Commit and push everything
      5. \n
    \n

    No separate hosting, no Jekyll setup, no additional infrastructure - just GitHub doing what it does best. The key is that release.sh is the master orchestrator that calls most other scripts in sequence for a complete automated release.

    \n

    View the complete script flow architecture

    \n
    🚀 Main Release Flow (release.sh)\n\nrelease.sh\n├── 1. preflight-check.sh ────────────── Validates everything ready\n├── 2. generate-xcproj.sh ────────────── Generates Xcode project\n├── 3. build.sh ──────────────────────── Builds app with IS_PRERELEASE_BUILD flag\n├── 4. sign-and-notarize.sh ──────────── Signs & notarizes app\n│   ├── codesign-app.sh ─────────────── Code signs app bundle\n│   └── notarize-app.sh ─────────────── Notarizes signed app\n├── 5. create-dmg.sh ─────────────────── Creates & signs DMG\n├── 6. GitHub CLI (gh) ───────────────── Creates GitHub release\n├── 7. generate-appcast.sh ───────────── Updates appcast XML files\n└── 8. verify-appcast.sh ─────────────── Validates appcast (optional)\n\n✅ Verification Flow\n\npreflight-check.sh ───────────────────── Pre-release validation\n└── verify-prerelease-system.sh ──────── IS_PRERELEASE_BUILD system check\n\nverify-app.sh ────────────────────────── Post-build verification\nverify-appcast.sh ────────────────────── Appcast validation\n\n🔐 Manual Signing Flow\n\nsign-and-notarize.sh\n├── codesign-app.sh ──────────────────── Code sign app\n├── notarize-app.sh ──────────────────── Notarize app\n└── create-dmg.sh ────────────────────── Create distribution DMG\n\n🛠️ Utility Scripts (Called by others)\n\n- changelog-to-html.sh ← Called by update-appcast.sh\n- version.sh ← Standalone version management\n
    \n

    Lessons Learned

    \n
      \n
    1. Read the documentation carefully - But also know that it might not cover every edge case
      2. \n
    2. Console.app is your friend - Filter by your process name and watch for XPC errors
      3. \n
    3. Don’t be clever - Follow Sparkle’s conventions exactly
      4. \n
    4. Test updates, not just builds - A successful build doesn’t mean updates will work
      5. \n
    5. Automate everything - Manual processes lead to human errors
      6. \n
    6. Version control your scripts - Build automation is as important as your app code
      7. \n
    \n

    Final Thoughts

    \n

    Implementing Sparkle in a sandboxed app is like solving a puzzle where the pieces keep changing shape. But once you understand the rules - respect the XPC services, get your entitlements right, and sign everything properly - it works beautifully.

    \n

    The irony? The final solution is actually quite simple. It’s getting there that’s the adventure. I don’t know how anyone manages to ship working macOS apps at all, honestly.

    \n

    Now go download Vibe Meter and read my dev diary on how I built it with Claude Code: Vibe Meter: Monitor Your AI Costs.

    \n

    Resources

    \n\n
    \n

    Special thanks to the Sparkle team and Claude Code - without them, this automation pipeline wouldn’t exist.

    \n

    P.S. Just steal my scripts. It’ll save you days of debugging. ☕️

    \n
    \n
      \n
    1. \n

      An appcast is an RSS-like XML feed that Sparkle uses to check for updates. It contains information about available versions, download URLs, and release notes. See Sparkle’s documentation on appcasts for more details. ↩

      \n
      2. \n
    2. \n

      The Downloader service is only needed if your app doesn’t have network access. Since Vibe Meter includes the com.apple.security.network.client entitlement, we can disable SUEnableDownloaderService. This simplifies the setup and avoids the Downloader service’s limitations. See Sparkle’s sandboxing documentation for details. ↩

      \n
      3. \n
    \n
    \n", "content_markdown": "![](https://steipete.me/assets/img/2025/code-signing-and-notarization-sparkle-and-tears/header.png)\n\n*Or: How I Learned to Stop Worrying and Love the XPC Services*\n\nIf you’ve ever tried to implement automatic updates in a sandboxed macOS app using Sparkle, you know it can feel like trying to solve a Rubik’s cube while wearing oven mitts. After creating way too many beta releases and spending countless hours debugging cryptic authorization errors, I finally cracked the code. Here’s my step-by-step guide to code signing, notarization, and Sparkle auto-updates in sandboxed macOS apps.\n\n## The Setup: Vibe Meter Meets Sparkle\n\n[Vibe Meter](https://vibemeter.ai) is a sandboxed macOS menu bar app that tracks AI service spending. When I decided to add automatic updates using Sparkle 2.x, I thought it would be straightforward. After all, Sparkle is the de facto standard for macOS app updates, right?\n\nOh, sweet summer child.\n\n## Act 1: The Mysterious Authorization Failure\n\nI’d already mastered code signing and notarization (its own nightmare), so I just told Claude: “Look at this repository and do what we did there.” It nailed the signing and notarization process.\n\nMy first attempts seemed promising. The app built, signed, and notarized successfully. But when users tried to update, they were greeted with:\n\n```plaintext\nError: Failed to gain authorization required to update target\n```\n\nThis error is Sparkle’s polite way of saying “I can’t talk to my XPC services, and I have no idea why.”\n\n## Act 2: The Entitlements Enigma\n\nAfter digging through [Sparkle’s documentation](https://sparkle-project.org/documentation/sandboxing/) and Console logs, I discovered my first issue: missing mach-lookup entitlements. In a sandboxed app, Sparkle uses XPC services to perform privileged operations, and these services need special permissions to communicate.\n\n### The Missing Piece\n\nMy entitlements file was missing a critical entry:\n\n```xml\ncom.apple.security.temporary-exception.mach-lookup.global-name\n\n com.steipete.vibemeter-spks\n com.steipete.vibemeter-spki\n\n```\n\nBut here’s the kicker - I initially only added `-spks`, thinking it stood for “Sparkle Server.” Turns out, you need BOTH:\n\n- `-spks`: Sparkle Server (for the InstallerLauncher.xpc service)\n- `-spki`: Sparkle Installer (for the Installer.xpc service)\n\nMissing either one results in the dreaded authorization error.\n\n## Act 3: The Code Signing Circus\n\nNext came the code signing adventures. My notarization script was doing what seemed logical:\n\n```bash\ncodesign --deep --force --sign \"Developer ID\" VibeMeter.app\n```\n\nBut Sparkle’s documentation specifically warns against using `--deep`. Why? Because it can mess up the XPC services’ signatures. Instead, you need to sign components in a specific order.\n\nHere’s the correct approach from my [codesign script](https://github.com/steipete/VibeMeter/blob/main/scripts/codesign-app.sh):\n\n```bash\n# Sign XPC services first\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/Installer.xpc\"\n\n# Preserve entitlements for Downloader.xpc (Sparkle 2.6+)\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime --preserve-metadata=entitlements \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/Downloader.xpc\"\n\n# Sign other Sparkle components\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework/Versions/B/Autoupdate\"\n\n# Then sign the framework\ncodesign -f -s \"$SIGN_IDENTITY\" -o runtime \\\n \"$APP_BUNDLE/Contents/Frameworks/Sparkle.framework\"\n\n# Finally, sign the app WITHOUT --deep\ncodesign --force --sign \"$SIGN_IDENTITY\" --entitlements VibeMeter.entitlements \\\n --options runtime VibeMeter.app\n```\n\n## Act 4: The Bundle ID Bamboozle\n\nAt one point, I thought I was being clever (or rather, [Claude Code](https://steipete.me/posts/claude-code-is-my-computer/) thought…) by trying to manually modify the XPC services’ bundle identifiers. Big mistake.\n\nFor sandboxed apps, Sparkle requires specific bundle ID suffixes:\n\n- Use `-spks` suffix for the InstallerLauncher service\n- Use `-spki` suffix for the Installer service\n\nThe framework expects these exact suffixes. Use anything else, and you’ll get cryptic XPC connection errors that will make you question your career choices.\n\n## Act 5: The Build Number Blues\n\nEven after fixing all the sandboxing issues, I hit another snag. Users were seeing “You’re up to date!” when updates were clearly available. The culprit? My appcast[^1] generation script was defaulting build numbers to “1”.\n\nSparkle uses build numbers (CFBundleVersion), not version strings, to determine if an update is available. If your build numbers don’t increment, Sparkle thinks there’s nothing new.\n\nMy [appcast generation script](https://github.com/steipete/VibeMeter/blob/main/scripts/generate-appcast.sh) now properly handles this:\n\n```bash\n# Extract build number from Info.plist\nBUILD_NUMBER=$(plutil -extract CFBundleVersion raw \"$INFO_PLIST\")\n\n# Ensure build numbers increment correctly\nif [[ \"$BUILD_NUMBER\" -le \"$PREVIOUS_BUILD_NUMBER\" ]]; then\n echo \"Error: Build number must be greater than previous release\"\n exit 1\nfi\n```\n\n## The Grand Finale: It Works!\n\n![Sparkle update dialog working perfectly](https://steipete.me/assets/img/2025/code-signing-and-notarization-sparkle-and-tears/sparkle.png)\n\nAfter two days of intense debugging, I finally had a working setup. My complete automation pipeline is now rock-solid, with [comprehensive scripts](https://github.com/steipete/VibeMeter/tree/main/scripts) that handle every aspect of the process.\n\n### The Magic Recipe\n\n1. **Entitlements**: Include BOTH `-spks` and `-spki` mach-lookup exceptions\n2. **Bundle IDs**: Never change Sparkle’s XPC service bundle IDs\n3. **Code Signing**: Sign XPC services individually, never use `--deep`\n4. **Build Numbers**: Always increment them, and verify your appcast\n5. **Info.plist**: Set `SUEnableInstallerLauncherService = true` and `SUEnableDownloaderService = false`[^2]\n\n### The Working Configuration\n\nThe XPC services themselves keep their original Sparkle bundle IDs (`org.sparkle-project.InstallerLauncher` and `org.sparkle-project.Downloader`). What we configure in the entitlements are the mach-lookup communication channels:\n\n```xml\n\ncom.apple.security.app-sandbox\n\ncom.apple.security.network.client\n\ncom.apple.security.temporary-exception.mach-lookup.global-name\n\n com.steipete.vibemeter-spks\n com.steipete.vibemeter-spki\n\n```\n\n## The Scripts That Saved My Sanity\n\nMy complete build pipeline consists of several specialized scripts:\n\n- **[preflight-check.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/preflight-check.sh)**: Validates environment and prerequisites\n- **[codesign-app.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/codesign-app.sh)**: Handles the complex code signing process\n- **[notarize-app.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/notarize-app.sh)**: Manages notarization and stapling\n- **[create-dmg.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/create-dmg.sh)**: Creates and signs distribution DMGs\n- **[generate-appcast.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/generate-appcast.sh)**: Generates Sparkle appcast files\n- **[release.sh](https://github.com/steipete/VibeMeter/blob/main/scripts/release.sh)**: Orchestrates the entire release process\n\nLook at this beauty! Now even Claude can do releases without messing up 🎉 I just tell it “Create a new beta release, see release.md” and it handles everything.\n\n```bash\n# Now create the release\n./scripts/release.sh stable # For stable 1.1.0\n# OR\n./scripts/release.sh beta 1 # For 1.1.0-beta.1\n\n# Use the version script to bump versions\n./scripts/version.sh --minor # 1.0.0 -> 1.1.0\n./scripts/version.sh --major # 1.0.0 -> 2.0.0\n./scripts/version.sh --set 1.1.0 # Set specific version\n```\n\nEverything happens automatically - from building to GitHub release creation. These scripts are tuned for [Tuist](https://tuist.dev/) and can easily be adapted for simpler setups.\n\n## The Notarization Nightmare\n\nApple’s notarization process adds another layer of complexity. Notarization verifies your app is safe - you upload it to Apple’s servers for scanning, and if approved, they “staple” a ticket to your app. The process typically takes a few minutes in Apple’s notarization queue (officially called the “processing queue”). The [notarization script](https://github.com/steipete/VibeMeter/blob/main/scripts/notarize-app.sh) uses the modern [`notarytool`](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution) approach:\n\n```bash\n# Create ZIP for notarization (not DMG!)\nditto -c -k --keepParent \"$APP_BUNDLE\" \"$ZIP_PATH\"\n\n# Submit for notarization\nxcrun notarytool submit \"$ZIP_PATH\" \\\n --key \"$API_KEY_PATH\" \\\n --key-id \"$API_KEY_ID\" \\\n --issuer \"$ISSUER_ID\" \\\n --wait\n\n# Staple the ticket\nxcrun stapler staple \"$APP_BUNDLE\"\n\n# Verify everything worked\nspctl -a -t exec -vv \"$APP_BUNDLE\"\nxcrun stapler validate \"$APP_BUNDLE\"\n```\n\nOf course this needs [certificates from Apple](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution). Luckily Claude is smart enough to guide you through the whole process of downloading those files and adding them to the keychain and your environment.\n\n## Pretty Changelogs in Sparkle\n\nOne challenge I hadn’t anticipated was making the update dialogs actually useful. Sparkle can display rich HTML changelogs, but getting from my Markdown changelog to properly formatted HTML required some creativity.\n\nThe [changelog-to-html.sh script](https://github.com/steipete/VibeMeter/blob/main/scripts/changelog-to-html.sh) extracts version-specific sections from `CHANGELOG.md` and converts them to HTML with what I call the “Poor Man’s Markdown Parser”:\n\n```bash\n# Extract version section and convert Markdown to HTML\nawk \"/^## \\\\[$version\\\\]/{flag=1;next}/^## \\\\[/{flag=0}flag\" CHANGELOG.md | \\\nsed 's/^### \\(.*\\)/

    \\1<\\/h3>/' | \\\nsed 's/^- \\(.*\\)/
  • \\1<\\/li>/' | \\\nsed 's/\\*\\*\\([^*]*\\)\\*\\*/\\1<\\/strong>/g'\n```\n\nThe result? Users see properly formatted changelogs with headers, lists, and styled text instead of raw Markdown. Note: This parser has limitations - it doesn’t handle nested lists, images, or links. Keep your changelogs simple or extend the parser for more complex formatting.\n\n## The Complete Architecture\n\nWhat emerged is a surprisingly elegant zero-infrastructure solution that leverages GitHub’s existing services:\n\n### GitHub-Centric Distribution\n\n- **Releases**: [GitHub releases](https://github.com/steipete/VibeMeter/releases) host the actual DMG files\n- **Appcast Hosting**: [Raw GitHub URLs](https://raw.githubusercontent.com/steipete/VibeMeter/main/appcast.xml) serve the XML feeds\n- **Dual Feeds**: Separate appcasts for [stable](https://github.com/steipete/VibeMeter/blob/main/appcast.xml) and [pre-release](https://github.com/steipete/VibeMeter/blob/main/appcast-prerelease.xml) channels\n- **Version Control**: Appcast files are versioned alongside the code\n\n### Dynamic Channel Switching\n\nThe app includes runtime logic to switch between update channels without reinstallation. Users can choose “stable” for production releases or “pre-release” for beta access, and the app dynamically points to the appropriate appcast URL.\n\n![Vibe Meter settings showing update channel options](https://steipete.me/assets/img/2025/code-signing-and-notarization-sparkle-and-tears/vibemeter-settings.png)\n\n### Automated Everything\n\nThe [release.sh script](https://github.com/steipete/VibeMeter/blob/main/scripts/release.sh) orchestrates the entire pipeline:\n\n1. Build and sign the app\n2. Create GitHub release with DMG\n3. Generate both appcast files with proper signatures\n4. Commit and push everything\n\nNo separate hosting, no Jekyll setup, no additional infrastructure - just GitHub doing what it does best. The key is that [`release.sh`](https://github.com/steipete/VibeMeter/blob/main/scripts/release.sh) is the master orchestrator that calls most other scripts in sequence for a complete automated release.\n\nView the complete script flow architecture\n\n```plaintext\n🚀 Main Release Flow (release.sh)\n\nrelease.sh\n├── 1. preflight-check.sh ────────────── Validates everything ready\n├── 2. generate-xcproj.sh ────────────── Generates Xcode project\n├── 3. build.sh ──────────────────────── Builds app with IS_PRERELEASE_BUILD flag\n├── 4. sign-and-notarize.sh ──────────── Signs & notarizes app\n│ ├── codesign-app.sh ─────────────── Code signs app bundle\n│ └── notarize-app.sh ─────────────── Notarizes signed app\n├── 5. create-dmg.sh ─────────────────── Creates & signs DMG\n├── 6. GitHub CLI (gh) ───────────────── Creates GitHub release\n├── 7. generate-appcast.sh ───────────── Updates appcast XML files\n└── 8. verify-appcast.sh ─────────────── Validates appcast (optional)\n\n✅ Verification Flow\n\npreflight-check.sh ───────────────────── Pre-release validation\n└── verify-prerelease-system.sh ──────── IS_PRERELEASE_BUILD system check\n\nverify-app.sh ────────────────────────── Post-build verification\nverify-appcast.sh ────────────────────── Appcast validation\n\n🔐 Manual Signing Flow\n\nsign-and-notarize.sh\n├── codesign-app.sh ──────────────────── Code sign app\n├── notarize-app.sh ──────────────────── Notarize app\n└── create-dmg.sh ────────────────────── Create distribution DMG\n\n🛠️ Utility Scripts (Called by others)\n\n- changelog-to-html.sh ← Called by update-appcast.sh\n- version.sh ← Standalone version management\n```\n\n## Lessons Learned\n\n1. **Read the documentation carefully** - But also know that it might not cover every edge case\n2. **Console.app is your friend** - Filter by your process name and watch for XPC errors\n3. **Don’t be clever** - Follow Sparkle’s conventions exactly\n4. **Test updates, not just builds** - A successful build doesn’t mean updates will work\n5. **Automate everything** - Manual processes lead to human errors\n6. **Version control your scripts** - Build automation is as important as your app code\n\n## Final Thoughts\n\nImplementing Sparkle in a sandboxed app is like solving a puzzle where the pieces keep changing shape. But once you understand the rules - respect the XPC services, get your entitlements right, and sign everything properly - it works beautifully.\n\nThe irony? The final solution is actually quite simple. It’s getting there that’s the adventure. I don’t know how anyone manages to ship working macOS apps at all, honestly.\n\nNow go download [Vibe Meter](https://vibemeter.ai) and read my dev diary on how I built it with Claude Code: [Vibe Meter: Monitor Your AI Costs](https://steipete.me/posts/vibe-meter-monitor-your-ai-costs).\n\n## Resources\n\n- [Sparkle Sandboxing Documentation](https://sparkle-project.org/documentation/sandboxing/)\n- [Apple’s Code Signing Guide](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution)\n- [VibeMeter Source Code](https://github.com/steipete/VibeMeter)\n- [VibeMeter Build Scripts](https://github.com/steipete/VibeMeter/tree/main/scripts)\n\n* * *\n\n*Special thanks to the Sparkle team and Claude Code - without them, this automation pipeline wouldn’t exist.*\n\n**P.S.** Just [steal my scripts](https://github.com/steipete/VibeMeter/tree/main/scripts). It’ll save you days of debugging. ☕️\n\n[^1]: An appcast is an RSS-like XML feed that Sparkle uses to check for updates. It contains information about available versions, download URLs, and release notes. See [Sparkle’s documentation on appcasts](https://sparkle-project.org/documentation/publishing/) for more details.\n\n[^2]: The Downloader service is only needed if your app doesn’t have network access. Since Vibe Meter includes the `com.apple.security.network.client` entitlement, we can disable SUEnableDownloaderService. This simplifies the setup and avoids the Downloader service’s limitations. See [Sparkle’s sandboxing documentation](https://sparkle-project.github.io/documentation/sandboxing/) for details.\n", "dateCreated": "2026-09-27T19:29:15.293681927+00:00", "date_created": "2025-06-05T07:00:00+00:00", "date_modified": "2025-06-05T07:00:00+00:00", "date_published": "2025-06-05T07:00:00+00:00", "description": "My brutal journey implementing Sparkle auto-updates in sandboxed macOS apps - from 40 failed releases to enlightenment.", "external_url": "https://steipete.me/posts/2025/code-signing-and-notarization-sparkle-and-tears/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/steipete-me/2025/06/2025-06-05-code-signing-and-notarization-sparkle-and-tears.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/steipete-me/2025/06/2025-06-05-code-signing-and-notarization-sparkle-and-tears.md" }, "id": "urn:aggr:item:76d5f33058c84a76be425a01280acb64b1a1a4d7", "isBasedOn": { "@id": "https://steipete.me/posts/2025/code-signing-and-notarization-sparkle-and-tears/" }, "mainEntity": { "@id": "https://steipete.me/posts/2025/code-signing-and-notarization-sparkle-and-tears/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-05-code-signing-and-notarization-sparkle-and-tears/#webpage" }, "dateModified": "2025-06-05T07:00:00+00:00", "datePublished": "2025-06-05T07:00:00+00:00", "headline": "Code Signing and Notarization: Sparkle and Tears", "timeRequired": "PT9M", "url": "https://steipete.me/posts/2025/code-signing-and-notarization-sparkle-and-tears/", "wordCount": 1806 }, "name": "Archived snapshot: Code Signing and Notarization: Sparkle and Tears", "preview": null, "reading_minutes": 9, "replicated_at": null, "source": "steipete-me", "source_name": "Peter Steinberger", "summary": "My brutal journey implementing Sparkle auto-updates in sandboxed macOS apps - from 40 failed releases to enlightenment.", "tags": [], "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00", "title": "Code Signing and Notarization: Sparkle and Tears", "url": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-05-code-signing-and-notarization-sparkle-and-tears/", "word_count": 1806 }