NWPathMonitor appears to retain itself (or is retained by some internal infrastructure) once it has been started until cancelled. This seems like it can lead to memory leaks if the references to to the monitor are dropped. Is this behavior documented anywhere? func nwpm_self_retain() { weak var weakRef: NWPathMonitor? autoreleasepool { let monitor: NWPathMonitor = NWPathMonitor() weakRef = monitor monitor.start(queue: .main) // monitor.cancel() // assertion fails unless this is called } assert(weakRef == nil) } nwpm_self_retain()

I’m using an NETransparentProxyProvider where I add UDP-53 rules to intercept DNS queries from a private application. These queries are resolved locally on the endpoint by returning a custom DNS response. Example Rules look like this: NENetworkRule(destinationHost: NWHostEndpoint(hostname: "mypaapp.com", port: 53),protocol:.UDP) This works as expected through browser and ping. handleNewUDPFlow/handleNewFlow with NEAppProxyUDPFlow gets called where custom dns response get written. Using nslookup mypaapp.com doesn't works. Why does this behaves differently for nslookup?

System Information in macOS from 26.0 to 26.2 RC no longer provides Wi-Fi SSIDs; instead, it displays "< redacted> " for every SSID on my two MacBooks. This issue has been fixed in macOS 26.1 beta and macOS 26.2 beta, but it returns in the RC and the Final Release versions. Is it an expected behaviour or a bug in the Release Candidate? MacBook Air 2025: MacBook Pro 2021:

Hello Everyone, I’m working on a project that involves multicast communication between processes running on different devices within the same network. For all my Apple devices (macOS, iOS, etc.), I am using NWConnectionGroup, which listens on a multicast address "XX.XX.XX.XX" and a specific multicast port. The issue occurs when a requestor (such as a non-Apple process) sends a multicast request, and the server, which is a process running on an Apple device using NWConnectionGroup (the responder), attempts to reply. The problem is that the response is sent from a different ephemeral port rather than the port on which the multicast request was received. If the client is behind a firewall that blocks unsolicited traffic, the firewall only allows incoming packets on the same multicast port used for the initial request. Since the multicast response is sent from a different ephemeral port, the firewall blocks this response, preventing the requestor from receiving it. Questions: Is there a recommended approach within the NWConnectionGroup or Network.framework to ensure that responses to multicast requests are sent from the same port used for the request? Are there any best practices for handling multicast responses in scenarios where the requestor is behind a restrictive firewall? Any insights or suggestions on how to account for this behavior and ensure reliable multicast communication in such environments would be greatly appreciated. Thanks, Harshal

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") } }

Description: We are investigating an issue where running a specific e-commerce iOS app inside the Xcode Simulator intermittently disrupts the Mac’s network connectivity. When the app is launched in the Simulator, our NETransparentProxyProvider and NEFilterDataProvider extensions occasionally stop receiving traffic correctly, and shortly afterward the entire macOS DNS resolution fails. Once this happens, all apps on the Mac lose internet access until mac is restarted. Disabling extensions also fixing the issue. This issue only appears when the app runs in the Xcode Simulator. I would like to confirm: Is it possible for traffic patterns or network behavior inside the Simulator to interfere with system-level Network Extension providers on macOS? Are there known limitations or conflicts between the Simulator’s virtual networking interfaces and Network Extensions? Any recommended debugging steps or best practices to isolate this behavior? Any guidance, known issues, or suggestions would be appreciated.

I want to configure one aspect of my networking configuration (the QUIC keepalive interval). This only seems to be configurable via Network.framework’s nw_quic_set_keepalive_interval. Is there any way to apply this to a URLSession? Or do I need to implement the whole connection management myself using Network.framework?

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?

Hey everyone, I’m developing an app for visionOS where I need to display the Apple Vision Pro’s current IP address. For this I’m using the following code, which works for iOS, macOS, and visionOS in the simulator. Only on a real Apple Vision Pro it’s unable to extract an IP. Could it be that visionOS currently doesn’t allow this? Have any of you had the same experience and found a workaround? var address: String = "no ip" var ifaddr: UnsafeMutablePointer<ifaddrs>? = nil if getifaddrs(&ifaddr) == 0 { var ptr = ifaddr while ptr != nil { defer { ptr = ptr?.pointee.ifa_next } let interface = ptr?.pointee let addrFamily = interface?.ifa_addr.pointee.sa_family if addrFamily == UInt8(AF_INET) { if let name: Optional<String> = String(cString: (interface?.ifa_name)!), name == "en0" { var hostname = [CChar](repeating: 0, count: Int(NI_MAXHOST)) getnameinfo(interface?.ifa_addr, socklen_t((interface?.ifa_addr.pointee.sa_len)!), &hostname, socklen_t(hostname.count), nil, socklen_t(0), NI_NUMERICHOST) address = String(cString: hostname) } } } freeifaddrs(ifaddr) } return address } Thanks in advance for any insights or tips! Best Regards, David

Hi, We are trying to use Apple Security API for KeyChain Services. Using the common App Group : Specifying the common app group in the "kSecAttrAccessGroup" field of the KeyChain query, allowed us to have a shared keychains for different apps (targets) in the app group, but this did not work for extensions. Enabling the KeyChain Sharing capability : We enabled the KeyChain Sharing Ability in the extensions and the app target as well, giving a common KeyChain Access group. Specifying this in the kSecAttrAccessGroup field also did not work. This was done in XCode as we were unable to locate it in the Developer portal in Indentifiers. We tried specifying "$AppIdentifier.KeyChainSharingGroup" in the kSecAttrAccessGroup field , but this did not work as well The error code which we get in all these 3 cases when trying to access the Keychain from the extension is error code 25291 (errSecNotAvailable). The Documentation says this error comes when "No Trust Results are available" and printing the error in xcode using the status says "No keychain is available. The online Documentation says that it is possible to share keychain with extensions, but by far we are unable to do it with the methods suggested. Do we need any special entitlement for this or is there something we are missing while using these APIs? We really appreciate any and all help in solving this issue! Thank you

We’re implementing VPN application using the WireGuard protocol and aiming to support both split-tunnel and per-app VPN configurations. Each mode works correctly on its own: per-app VPN functions well when configured with a full tunnel and split-tunnel works as expected when per-app is disabled. However, combining both configurations leads to issues. Specifically, the routing table is not set up properly, resulting in traffic that should not be routed through the tunnel is routed through the tunnel. Detailed description: Through our backend, we are pushing these two plist files to the iPad one after the other: VPN config with allowed IPs 1.1.1.1/32 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version="1.0"> <dict> <key>PayloadUUID</key> <string>3fd861df-c917-4716-97e5-f5e96452436a</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadOrganization</key> <string>someorganization</string> <key>PayloadIdentifier</key> <string>config.11ff5059-369f-4a71-afea-d5fdbfa99c91</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadDisplayName</key> <string> test</string> <key>PayloadDescription</key> <string>(Version 13) </string> <key>PayloadRemovalDisallowed</key> <true /> <key>PayloadContent</key> <array> <dict> <key>VPN</key> <dict> <key>AuthenticationMethod</key> <string>Password</string> <key>ProviderType</key> <string>packet-tunnel</string> <key>OnDemandUserOverrideDisabled</key> <integer>1</integer> <key>RemoteAddress</key> <string>172.17.28.1:51820</string> <key>OnDemandEnabled</key> <integer>1</integer> <key>OnDemandRules</key> <array> <dict> <key>Action</key> <string>Connect</string> </dict> </array> <key>ProviderBundleIdentifier</key> <string>some.bundle.id.network-extension</string> </dict> <key>VPNSubType</key> <string>some.bundle.id</string> <key>VPNType</key> <string>VPN</string> <key>VPNUUID</key> <string>d2773557-b535-414f-968a-5447d9c02d52</string> <key>OnDemandMatchAppEnabled</key> <true /> <key>VendorConfig</key> <dict> <key>VPNConfig</key> <string> Some custom configuration here </string> </dict> <key>UserDefinedName</key> <string>TestVPNServerrra</string> <key>PayloadType</key> <string>com.apple.vpn.managed.applayer</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>vpn.5e6b56be-a4bb-41a5-949e-4e8195a83f0f</string> <key>PayloadUUID</key> <string>9bebe6e2-dbef-4849-a1fb-3cca37221116</string> <key>PayloadDisplayName</key> <string>Vpn</string> <key>PayloadDescription</key> <string>Configures VPN settings</string> <key>PayloadOrganization</key> <string>someorganization</string> </dict> </array> </dict> </plist> Command to set up per-app with Chrome browser <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version="1.0"> <dict> <key>Command</key> <dict> <key>Settings</key> <array> <dict> <key>Identifier</key> <string>com.google.chrome.ios</string> <key>Attributes</key> <dict> <key>VPNUUID</key> <string>d2773557-b535-414f-968a-5447d9c02d52</string> <key>TapToPayScreenLock</key> <false /> <key>Removable</key> <true /> </dict> <key>Item</key> <string>ApplicationAttributes</string> </dict> </array> <key>RequestType</key> <string>Settings</string> </dict> <key>CommandUUID</key> <string>17ce3e19-35ef-4dbc-83d9-4ca2735ac430</string> </dict> </plist> From the log we see that our VPN application set up allowed IP 1.1.1.1 via NEIPv4Settings.includedRoutes but system routing all of the Chrome browser traffic through our application. Is this expected Apple iOS behavior, or are we misconfiguring the profiles?

For a long time our app had this creation of a URLRequest: var urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalAndRemoteCacheData, timeoutInterval: timeout) But since iOS 26 was released we started to get crashes in this call. It is created on a background thread. Thread 10 Crashed: 0 libsystem_malloc.dylib 0x00000001920e309c _xzm_xzone_malloc_freelist_outlined + 864 (xzone_malloc.c:1869) 1 libswiftCore.dylib 0x0000000184030360 swift::swift_slowAllocTyped(unsigned long, unsigned long, unsigned long long) + 56 (Heap.cpp:110) 2 libswiftCore.dylib 0x0000000184030754 swift_allocObject + 136 (HeapObject.cpp:245) 3 Foundation 0x00000001845dab9c specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 120 4 Foundation 0x00000001845daa58 specialized static _SwiftURL._makeCFURL(from:baseURL:) + 2288 (URL_Swift.swift:1192) 5 Foundation 0x00000001845da118 closure #1 in _SwiftURL._nsurl.getter + 112 (URL_Swift.swift:64) 6 Foundation 0x00000001845da160 partial apply for closure #1 in _SwiftURL._nsurl.getter + 20 (<compiler-generated>:0) 7 Foundation 0x00000001845da0a0 closure #1 in _SwiftURL._nsurl.getterpartial apply + 16 8 Foundation 0x00000001845d9a6c protocol witness for _URLProtocol.bridgeToNSURL() in conformance _SwiftURL + 196 (<compiler-generated>:974) 9 Foundation 0x000000018470f31c URLRequest.init(url:cachePolicy:timeoutInterval:) + 92 (URLRequest.swift:44)# Live For Studio Any idea if this crash is caused by our code or if it is a known problem in iOS 26? I have attached one of the crash reports from Xcode: 2025-10-08_10-13-45.1128_+0200-8acf1536892bf0576f963e1534419cd29e6e10b8.crash

