Note using Sparkle in a sandboxed application is only supported in Sparkle 2.0, which is currently in beta.
In order for Sparkle to work in a sandboxed application, the application must call out to XPC services to perform the updating and installation. Note if you do not sandbox your application, you do not need to use any XPC services and may skip this page.
In an extracted Sparkle-2.0.0.tar.xz
distribution in the XPCServices/
directory you will notice:
If you build Sparkle yourself, you can optionally choose to change XPC_SERVICE_BUNDLE_ID_PREFIX
in ConfigCommon.xcconfig
from org.sparkle-project
to your own prefix.
The last downloader XPC Service is optional. Use it only if your sandboxed application does not request the com.apple.security.network.client
entitlement. The downloader service allows using Sparkle without forcing the network client entitlement on your entire application. There are a couple caveats with using the downloader service though:
Note: Skip this code signing step if you use Xcode’s Archive Organizer to Distribute your App, which is the recommended way of distributing applications. It will manage re-signing these services in your application with the appropriate entitlements automatically.
Otherwise, if you use other workflows you will also need to code sign these services by running:
./bin/codesign_embedded_executable "Developer ID Application" XPCServices/*.xpc
I used “Developer ID Application” for my certificate; you may need to adjust this.
Due to the XPC Services being code signed with the Hardened Runtime enabled, Xcode cannot debug the XPC Services and you may see that updating does not work when your application is attached to Xcode’s debugger. You can work around this either by editing your project’s Scheme and disabling Debug XPC services used by app or by testing your application detached from Xcode.