I am using a URLSessionWebSocketTask. When trying to receive messages while the app is backgrounded, the receive() method fails with an NSError where the domain is NSPOSIXErrorDomain and the code is ECONNABORTED. That behavior is good. However, when this happens, the URLSessionWebSocketTask reports a closeCode of invalid, which is supposed to denote that the connection is still open. However, the connection state property is reporting completed. I feel that the closeCode property should be reporting something like abnormalClosure in this case. Either way, this seems like a bug or the documentation is incorrect.

I have written the Transparent App Proxy and can capture the network flow and send it to my local server. I want to avoid any processing on the traffic outgoing from my server and establish a connection with a remote server, but instead of connecting to the remote server, it again gets captured and sent back to my local server. I am not getting any clue on how to ignore these flows originating from my server. Any pointers, API, or mechanisms that will help me?

I have an iOS app that connects to a server running on macOS by leveraging NWListener & NWBrowser. It also makes use of the peerToPeer functionality / AWDL offered via the Network framework. This works great in the iOS app. Now I would like to add support for Shortcuts / App Intents in general. The NWConnection on its own is also working great in the App Intent, but only if I provide the host/port manually, which means I can't use the peer to peer functionality. If I try to run my NWBrowser in the AppIntent it immediately changes its state to failed with a NoAuth (-65555) error: nw_browser_cancel [B1517] The browser has already been cancelled, ignoring nw_browser_cancel(). nw_browser_fail_on_dns_error_locked [B1518] DNSServiceBrowse failed: NoAuth(-65555) NWClientManager: Browser failed: -65555: NoAuth I haven't found documentation/information on whether NWBrowser should work in an AppIntent extension or not.