If the includeAllNetworks flag to true, we cannot update our app via Xcode, TestFlight or the AppStore. In the AppStore and TestFlight cases, it seems that the packet tunnel process is stopped before the new app is downloaded - once the packet tunnel process is stopped, it can’t be started again via Settings/VPN profiles, nor can it be started via the app.

We have a content filter system extension as part of our macOS app. The filter normally works correctly, activation and deactivation works as expected but occasionally we see an issue when the content filter is activated. When this issues occurs, the filter activation appears to behave correctly, no errors are reported. Using "systemextensionsctl list" we see the filter is labelled as "[activated enabled]". However, the installed content filter executable does not run. We have seen this issue on macOS 15.3 and later and on the beta macOS 26.1 RC. It happens only occasionally but when it does there is no indication as to why the executable is not running. There are no crash logs or errors in launchd logs. Both rebooting and deactivating/activating the filter do not resolve the issue. The only fix appears to be completely uninstalling the app (including content filter) and reinstalling. I have raised a FB ticket, FB20866080. Does anyone have any idea what could cause this?

In our system, when a user enables a mobile hotspot and the system connects to it, the system attempts to verify WIFI availability by sending an HTTP GET request to http://captive.apple.com. Normally, the server returns: HTTP Status: 200 (OK) Content-Type: text/html This has always been used as a sign of normal connectivity. Issue: Since last Friday, the server sometimes responds with: Content-Type: application/octet-stream When this occurs, our system determines that the network is unavailable and displays a connection warning (a “!” icon). Question: Has Apple recently made any backend or CDN configuration changes to captive.apple.com that could affect the response type? Any advice how can we solve this problem? Thanks!

