Open-source AI projects with GitHub release updates in the past day, and the three Swift functions that decide whether the update reaches your Mac

It means the developer pushed a tag, GitHub built the release, and your machine has to install it. On macOS 26 the install side is the part that breaks. Sparkle, the standard Mac auto-updater, calls SMJobSubmit to launch a privileged installer service. macOS 26 introduced an 'on-demand-only' launchd mode and stricter code signature validation that together cause SUInstallationError code 4005 unless the app has App Management permission and the developer manually kickstarts the launchd service. Almost no listicle for this query mentions any of that.

Three Swift functions in github.com/mediar-ai/fazm. (1) kickstartSparkleServices() at Desktop/Sources/UpdaterViewModel.swift lines 209-238 retries `launchctl kickstart -p gui/<uid>/<bundleID>-sparkle-updater` at 0.5s, 2s, and 5s. (2) probeAndUnlockAppManagement() at lines 414-439 writes a temp file to `Bundle.main.bundlePath + "/Contents/.fazm-permission-test"` to detect when the user has granted App Management permission, then auto-resumes the install. (3) shouldProceedWithUpdate() at lines 88-101 throws when the new version equals UpdateRollbackManager.blockedVersion, refusing to install a tag that just crash-looped. All three are MIT-licensed source code, readable in the public repo.

Two changes. First, launchd on macOS 26 can run in 'on-demand-only mode' for user agents, which means a service submitted via SMJobSubmit with RunAtLoad=YES does not actually start at load time, only when something pings it. Sparkle 2.9.0 added a built-in probe via PR #2852, but the probe still does not always succeed under timing variance, which is why Fazm runs `launchctl kickstart` three times at 0.5s, 2.0s, and 5.0s after Sparkle's didExtractUpdate fires. Second, the system enforces App Management permission for any tool that wants to overwrite an app inside /Applications/. If the user has not granted it, AuthorizationCreate inside Sparkle's installer fails with NSOSStatusErrorDomain -60005, which Sparkle surfaces as SUSparkleErrorDomain code 4005.

macOS does not expose a clean 'is App Management granted' API for sandboxed processes. Fazm probes by trying to write a one-byte temp file at Bundle.main.bundlePath + '/Contents/.fazm-permission-test'. If the create succeeds, the file is deleted immediately and the app sets `hasSuccessfullyInstalledSparkleUpdate = true` in UserDefaults so the next update goes through Sparkle's normal UI without a guide. The probe runs on every launch but only when there is a pending guide for the previously-blocked version. The whole function is 23 lines of Swift in UpdaterViewModel.swift.

The cap is around 11 minutes. The backend appcast at fazm-backend caches GitHub's releases response for 60 seconds, so a new tag is reflected in /appcast.xml within a minute. Sparkle on the client polls every 600 seconds (UpdaterViewModel.swift line 361 sets `updateCheckInterval = 600`), and that timer fires uniformly distributed in [0, 600], so the median wait from tag-push to client-discovers-update is around 5 minutes 30 seconds, with a worst case at 11 minutes plus the cache TTL. After discovery, a successful install with the kickstart workaround typically completes in 4-8 seconds. If the user has not granted App Management permission yet, the App Management guide window appears instead of Sparkle's dialog, and the install pauses until they grant it.

If the new release crash-loops, three launches in 60 seconds triggers a rollback. The rolled-back version is stored in UserDefaults at `rollback_blockedVersion`. On the next Sparkle check, shouldProceedWithUpdate sees the available version equals blockedVersion and throws an NSError with domain `com.fazm.rollback`. That throw blocks the install and tells PostHog the version was blocked. The block clears automatically when GitHub publishes a NEWER version, which is exactly what makes a high cadence of past-day updates safe: a bad release is dead within minutes and the next tag fixes it without manual intervention.

v2.1.2 (Apr 7) added the 4005 detection branch in didAbortWithError that sets the `hasSeenAppManagementError` UserDefaults flag and resets the success flag so the App Management guide shows again. v2.1.3 (Apr 9) wired the guide ahead of Sparkle's UI in shouldProceedWithUpdate. v2.2.0 (Apr 11) added probeAndUnlockAppManagement() to the launch path so granting the permission and reopening would auto-resume. v2.2.1 (Apr 12) added the third retry of launchctl kickstart at the 5.0-second delay after FAZM-9K. v2.3.2 (Apr 16) is the first release after macOS 26.1 brought even stricter SMJobSubmit checks. Every one of these is a public tag at github.com/mediar-ai/fazm/releases.

Because the logger is the only thing you can trust during a Sparkle install. The comment at UpdaterViewModel.swift line 45 spells it out: 'Sparkle may terminate the app immediately after willInstallUpdate / didAbortWithError, so async logging would be lost.' UpdateRollbackManager goes further at line 11: 'All detection/restore code uses only Foundation + logSync — no Firebase, Sentry, or PostHog (those frameworks might be what is crashing).' If the update is bad, the analytics SDK might be the bug. The crash-loop detector cannot depend on it.

Yes. The minimum is three short Swift functions and one Sparkle delegate. (1) Implement kickstartSparkleServices(): at the end of didExtractUpdate, schedule three Process invocations of `/bin/launchctl kickstart -p gui/<uid>/<bundleID>-sparkle-updater` at 0.5s, 2.0s, 5.0s. (2) Implement probeAndUnlockAppManagement(): on every launch, if you have a pending guide, try to write a temp file inside Bundle.main.bundlePath + '/Contents/'; success means permission is granted. (3) Implement shouldProceedWithUpdate to throw when the version matches a stored blockedVersion key in UserDefaults. The total is around 80 lines, mostly defensive logging. Copy from Desktop/Sources/UpdaterViewModel.swift.

Screenshot-based cloud agents push model updates server-side. Their 'release' is a Firestore feature flag, not a binary install. Fazm reads the macOS accessibility tree directly via AXUIElementCreateApplication, which means the agent code lives inside the .app bundle, which means a model improvement OR an agent improvement requires a real binary update through Sparkle. That puts macOS 26's installer constraints squarely on the critical path. A consumer-friendly desktop AI app on the latest macOS has to ship its own Sparkle workarounds. There is no other option.

Look for three signals in the repo. First, a Swift file named UpdaterViewModel, UpdaterDelegate, or anything subclassing SPUUpdaterDelegate. Second, the substring 'launchctl kickstart' anywhere in the Swift sources (without it, the app will hit 4005 on macOS 26 and most users will give up). Third, the substring 'shouldProceedWithUpdate' implementing a version blocklist. If a repo has an SPUUpdaterDelegate but none of those three things, the project's same-day GitHub releases are not actually reaching users on macOS 26.