Firstly, I'm completely new to native Swift/iOS Development so apologies if this is a simple question that I'm seemingly misunderstanding. I have an app which has the Multicast Networking entitlement and works fine on my own iPhone, however it only has one interface when I list them (en0) The multicast networking, however, fails entirely on another test iPhone but this also appears to have one or more 'ipsecX' interfaces both with the IP 192.0.0.6 - I'm guessing but I wonder if this is related to a connection to Apple Watch as I've noticed two devices that have these additional interfaces, and both of them are connected to Apple Watch (with no VPNs configured) and that's the only thing that differentiates them from my own iPhone. I can reproduce the symptoms on my own iPhone by connecting to a VPN which creates a utunX interface (but in my case disconnecting from the VPN removes this interface and it works as expected) I expect a solution would be to bind my Multicast Group to the WiFi IP but I've tried a few things without success; Setting params.requiredInterfaceType = .wifi Looping through each interface to try and 'find' en0 and bind this way; let queue = DispatchQueue(label: "En0MonitorQueue") monitor.pathUpdateHandler = { [weak self] path in // Find the en0 interface if let en0 = path.availableInterfaces.first(where: { $0.name == "en0" }) { monitor.cancel() // Stop monitoring once found let params = NWParameters.udp params.allowLocalEndpointReuse = true params.requiredInterface = en0 guard let multicast = try? NWMulticastGroup(for: [ .hostPort( host: NWEndpoint.Host(self?.settings.multicastIP ?? "224.224.0.77"), port: NWEndpoint.Port(rawValue: UInt16(self?.settings.multicastPort ?? 23019)) ) ]) else { print("Failed to Start Multicast Group") return } let group = NWConnectionGroup(with: multicast, using: params) // previous multicast stuff is here } else { print("en0 interface not found, waiting...") } } monitor.start(queue: queue) Neither seems to work. I feel I must be missing something simple, because it should not be the case that simply enabling a VPN (or having another interface created by something else) breaks Multicast on en0/WiFi. That said, I also don't want to limit the user to en0 as they may wish to use Ethernet interfaces, but for now it would be good to make it work to confirm this is the problem.

My personal project is a bit further along however after not being able to get this to work in my app I fell back to a much simpler/proven implementation out there. There is this project on GitHub with a guide that implements a barebones app extension with packet tunneling. I figure this can give us common ground. After changing the bundle and group identifiers to all end with -Caleb and or match up I tried running the app. The app extension does not work whatsoever and seemingly for reasons that are similar to my personal project. If I pull up the console and filter for the subsystem (com.github.kean.vpn-client-caleb.vpn-tunnel) I see the following. First you see installd installing it 0x16ba5f000 -[MIUninstaller _uninstallBundleWithIdentity:linkedToChildren:waitForDeletion:uninstallReason:temporaryReference:deleteDataContainers:wasLastReference:error:]: Destroying container com.github.kean.vpn-client-caleb.vpn-tunnel with persona 54D15361-A614-4E0D-931A-0953CDB50CE8 at /private/var/mobile/Containers/Data/PluginKitPlugin/2D0AE485-BB56-4E3E-B59E-48424CD4FD65 And then installd says this (No idea what it means) 0x16b9d3000 -[MIInstallationJournalEntry _refreshUUIDForContainer:withError:]: Data container for com.github.kean.vpn-client-caleb.vpn-tunnel is now at /private/var/mobile/Containers/Data/PluginKitPlugin/2D0AE485-BB56-4E3E-B59E-48424CD4FD65 Concerningly runningboardd seems to immediately try and stop it? Executing termination request for: <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {( "com.github.kean.vpn-client-caleb", "com.github.kean.vpn-client-caleb.vpn-tunnel" )}>> [app<com.github.kean.vpn-client-caleb(54D15361-A614-4E0D-931A-0953CDB50CE8)>:1054] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.github.kean.vpn-client-caleb/54D15361-A614-4E0D-931A-0953CDB50CE8] uuid:963149FA-F712-460B-9B5C-5CE1C309B2FC isPlaceholder:Y reportType:None maxTerminationResistance:Absolute attrs:[ <RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {( "com.github.kean.vpn-client-caleb", "com.github.kean.vpn-client-caleb.vpn-tunnel" )}>> allow:(null)> ]> Then runningboardd leaves a cryptic message Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd>:244] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.github.kean.vpn-client-caleb/54D15361-A614-4E0D-931A-0953CDB50CE8] uuid:963149FA-F712-460B-9B5C-5CE1C309B2FC isPlaceholder:Y" ID:33-244-5222 target:system attributes:[ <RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {( "com.github.kean.vpn-client-caleb", "com.github.kean.vpn-client-caleb.vpn-tunnel" )}>> allow:(null)> ]> And that seems to be all I have to go off of.... If I widen my search a bit I can see backboardd saying things like Connection removed: IOHIDEventSystemConnection uuid:57E97E5D-8CDE-467B-81CA-36A93C7684AD pid:1054 process:vpn-client type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{ HighFrequency = 1; bundleID = "com.github.kean.vpn-client-caleb"; pid = 1054; } state:0x1 events:119 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE Or Removing client connection <BKHIDClientConnection: 0xbf9828cd0; IOHIDEventSystemConnectionRef: 0xbf96d9600; vpid: 1054(vAF7); taskPort: 0x5D777; bundleID: com.github.kean.vpn-client-caleb> for client: IOHIDEventSystemConnection uuid:57E97E5D-8CDE-467B-81CA-36A93C7684AD pid:1054 process:vpn-client type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{ HighFrequency = 1; bundleID = "com.github.kean.vpn-client-caleb"; pid = 1054; } state:0x1 events:119 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE source:HID There's really nothing in the sysdiagnose either. No crash no nothing. I am stumped. Any idea what might be going wrong for me here? Has something about the way app extensions or sandbox rules work changed in later OSes?

Hi, DNS resolution using libresolv (res_nquery) fails in 15.4 when connected to VPN. The same is working fine for 15.3 and lower and this happens for all the domains. The method returns -1 and res->res_h_errno is set to 2. In wireshark we can see that the DNS request is sent and server also returns the response successfully. The same works fine if we use TCP instead of UDP by setting the following option res->options |= RES_USEVC;

Hi I am developing the packet tunnel extension on a SIP enabled device. If I build the app and notarize and install it on the device, it works fine. If I modify, build and execute the App (which contains the system extension), it fails with below error. 102.3.1.4 is production build. And 201.202.0.101 is for XCode build. SystemExtension "&lt;&lt;complete name&gt;&gt;.pkttunnel" request for replacement from 102.3.1.4 to 201.202.0.101 Packet Tunnel SystemExtension "&lt;&lt;complete name&gt;&gt;.pkttunnel" activation request did fail: Error Domain=OSSystemExtensionErrorDomain Code=8 "(null)" If SIP is disabled, it works fine. Is there a way the system extension can be developed even if SIP remains enabled?

