1 Reply
      Latest reply on Dec 20, 2019 12:34 AM by eskimo
      devfunshark Level 1 Level 1 (0 points)

        I want to use the XPC technology simply to launch an app on macOS. I do not need any interprocess communication, or any of the other feature of XPC.


        The only documents that I can find on the internet show a complex structure, with code for the XPC service, separate code to launch the XPC

        service via a script, and app code to communicate with the service.


        In other words, I only want something that does the equivalent of this:

        NSWorkspace.shared.openApplication(at: path, configuration: configuration, completionHandler: nil)

        but with XPC. So I would need something along the lines of:

        let listener = NSXPCListener.service("/path/to/my_app.app")

        Obviously, the service method does not take an argument that would be an executable path, so this does not work.


        How can I do that ?


        PS: to explain the motivation, launching an XPC service will preserve sandbox restriction form the launching app, whereas launching the app directly via NSWorkspace.shared.openApplication will not preserve sandbox restrictions (because the spawned app does not have "com.apple.security.inherit" as entitlement).

        • Re: Very Simple XPC
          eskimo Apple Staff Apple Staff (12,705 points)

          to explain the motivation

          Can you explain more of the motivation here?  What type of product are you shipping?  An app?  Or something else?  What’s this secondary process you’re trying to launch?  Something you created?  Or some other code that just happens to already exist on the system?  And why does this code need to run outside of the sandbox?

          The reason I have all of these questions is that the questions you’ve posed above assume a structure that is far removed from how macOS actually works.  It misses a key component of the launchd / XPC architecture, namely that jobs are launched on demand and that XPC, as an IPC mechanism, creates that demand.  One does not simply start a launchd job, but rather launchd knows about all the communication endpoints (of which XPC services are just one type) and it’s the attempt to communicate with that endpoint that causes launchd to start the process responsible for that endpoint.  In short, XPC without the C makes no sense.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

          ps DTS is closed 21 Dec through 1 Jan.