We have an iPad application that utilizes Multipeer Connectivity to enable local communication between devices running a copy of our app. Until recently, we were able to test this functionality in the Xcode simulator without any issues. We could easily set up multiple simulators and have them all communicate with each other. However, recently, either due to an upgrade to Xcode or MacOS, this functionality ceased working in the simulator. Surprisingly, it still functions perfectly on physical devices. If we reboot the development computer and launch the simulator immediately after the reboot (without building and sending from Xcode, but running the existing code on the device), the issue resolves. However, the moment we generate a new build and send it to the simulator from Xcode, the multipeer functionality stops working again in the simulator. The simulators won’t reconnect until a reboot of the physical Mac hardware hosting the simulator. We’ve tried the usual troubleshooting steps, such as downgrading Xcode, deleting simulators and recreating them, cleaning the build folder, and deleting derived data, but unfortunately, none of these solutions have worked. The next step is to attempt to use a previous version of MacOS (15.3) and see if that helps, but I’d prefer to avoid this if possible. Does anyone have any obvious suggestions or troubleshooting steps that might help us identify the cause of this issue?

I'm working with Apple's SimpleURLFilter sample project and consistently encountering an error when trying to implement the URL filter. Here are the details: Setup: Downloaded the official SimpleURLFilter sample project from Apple Set the developer team for both targets (main app and extension) Built and ran the PIR server on my laptop using Docker as per the sample instructions Built the iOS project on my iPhone running iOS 26.0.1 Server is accessible at my Mac's IP address on port 8080 Configuration: PIR Server URL: http://[my-mac-ip]:8080 Authentication Token: AAAA (as specified in service-config.json) Privacy Pass Issuer URL: (left empty) Fail Closed: enabled Code Changes: The only modifications I made were: Updated bundle identifiers to include my team identifier Updated PIR server's service-config.json to match: com.example.apple-samplecode.SimpleURLFilter[TEAM_ID].url.filtering Modified URLFilterControlProvider.swift: Added existingPrefilterTag: String? parameter to fetchPrefilter() method Added tag: "bloom_filter" parameter to NEURLFilterPrefilter initializer Issue: After configuring the filter and entering my passcode in Settings, I consistently see: Received filter status change: <FilterStatus: 'starting'> Received filter status change: <FilterStatus: 'stopped' errorMessage: 'The operation couldn't be completed. (NetworkExtension.NEURLFilterManager.Error error 9.)'> Questions: What does NEURLFilterManager.Error error 9 specifically indicate? Could the URLFilterControlProvider modifications be causing this issue? Are there debugging steps to get more detailed error information? Any guidance would be appreciated!