I'm running a Node.js server on my MacBook with Apple M4 Pro chip, macOS Sequoia 15.4, and Node.js v23.10.0. The server starts normally on port 5000 and logs show that it's listening correctly. However, when I try to access it via browser or Postman (http://localhost:5000/api/...), I get a 403 Forbidden error. After checking with lsof -i :5000, I noticed that the ControlCenter process is listening on port 5000 under the name commplex-main. Interestingly, this doesn't happen on M3 Pro machines. On those devices, Node.js runs fine on port 5000 and can be accessed from Postman and browsers. Is port 5000 now internally reserved by macOS or used by some system-level service in Sequoia or Apple Silicon (M4 Pro)? Should I avoid using this port going forward? Any official clarification would be appreciated.

ios構成プロファイルの制限のallowCloudPrivateRelayのプライベートリレーの制御とRelayペイロードの機能は関係がありますか？ それとも別々の機能でしょうか？ ↓ s there a relationship between the private relay control in the iOS configuration profile restriction allowCloudPrivateRelay and the functionality of the Relay payload? Or are they separate features?

Hi~ I implemented network filtering on iOS using NEFilterControlProvider and NEFilterDataProvider. However, I found that their usage is restricted when distributing in the App Store. Does ADEP-based distribution allow the use of NEFilterControlProvider and NEFilterDataProvider? In TN3134, it states that NEPacketTunnelProvider requires MDM. Should I assume that NEFilterControlProvider and NEFilterDataProvider also require MDM in the same way? thanks.

Are the network relays introduced in 2023 and https://developer.apple.com/videos/play/wwdc2023/10002/ the same thing as the Private Relay introduced in 2021? https://developer.apple.com/videos/play/wwdc2021/10096/ We are considering verifying the relay function, but we are not sure whether they are the same function or different functions. https://developer.apple.com/documentation/devicemanagement/relay?language=objc

Hi~ I implemented network filtering on iOS using NEFilterControlProvider and NEFilterDataProvider. However, I found that their usage is restricted when distributing through the App Store. Does ADEP-based distribution allow the use of NEFilterControlProvider and NEFilterDataProvider? In TN3134, it states that NEPacketTunnelProvider requires MDM. Should I assume that NEFilterControlProvider and NEFilterDataProvider also require MDM in the same way? Thanks

Every now and again folks notice that Network framework seems to create an unexpected number of connections on the wire. This post explains why that happens and what you should do about it. If you have questions or comments, put them in a new thread here on the forums. Use the App & System Services > Networking topic area and the Network tag. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Understanding Also-Ran Connections Network framework implements the Happy Eyeballs algorithm. That might create more on-the-wire connections than you expect. There are two common places where folks notice this: When looking at a packet trace When implementing a listener Imagine that you’ve implemented a TCP server using NWListener and you connect to it from a client using NWConnection. In many situations there are multiple network paths between the client and the server. For example, on a local network there’s always at least two paths: the link-local IPv6 path and either an infrastructure IPv4 path or the link-local IPv4 path. When you start your NWConnection, Network framework’s Happy Eyeballs algorithm might [1] start a TCP connection for each of these paths. It then races those connections. The one that connects first is the ‘winner’, and Network framework uses that connection for your traffic. Once it has a winner, the other connections, the also-ran connections, are redundant, and Network framework just closes them. You can observe this behaviour on the client side by looking in the system log. Many Network framework log entries (subsystem com.apple.network) contain a connection identifier. For example C8 is the eighth connection started by this process. Each connection may have child connections (C8.1, C8.2, …) and grandchild connections (C8.1.1, C8.1.2, …), and so on. You’ll see state transitions for these child connections occurring in parallel. For example, the following log entries show that C8 is racing the connection of two grandchild connections, C8.1.1 and C8.1.2: type: debug time: 12:22:26.825331+0100 process: TestAlsoRanConnections subsystem: com.apple.network category: connection message: nw_socket_connect [C8.1.1:1] Calling connectx(…) type: debug time: 12:22:26.964150+0100 process: TestAlsoRanConnections subsystem: com.apple.network category: connection message: nw_socket_connect [C8.1.2:1] Calling connectx(…) Note For more information about accessing the system log, see Your Friend the System Log. You also see this on the server side, but in this case each connection is visible to your code. When you connect from the client, Network framework calls your listener’s new connection handler with multiple connections. One of those is the winning connection and you’ll receive traffic on it. The others are the also-ran connections, and they close promptly. IMPORTANT Depending on network conditions there may be no also-ran connections. Or there may be lots of them. If you want to test the also-ran connection case, use Network Link Conditioner to add a bunch of delay to your packets. You don’t need to write special code to handle also-ran connections. From the perspective of your listener, these are simply connections that open and then immediately close. There’s no difference between an also-ran connection and, say, a connection from a client that immediately crashes. Or a connection generated by someone doing a port scan. Your server must be resilient to such things. However, the presence of these also-ran connections can be confusing, especially if you’re just getting started with Network framework, and hence this post. [1] This is “might” because the exact behaviour depends on network conditions. More on that below.

I am trying to connect to an accessory's WiFi network using the below code and I always see the message "connection succeded" even if I provide an incorrect passphrase. I tried with different accessories and see the same behavior. hotspotConfigurationManager.joinAccessoryHotspot(accessory, passphrase: passphrase) { error in if let error = error { print("connection failed: \(error.localizedDescription)") } else { print("connection succeeded") } }

你好，是这样的，目的我使用的是mac mini进行软件测试，我目前测试的软件会通过本地回环地址127.0.0.1进行数据传输，这种数据传输不是网络请求，所以用网络抓包的手段，没法测试。所以，我目前的想法是修改您macOS的本地回环地址优先级，定向到我自己的代理服务器，进行数据测试和请求检测。我对liunx系统的作比较了解，但是对于macos上面这方面设置的修改不太清楚。 希望您可以解答！

Hi, We're in the process of following Apple’s guidance on transitioning away from Packet Filter (pf) and migrating to a Network Extension-based solution that functions as a firewall. During this transition, we've encountered several limitations with the current Content Filter API and wanted to share our findings. Our VPN client relies on firewall functionality to enforce strict adherence to split tunneling rules defined via the routing table. This ensures that no traffic leaks outside the VPN tunnel, which is critical for our users for a variety of reasons. To enforce this, our product currently uses interface-scoped rules to block all non-VPN traffic outside the tunnel. Replicating this behavior with the Content Filter API (NEFilterDataProvider) appears to be infeasible today. The key limitation we've encountered is that the current Content Filter API does not expose information about the network interface associated with a flow. As a workaround, we considered using the flow’s local endpoint IP to infer the interface, but this data is not available until after returning a verdict to peek into the flow’s data—at which point the connection has already been established. This can result in connection metadata leaking outside the tunnel, which may contain sensitive information depending on the connection. What is the recommended approach for this use case? NEFilterPacketProvider? This may work, but it has a negative impact on network performance. Using a Packet Tunnel Provider and purely relying on enforceRoutes? Would this indeed ensure that no traffic can leak by targeting a specific interface or by using a second VPN extension? And more broadly—especially if no such approach is currently feasible with the existing APIs—we're interpreting TN3165 as a signal that pf should be considered deprecated and may not be available in the next major macOS release. Is that a reasonable interpretation?

Hello, I am in a very similar situation as described in the thread: https://developer.apple.com/forums/thread/655183 Context: I am working on an app that receives data from a hardware device through its Wifi network, and the hardware is not connected to the internet. Now, I would need to call some API while still connected to hardware so I would need to use the cellular data. As mentioned on the thread, I can achieve this via Network framework, using the requiredInterfaceType property. But Is there any other way I can achieve this? I can also do some suggestion on the hardware if that's helpful. Thank you!

Hi folks, I'm building an iOS companion app to a local hosted server app (hosted on 0.0.0.0). The MacOS app locally connects to this server hosted, and I took the approach of advertising the server using a Daemon and BonjourwithTXT(for port) and then net service to resolve a local name. Unfortunately if there's not enough time given after the iPhone/iPad is plugged in (usb or ethernet), the app will cycle through attempts and disconnects many times before connecting and I'm trying to find a way to only connect when a viable en interface is available. I've run into a weird thing in which the en interface only becomes seen on the NWMonitor after multiple connection attempts have been made and failed. If I screen for en before connecting it simply never appears. Is there any way to handle this such that my app can intelligently wait for an en connection before trying to connect? Attaching my code although I have tried a few other setups but none has been perfect. func startMonitoringAndBrowse() { DebugLogger.shared.append("Starting Bonjour + Ethernet monitoring") if !browserStarted { let params = NWParameters.tcp params.includePeerToPeer = false params.requiredInterfaceType = .wiredEthernet browser = NWBrowser(for: .bonjourWithTXTRecord(type: "_mytcpapp._tcp", domain: nil), using: params) browser?.stateUpdateHandler = { state in if case .ready = state { DebugLogger.shared.append("Bonjour browser ready.") } } browser?.browseResultsChangedHandler = { results, _ in self.handleBrowseResults(results) } browser?.start(queue: .main) browserStarted = true } // Start monitoring for wired ethernet monitor = NWPathMonitor() monitor?.pathUpdateHandler = { path in let hasEthernet = path.availableInterfaces.contains { $0.type == .wiredEthernet } let ethernetInUse = path.usesInterfaceType(.wiredEthernet) DebugLogger.shared.append(""" NWPathMonitor: - Status: \(path.status) - Interfaces: \(path.availableInterfaces.map { "\($0.name)[\($0.type)]" }.joined(separator: ", ")) - Wired Ethernet: \(hasEthernet), In Use: \(ethernetInUse) """) self.tryToConnectIfReady() self.stopMonitoring() } monitor?.start(queue: monitorQueue) } // MARK: - Internal Logic private func handleBrowseResults(_ results: Set&lt;NWBrowser.Result&gt;) { guard !self.isResolving, !self.hasResolvedService else { return } for result in results { guard case let .bonjour(txtRecord) = result.metadata, let portString = txtRecord["actual_port"], let actualPort = Int(portString), case let .service(name, type, domain, _) = result.endpoint else { continue } DebugLogger.shared.append("Bonjour result — port: \(actualPort)") self.resolvedPort = actualPort self.isResolving = true self.resolveWithNetService(name: name, type: type, domain: domain) break } } private func resolveWithNetService(name: String, type: String, domain: String) { let netService = NetService(domain: domain, type: type, name: name) netService.delegate = self netService.includesPeerToPeer = false netService.resolve(withTimeout: 5.0) resolvingNetService = netService DebugLogger.shared.append("Resolving NetService: \(name).\(type)\(domain)") } private func tryToConnectIfReady() { guard hasResolvedService, let host = resolvedHost, let port = resolvedPort else { return } DebugLogger.shared.append("Attempting to connect: \(host):\(port)") discoveredIP = host discoveredPort = port connectionPublisher.send(.connecting(ip: host, port: port)) stopBrowsing() socketManager.connectToServer(ip: host, port: port) hasResolvedService = false } } // MARK: - NetServiceDelegate extension BonjourManager: NetServiceDelegate { func netServiceDidResolveAddress(_ sender: NetService) { guard let hostname = sender.hostName else { DebugLogger.shared.append("Resolved service with no hostname") return } DebugLogger.shared.append("Resolved NetService hostname: \(hostname)") resolvedHost = hostname isResolving = false hasResolvedService = true tryToConnectIfReady() } func netService(_ sender: NetService, didNotResolve errorDict: [String : NSNumber]) { DebugLogger.shared.append("NetService failed to resolve: \(errorDict)") } }

CarPlay woes. I think it's unacceptable that it silently kills an ongoing WiFi connection that has been established using ASAccessoryKit and NEHotspotHelper which is in active use. This is responsible for angry clients because their processes break a lot when they are in reach of the connected car. (And yes, they have to be in the reach of the car, because it is a diagnostic/maintenance app for cars…) Do I really need to ask my clients to unpair from CarPlay before using our app or is there another way?

Here's what the documentation says https://developer.apple.com/documentation/networkextension/maintaining-a-reliable-network-connection Confirm that your NEAppPushProvider implementation doesn’t create a retain cycle with itself. After you call the completionHandler that the system passes to stop(with:completionHandler:), the Network Extension framework releases your NEAppPushProvider instance. This instance typically deallocates from memory when released, but if the instance has a retain cycle with itself, it fails to deallocate and wastes memory. Failure to deallocate can also cause the system to have two or more instances of your push provider, leading to inconsistent behavior. Use Instruments or add a logging statement to deinit to verify that your NEAppPushProvider deinitializes when expected. I observe that when I turn off the wifi, the AppPushProvider subclass fully deinitializes. But when I call removeFromPreferences on the NEAppPushManager from the app, it calls stop() on my AppPushProvider subclass, but it does not initialize. Should I be alarmed by this behavior? Will this cause a memory leak? Will this cause multiple Extension/AppPushProviders to be operating concurrently? For testing, I've removed everything except for logs and some singleton calls. No closures capturing self, and no strong references of self being passed anywhere. I am also not using the debugger, and am using the console to debug.