0.8.0

This is a big release! Continued thanks to @amomchilov for his contributions and code reviews.

New functionality

• Adds built-in support for macOS Ventura's new SMAppService's daemons & agents.
  • For simple configurations, just call XPCServer.forMachService() and an auto-configured server will be returned.
• Experimental support for shared memory has been added. Shared memory is truly shared between processes, no encoding or decoding occurs like with typical XPC communication.
  • A friendly to use, although quite basic, data structure SharedTrivial demonstrates this functionality.
  • The building block pieces available through SharedSemaphore, SharedMemory, and SharedRawMemory should enable you to build your own custom multi-process data structures.
  • This support is experimental and while it remains experimental breaking changes to it will not be considered for SerVer purposes.
• XPCClient now provides the unforgeable identity of the server it is connected to via its serverIdentity async property (or the equivalent callback function).
• XPCClient now automatically verifies the identity of the server in common cases and this can be customized with XPCClient.ServerRequirement.
• XPCServer instances now always have an endpoint property (previously only those also conforming to XPCNonBlockingServer had this property).
• Send IOSurface instances over XPC connections using the IOSurfaceForXPC property wrapper.
• Data instances and arrays of trivial types can optionally be more efficiently sent across XPC connections by using the DataOptimizedForXPC and ArrayOptimizedForXPC property wrappers.

Breaking changes

• XPCServer retrieval has been simplified. There are now just three main entry points:
  • XPCServer.forThisXPCService()
  • XPCServer.forMachService()
  • XPCServer.makeAnonymous()
• XPCServer retrieval is now more customizable.
  • To customize a Mach service use XPCServer.MachServiceCriteria then call XPCServer.forMachService(withCriteria:)
  • To customize an anonymous server use XPCServer.makeAnonymous(withClientRequirement:)
• XPCServer's client requirements no longer require using SecRequirement directly (although that's still supported).
  • Requirements are now created using XPCServer.ClientRequirement and declarative in nature: XPCServer.makeAnonymous(withClientRequirement: try .sameTeamIdentifier || try .teamIdentifier("Q55ZG849VX"))
• XPCClient's factory methods have been tweaked to now optionally take a XPCClient.ServerRequirement instance.
• XPCFileDescriptorContainer has been replaced by the FileHandleForXPC and FileDescriptorForXPC property wrappers.
• XPCRequestContext has been renamed to XPCServer.ClientIdentity.
• Several XPCError cases have been removed and a few have been added.
• The underlying interprocess communication protocol between the client and server has changed (to support the client's ability to verify the server's identity). This means if you update SecureXPC, you need to do so for both your client and server implementations at the same time.

0.7.0

This release adds numerous improvements that result in breaking changes.

Breaking changes

• XPCServer's targetQueue property has been removed and replaced with a handlerQueue property with improved documentation. This queue is only used when running synchronous handlers. By default a concurrent queue is used to run synchronous handlers, but this can be set to a serial queue if desired.
• XPCClient and XPCServer's serviceName property has been replaced by a connectionDescriptor property. This property returns a type of XPCConnectionDescriptor which describes the connection and for non-anonymous connections includes the name.
• XPCServerEndpoint now also has a connectionDescriptor property which returns a value matching that of the XPCServer from which it was created.
• Most of XPCError's cases now have named parameters for their associated values. For example XPCError.routeMismatch(routeName:description:).

0.6.0

This release adds automatic support for login items.

New functionality

• Call XPCServer.forThisLoginItem() to be returned an auto-configured XPCServer for login items installed with SMLoginItemSetEnabled. This works for both sandboxed and non-sandboxed login items.

Breaking changes

• The underlying interprocess communication protocol between the client and server has changed (to support the above mentioned new functionality). This is true even if you are not using login items. This means if you update SecureXPC, you need to do so for both your client and server implementations at the same time.

0.5.2

This minor release introduces a new capability for file descriptors.

New functionality

