Don't Use Sparkle 2.x With Carthage

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's framework out-of-the-box doesn't work well with code signing

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.

Receive new .