An old code base was still using Sparkler v1.27.0. To test the transition to the latest 2.x branch, the one that allows Sandboxing and uses XPC services under the hood, I migrated that project.

Carthage builds of Sparkle’s v2.x branch don’t work well, though. You would need to do a lot of manual re-signing, otherwise the code signing stage of your build will fails. It does with a simple test project that embeds and signs the framework.

A couple of years ago, manual signing was necessary, but not anymore. Since my M1 Monterey Mac forces me to use Xcode 13 anyway, I figured I might now just as well use SwiftPM – and that works like a charm!

So if you get an error like:

…/SparkleTestApp.app/Contents/Frameworks/Sparkle.framework/Versions/B: code object is not signed at all
In subcomponent: …/SparkleTestApp.app/Contents/Frameworks/Sparkle.framework/Versions/B/Autoupdate
Command CodeSign failed with a nonzero exit code

… then you might want to try to switch to SwiftPM or git submodule for Sparkle. (CocoaPods should work, too, but adding that on top of/next to Carthage seems weird.)

In The Archive and the Word Counter, I’m currently using a git submodule-based approach. That’s because I adopted the XPC-based changes quite early and needed to switch between my fork with some adjustments and the upstream code. So this is probably the first time in, what, 4 years?, that I’m relying on the vanilla version of Sparkle again. This increases my confidence in the updater I ship quite a bit.