• Adds XPCFileDescriptorContainer which can wrap a native file descriptor, a FileHandle, or a FileDescriptor enabling sending of live file descriptors across an XPC connection.

0.5.1

This release contains minor internal improvements. In particular, servers that have a sequential result not yet finished should avoid termination by the system.

0.5.0

This release contains a major new capability - sending multiple replies from the server for the same request.

New functionality

• Routes can now use sequential replies. On the server, a handler registered for a route with a sequential reply is passed a SequentialResultProvider with which it can send arbitrarily many responses to the client. On the client side these are exposed as an AsyncThrowingStream (or for the closure-based version as a callback provided SequentialResults).
  • The server side implementation can choose to finish a sequence or it can continue to provide values indefinitely. Amongst other use cases this is intended to replace any scenarios where the client is currently polling for new values - now the server can stream those to the client upon request.

Breaking changes

• The NonBlockingServer protocol has been renamed to XPCNonBlockingServer.
• The underlying interprocess communication protocol between the client and server has changed (to support the above mentioned new functionality). This means if you update SecureXPC, you need to do so for both your client and server implementations at the same time.

0.4.0

This release adds a bit of new functionality and also contains some minor breaking changes. Continued thanks to @amomchilov for all of his contributions and code reviews.

New functionality

• Support for all custom errors so long as they're Codable. Simply define them as part of an XPCRoute (doing so is optional) and they'll be decoded by the client. This is highly convenient when using the async send messages as the error itself will be throw. When using the closure based variants the error will be encapsulated within a HandlerError.
• An async closure/function can now be used as the error handler for an XPCServer.
• Within a closure registered with and called by an XPCServer the newly added XPCRequestContext can be used to access information about the request's client process. Usage of this information is entirely optional and likely not needed by most daemons and applications.

Breaking changes

• All of the route named parameters for XPCClient's send and sendMessage functions have been renamed to to. Otherwise functionality remains unchanged.
• To add an error handler to an XPCServer instead of assigning a closure to errorHandler, it must now be added using the setErrorHandler function. There are two variants of this function with identical names: one for async and one for "standard" synchronous closures.
• The XPCError.other case no longer exists.

0.3.1

• Fixes a bug where interrupted clients wouldn't reconnect properly when the service had terminated

0.3.0

This release adds significant new functionality and also contains many breaking changes. Big thanks to @amomchilov for all of the work he contributed to this release.

New functionality

• XPC services: create a server with XPCServer.forThisXPCService() and communicate with it using XPCClient.forXPCService(named:).
• Anonymous XPC: useful for testing and some advanced multiprocess communication scenarios.
• Swift concurrency: await sends from the client and register async routes with the server side (available on macOS 10.15 and later).
• A server's dispatch queue can now be set.
• Endpoints can be retrieved for anonymous and XPC Mach servers, optionally sent over another XPC connection, and used to create clients.
• Anonymous and XPC Mach servers can be started in a non-blocking manner.
• Improved error types and messages.

Changes

• XPC Mach servers are now retrieved with XPCServer.forThisBlessedHelperTool() or XPCServer.forThisMachService(named:clientRequirements:).
• To start a server in a blocking manner, use startAndBlock(). start() now starts the server and then returns.
• XPC Mach clients are now retrieved with XPCClient.forMachService(named:).
• The client's send and sendMessage functions which do not receive a reply must now either provide an onCompletion handler or explicitly pass in nil to indicate they do not want to be informed of completion or any errors.
• The clients send and sendMessage functions which receive a reply have had their withReply parameter renamed to withResponse.
• The client's send and sendMessage functions no longer throw; all errors are passed to either the onCompletion or withResponse handler.
• Routes are now constructed with a builder pattern, for example: XPCRoute.named("bedazzle").withMessageType(String.self).withReplyType(Bool.self)

Other additions

• Over 100 tests have been added.

0.2.2

• Renames XPCMachServer.forBlessedExecutable() to XPCMachServer.forBlessedHelperTool() to better align with the naming convention used by Apple in SMJobBless documentation
• Minor documentation improvements