They should not be bundle IDs because they may surface up in the UI.
Particularly, the Installer XPC Service may show up in the authorization prompt when authorization is required to install an update.
I'm hoping this will ease some of the build configuration issues I've been running into.
Apps (eg: unsigned, not-sandboxed) don't need to (although they still can) use the XPC services.
Sandboxed apps naturally should use the XPC services. Although, you can for example, choose not to use the
downloader services if the host app already entitlements to allow network connections.
If you use the downloader services, you must configure ATS exceptions in them. And if you use those services,
you probably want to sign them with the required entitlements.
If you don't use the services, Sparkle will fall back on almost-identical code executed within the framework instead.
There may be other reasons to use the services or not other than for sandboxing, like fault tolerance.
Lastly, XPC services work within an application namespace. They are discoverable as long as they're in the app.
That's why we can have an app incorporate the services and let the framework use them.
Rename the XPC service products so that they start with 'Sparkle'
Make the bundle IDs of the services a part of the build configuration, so we can pass it to the preprocessor.
This allows Sparkle to be used as-is in a sandboxed application,
without needing to place Sparkle into its own XPC service.
Currently the main app may need to set a global mach service lookup exception
and a client download exception, however this can be fixed by creating a couple more
services. Testing for disk writability will need be done in a service too.
Daniel Jalkut
Zorg