Feedback ticket for the documentation: FB17345983                  But as a third-party developer I’m not sure that’s a significant restriction. If you’re building your own daemon or agent, you can bake spawn constraint into its code signature. This would protect the daemon or agent from being launched by an unexpected executable. BUT this would not prevent the launchd plist from starting an executable at the path pointed by the plist but which is not the expected executable.

It can be reproduced on macOS 15.4.

Is DocC also responsible for the gotoNextPane and gotoPreviousPane methods of InstallerPane (InstallerPlugins framework) being weirdly defined as readonly properties? Already filed another feedback ticket about that one.

IMHO, it matters considering that: this is the Objective-C flavor of the documentation. the prototype of the method returns a BOOL. the title of the chapter is "Return value". The type is a BOOL. for more than 30 years, it has been YES or NO (e.g. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/Foundation/Classes/NSDictionaryClassCluster.htmld/index.html). It's a documentation so I don't see how the fact that TRUE, true, YES or 1 are all the same matters.

I removed the filter. Outbound UDP flows are all seen. The inbound UDP flow in the test scenario is never seen. Some other inbound UDP flows are seen. Here's the modified source I used for the FilterDataProvider: // MARK: Properties // The TCP port which the filter is interested in. // MARK: NEFilterDataProvider override func startFilter(completionHandler: @escaping (Error?) -> Void) { completionHandler(nil) } override func stopFilter(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) { completionHandler() } override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint else { os_log("Early return") return .allow() } os_log("Got a new flow (socket protocol: %d direction: %d) with remote endpoint %{public}@", socketFlow.socketProtocol, socketFlow.direction.rawValue, remoteEndpoint) os_log("Got a new flow with remote port %{public}@", remoteEndpoint.port) return .allow() } }

I'm able to reproduce the problem with the SimpleFirewall example. When following the procedure described in the ticket: UDP traffic is never seen. TCP traffic is seen. As far as I can tell, the issue is with incoming UDP traffic. I tried with a binary where the Apple signature was removed, I tried different ports.

It's actually more what is not seen. TCP traffic is seen by the handleNewFlow method/function. UDP traffic is not. Ref. https://feedbackassistant.apple.com/feedback/16846115

OK. I will file a feedback assistant ticket to at least get the minimum one line sentence in the online documentation. BTW, the Comment feature (popup window icon) is broken at the time of this writing. Filing another feedback assistant ticket about this.

OK but then is it expected for a NEFilterSocketFlow to have the following properties: direction = outbound protocol = 255 (IPPROTO_RAW) family = 2 (PF_INET) type = 3 (SOCK_RAW) localEndpoint = 0.0.0.0:0 remoteEndpoint = not.a.local.ip:0 ?