The Sparkle XPC fork is even better than I would’ve imagined!
As I mentioned in the previous post about Sparkle’s XPC branch, you can switch to the new framework version and the new types without having to change much else. The new API is very similar to the old one. If you switch to the work-in-progress
ui-separation-and-xpc branch, then you can continue to use CocoaPods or Carthage if all you want is the new API.
Only when you want to use the XPC services will you have to build the Sparkle build products yourself.
That means the Sparkle framework does not require the XPC services to work. They are optional. Unless you want to use them, you won’t notice any difference.
But how do you set up your app to use the XPC services if you want to? Is there a new initializer or delegate callback or anything? If disabling XPC services is not required, then enabling must be, right?
Turns out Sparkle does all the decision making for us. In the
Sparkle.xcodeproj, search for occurrences of the
SPUXPCServiceExists function. Then you’ll see where Sparkle checks if an XPC service is present in its host bundle, aka your app:
- If no XPC services are bundled with your app, Sparkle more or less behaves like it used to for a decade and more.
- If you bundle the XPC services with your app, Sparkle will utilize them instead.
This is great, because that means you have zero configuration to do!
I was puzzled for a while after I set up the basics yesterday. What’s the next step? Bundle the XPC services with the app, and then what? Nothing: There is no step three!
I’m happy to see that the Sparkle project was designed to be this simple to use.
SPUXPCServiceExists function is also pretty simple: see code for
SPUXPCServiceInfo.m on GitHub.
This was the second post in a series:
- How to migrate to the new Sparkle XPC branch
- How to toggle use of XPC service (this post)
- How to build, embed, and notarize the XPC services in your app
Receive new posts via email.