I'm trying to implement support for grpc http/2 streams using NSURLSession. Almost everything works fine, data streaming is flowing from the server and from the client and responses are coming through my NSURLSessionTaskDelegate. I'm getting the responses and streamed data through the appropriate handlers (didReceiveData, didReceiveResponse). However, I cannot seem to find an API to access the trailers expected by grpc. Specifically, the expected trailer "grpc-status: 0" is in the response, but after the data. Is there no way to gain access to trailers in the NSURLSession Framework?

Simulator: iPhone 16 pro (iOS 26) Minimum Deployments: iOS 16.0+, not iOS 17. Here is the demo: import SwiftUI import NetworkExtension struct ContentView: View { private var monitor = NWPathMonitor() var body: some View { VStack { Text("Hello, world!") } .task { let _ = URLSession.shared } } }

Hi, I've encountered a strange behavior in the DNS Proxy Provider extension. Our app implements both DNS Proxy Provider and Content Filter Providers extensions, configured via MDM. When the app is uninstalled, the behavior of the providers differs: For Content Filter Providers (both Filter Control and Filter Data Providers), the providers stop as expected with the stop reason: /** @const NEProviderStopReasonProviderDisabled The provider was disabled. */ case providerDisabled = 5 However, for the DNS Proxy Provider, the provider remains in the "Running" state, even though there is no app available to match the provider's bundle ID in the uploaded configuration profile. When the app is reinstalled: The Content Filter Providers start as expected. The DNS Proxy Provider stops with the stop reason: /** @const NEProviderStopReasonAppUpdate The NEProvider is being updated */ @available(iOS 13.0, *) case appUpdate = 16 At this point, the DNS Proxy Provider remains in an 'Invalid' state. Reinstalling the app a second time seems to resolve the issue, with both the DNS Proxy Provider and Content Filter Providers starting as expected. This issue seems to occur only if some time has passed after the DNS Proxy Provider entered the 'Running' state. It appears as though the system retains a stale configuration for the DNS Proxy Provider, even after the app has been removed. Steps to reproduce: Install the app and configure both DNS Proxy Provider and Content Filter Providers using MDM. Uninstall the app. Content Filter Providers are stopped as expected (NEProviderStopReason.providerDisabled = 5). DNS Proxy Provider remains in the 'Running' state. Reinstall the app. Content Filter Providers start as expected. DNS Proxy Provider stops with NEProviderStopReason.appUpdate (16) and remains 'Invalid'. Reinstall the app again. DNS Proxy Provider now starts as expected. This behavior raises concerns about how the system manages the lifecycle of DNS Proxy Provider, because DNS Proxy Provider is matched with provider bundle id in .mobileconfig file. Has anyone else experienced this issue? Any suggestions on how to address or debug this behavior would be highly appreciated. Thank you!