launchd integration with NWListener(Network.framework)

That is a good question. I haven’t yet heard anything about the launchd integration story and I suspect there isn’t one yet. Please file an enhancement request describing this issue, then post the bug number here, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

As always honest answer from eskimo.

Enhancement/Suggestion request ID: 41483517

Thank You

I am also interested in the launchd integration with Network.framework, ID 41483517

Is there any update on this?

Is there any update on this?

No, alas.

btw Fixing this is harder than it you might think because the listening socket support in

launchd

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I don’t see the problem here. If you are integrating with launchd, then the system is doing the listening, not your app. Your app just gets launched with an already-connected socket. If the new framework can be initialed with a connected socket, then you should be fine. The user space requirement will require that your apps are launched as agents rather than daemons, but that shouldn’t be that big a problem.

If the new framework can be initialed with a connected socket, then you should be fine.

It cannot. As I mentioned, Network framework is designed to operate in a world without sockets, and thus it doesn’t not provide a round trip between

NWConnection

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Could you clarify what you mean by "integration"?

Launchd has some extensive socket support for integrating with daemons and agents. But, as eskimo explains, those are not compatible with the Network framework. But launchd has some additional tricks. This is an interesting time as macOS is making its "transition". Many of the custom-built Mac APIs are no longer supported, at least in the sense that new APIs are generally iOS-born and know nothing about the Mac.

But there exists some pre-Mac UNIX APIs that still work and perhaps might not be deprecated. And, even if they are cast aside one day, they might be ultimately more compatible with newer frameworks. Specifically, I am talking about launchd's inetCompatibility key. You could use this to have launchd listen on a socket, make a connection, and start your job with STDIN/STDOUT routed through the connected socket. Then you don't have to deal with sockets at all, just file descriptors. This kind of old-school code is easy to write and easy to test. I think that code structured for this type of architecture would be easily ported to the Network framework should that be a requirement one day. That would help to isolate your app's logic from whatever network implementation Apple is using in the future.

3 years have passed. Just checking to know about the status of interoperation of launchd with NWListener. Anything changed ?

The single think i miss the most from launchd is process crash recovery. Are there any other ways to achieve this with app distributed in within AppStore ? The single thing I could think of is moving payload processing to XPC.

Anything changed?

No )-;

The single think i miss the most from launchd is process crash recovery. Are there any other ways to achieve this with app distributed in within App Store?

That depends on your specific requirements. The best way to deal with this is to put the unreliable code into an XPC Service. The XPC client will receive a ‘connection interrupted’ error if the service crashes while the client is waiting for a response.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"