Is Apple's Wi-Fi Aware certified by the Wi-Fi Alliance? Is there any non-compliance of Apple's Wi-Fi Aware with the Wi-Fi Alliance standards? Does Apple have a roadmap to switch AWDL to Wi-Fi Aware? Does Apple have plans to adopt Wi-Fi Aware in Mac computers?

I’m trying to use the TLS Session Resumption feature in TLS 1.2 and 1.3. I first tested this on iOS, but it didn’t work as expected. To investigate via packet capture, I ran the same code on macOS and saw the same issue. Using URLSession to establish a WebSocket connection, I captured packets in Wireshark to check if Session Resumption was working. The behavior differed from what I expected: 1st TLS handshake – Client Hello does not contain the session_ticket extension (required for session resumption per the TLS spec). 2nd TLS handshake – Client Hello does not contain a pre_shared_key. Test apps: https://github.com/sf-jed-kyung/tls-session-resumption-test Test environment: Xcode 16.3, macOS 15.6, OpenSSL 3.5.1 This repo contains: tls-urlsession-macos – WebSocket via URLSession (shows missing extensions). tls-openssl-macos – Manual TLS handshake via OpenSSL (shows both session_ticket and pre_shared_key). To run this, adjust Header Search Paths and Library Search Paths for your local OpenSSL install. URLSession – 1st Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 508 Version: TLS 1.2 (0x0303) Random: 0502b10cf04223658... Session ID Length: 32 Session ID: e3b276b14f2deaced... Cipher Suites Length: 42 Cipher Suites (21 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 393 ... Extension: server_name (len=26) name=echo.websocket.events Extension: extended_master_secret (len=0) Extension: renegotiation_info (len=1) Extension: supported_groups (len=12) Extension: ec_point_formats (len=2) Extension: application_layer_protocol_negotiation (len=11) Extension: status_request (len=5) Extension: signature_algorithms (len=22) Extension: signed_certificate_timestamp (len=0) Extension: key_share (len=43) x25519 Extension: psk_key_exchange_modes (len=2) Extension: supported_versions (len=7) TLS 1.3, TLS 1.2 Extension: compress_certificate (len=3) ... URLSession – 2nd Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 508 Version: TLS 1.2 (0x0303) Random: 1e485f35ad66c8598... Session ID Length: 32 Session ID: 99d02000c7ed403a5... Cipher Suites Length: 42 Cipher Suites (21 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 393 ... Extension: server_name (len=26) name=echo.websocket.events Extension: extended_master_secret (len=0) Extension: renegotiation_info (len=1) Extension: supported_groups (len=12) Extension: ec_point_formats (len=2) Extension: application_layer_protocol_negotiation (len=11) Extension: status_request (len=5) Extension: signature_algorithms (len=22) Extension: signed_certificate_timestamp (len=0) Extension: key_share (len=43) x25519 Extension: psk_key_exchange_modes (len=2) Extension: supported_versions (len=7) TLS 1.3, TLS 1.2 Extension: compress_certificate (len=3) ... OpenSSL – 1st Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 1564 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 1560 Version: TLS 1.2 (0x0303) Random: aec30b0aad542252... Session ID Length: 32 Session ID: f7ee7178cab8716a625... Cipher Suites Length: 60 Cipher Suites (30 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 1427 Extension: renegotiation_info (len=1) Extension: server_name (len=26) name=echo.websocket.events Extension: ec_point_formats (len=4) Extension: supported_groups (len=18) Extension: session_ticket (len=0) Extension: application_layer_protocol_negotiation (len=11) Extension: encrypt_then_mac (len=0) Extension: extended_master_secret (len=0) Extension: signature_algorithms (len=54) Extension: supported_versions (len=5) TLS 1.3, TLS 1.2 Extension: psk_key_exchange_modes (len=2) Extension: key_share (len=1258) X25519MLKEM768, x25519 OpenSSL – 2nd Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 1716 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 1712 Version: TLS 1.2 (0x0303) Random: 3fb3938a88166e4eb... Session ID Length: 32 Session ID: 7f13e54a231c17ccff70... Cipher Suites Length: 60 Cipher Suites (30 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 1579 Extension: renegotiation_info (len=1) Extension: server_name (len=26) name=echo.websocket.events Extension: ec_point_formats (len=4) Extension: supported_groups (len=18) Extension: session_ticket (len=0) Extension: application_layer_protocol_negotiation (len=11) Extension: encrypt_then_mac (len=0) Extension: extended_master_secret (len=0) Extension: signature_algorithms (len=54) Extension: supported_versions (len=5) TLS 1.3, TLS 1.2 Extension: psk_key_exchange_modes (len=2) Extension: key_share (len=1258) X25519MLKEM768, x25519 Extension: pre_shared_key (len=148) Since the Client Hello is generated by the client, I believe the session_ticket should be included in the first handshake regardless of server support. However, URLSession omits it entirely. Question: How can I enable TLS Session Resumption when using URLSession?

With my UDP Flow Copier working as demonstrated by the fact that it is proxying DNS traffic successfully, I am finally writing tests to verify UDP packet filtering. I'm sending packets to a public UDP echo server and reading the response successfully. In my initial testing however the TransparentProxyProvider System Extension is not intercepting my UDP traffic. handleNewUDPFlow() is being called for DNS but not for my test case UDP echo sends and receives. I've tried sending UDP with both GCDAsyncSocket and NWConnection as: connection = NWConnection(host: host, port: port, using: .udp) Is there some other criteria for UDP datagrams to be intercepted? Google search suggests this might be a known issue for connected or async UDP sockets.

Hello everyone, I'm encountering a MultipeerConnectivity connection issue while developing a visionOS app and would like to ask if other developers have experienced similar problems. Problem Description In visionOS 26.0 Beta 3 and Beta 4, when a visionOS device attempts to connect to an iPad via MultipeerConnectivity, the iPad side completely fails to receive connection requests, resulting in connection establishment failure. Specific Symptoms After executing serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) on the visionOS side The iPad side shows no response and receives no connection invitation Connection request times out after 10 seconds and is automatically rejected No error logs or exception information are generated Environment Information visionOS version: 26.0 Beta 3 and Beta 4 Development environment: macOS Tahoe 26.0 Beta (25A5306g) Target device: iPad (iOS 17.x) Network environment: Same WiFi network Comparative Test Results visionOS 2.6 (22O785): Functionality completely normal visionOS 26.0 Beta 1/2: Functionality normal visionOS 26.0 Beta 3/4: Exhibits the above problems Attempted Solutions Checked network configuration and firewall settings Adjusted MultipeerConnectivity parameters Reinitialized MCSession and MCNearbyServiceBrowser Cleared app cache and reinstalled Reset network settings Temporary Workaround Currently, the only solution is to downgrade the visionOS device to version 2.6. Impact of the Problem This issue severely affects the development of cross-device collaboration features in visionOS apps, particularly scenarios requiring peer-to-peer communication with iOS/iPadOS devices. Questions for Help Have other developers encountered similar issues? Are there any known solutions or workarounds? Is this a known issue with visionOS 26.0 Beta? Are there other known issues related to MultipeerConnectivity? Relevant Code Snippet // Connection invitation code private var serviceBrowser: MCNearbyServiceBrowser? let mcSession: MCSession // Execute connection invitation serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) Thank you for your help and suggestions! Development Environment: Xcode 15.x Target Platform: visionOS

I have a custom VPN app that uses NETunnelProviderManager to install a VPN Profile if one is not already installed. On previous iOS versions this would open the VPN Settings and ask for either the PIN, FaceID or TouchID and install the profile. With iOS 26 beta5 it opens the VPN Settings and stops. Is this a bug in iOS 26? Have there been changes to NETunnelProviderManager for iOS 26 that I'm not aware of? FYI we do the samething on macOS 26 beta5 and that works as expected.

On iOS 26 beta 5, it is impossible to add a VPN configuration when a passcode is set on the device. Every time, all it does is redirect to the Settings app with no prompt for passcode. The only way around this is to disable passcode on the device so adding a VPN configuration doesn’t have to open the Settings app. This issue happened intermittently in the past with previous iOS 26 betas and even on iOS 18, but the problem has worsened on iOS 26 beta 5 to the point where you have to turn off passcode to add a VPN. Feedback ID: FB17974765

Issue summary: Iphone 16 is not connecting to WiFi7 AP with MLO Suiteb encryption. Furuno AP(EW750) is sending EAPOL M1 message, but Iphone16 is not responding with EAPOL M2 message, Hence Iphone16 is unable to connect to Qualcomm based AP with MLO suiteb encryption. Issue impact: All the Iphone16 users cannot connect to WiFi7 AP with MLO suiteb encryption globally. Predominantly, Iphone users tend to connect to more secured wifi networks using WPA3 suiteb encryption, hence many of the iphone users will experience the connectivity issue significantly. Topology: AP Hardware: Furuno WiFi7 AP(EW770) The Furuno WiFi7 AP uses Miami IPQ5332 with waikiki radio QCN9274 AP software: SPF12.2 CSU3 IPhone16 software: (18.3.1 or 18.5 ) Iphone16 wifi capabilities: 802.11 b/a/g/n/ac/ax/be Radius server details: Radius server: Laptop running with Ubuntu Radius package: 3.0.26dfsggit20220223.1.00ed0241fa-0ubuntu3.4 Version: 3.0.26 Steps: Power on the Wi-Fi 7 Access Point with the Miami chipset, and flash it with the SPF 12.2 CSU3 image. Enable both 5 GHz and 6 GHz radios on the AP. Enable MLO (Multi-Link Operation) in 6Ghz & 5Ghz, set MLD address different from radio address and configure Suite-B (192-bit) encryption On the Linux laptop, set up the RADIUS server with EAP-TLS authentication method. Once the above steps are completed, take the iPhone 16 and follow the steps below to install the RADIUS client certificates on the device. On the sniffer laptop, switch the Wi-Fi adapter to monitor mode, configure the required channel, and begin packet capture. Check SSID is broadcasting, then connect the iPhone 16 to . Verify if the client (iPhone 16) connects to the SSID using WPA3-Enterprise, MLO, and Suite-B encryption by checking the wireless capture on both the AP and iPhone sides. Support needed from Apple team: We would request Apple team to analyse and enable the IPhone16 users to connect to advanced security WPA3 Suiteb by resolving the issue. Below is our analysis and observation for your reference. As per IEEE, MLD mac address can be set to the same or different from radio address, Iphone16 is not accepting EAPOL M1 message if source address(MLD) is different from radio address. IPhone16 is accepting EAPOL M1 if the source address(MLD) is set to the same as the radio address and responds with M2 message IPhone16 is not accepting EAPOL M1 if source address(MLD) set to different from radio address and fails to respond with M2 message

When setting new entitlements com.apple.developer.networking.carrier-constrained.appcategory and com.apple.developer.networking.carrier-constrained.app-optimized, I have a question about how URLSession should behave. I notice we have a way to specify whether a Network connection should allow ultra-constrained paths via NWParameters allowUltraConstrainedPaths: https://developer.apple.com/documentation/network/nwparameters/allowultraconstrainedpaths There does not appear to be a similar property on URLSessionConfiguration. In an ultra-constrained (eg. satellite) network, should we expect all requests made through an URLSession to fail? Does all network activity when ultra-constrained need to go through a NWConnection or NetworkConnection specifically configured with allowUltraConstrainedPaths, or can URLSession ever be configured to allow ultra-constrained paths?

Is it possible to capture or inspect UDP traffic using iOS content filter APIs (e.g., NEFilterDataProvider)? If not, what are the current technical or policy limitations that prevent UDP inspection via these frameworks? Any insights or suggestions on these topics would be highly appreciated.

Is it possible to capture or inspect UDP traffic using iOS content filter APIs (e.g., NEFilterDataProvider)? If not, what are the current technical or policy limitations that prevent UDP inspection via these frameworks? Any insights or suggestions on these topics would be highly appreciated.

Apologies if this is not the correct topic to post under. EpochField 5.2 is our application. It's a .NET MAUI application built against XCode 16. A customer of ours uses another app, TN3270, to connect to a mainframe host. After installing our app on an iPad and restarting the device, the TN3270 app will disconnect when suspended. Uninstalling our app (EpochField) will allow the TN3270 to suspend without disconnecting. We have tried removing background services, setting UIRequiresFullScreen to false or removing it entirely, and several other ideas. The only remedy seems to be uninstalling EpochField. On an iPad device: Install MochaSoft’s TN3270 app (free version is fine). Create a connection to ssl3270.nccourts.org, port 2023, SSL/TLS turned on, keep alive turned on. Verify that you can connect. Suspend the app by swiping up or choosing another app. Go back to TN3270 and verify that the app has not disconnected. Install EpochField 5.2. Do not run or configure the app, just install it. Repeat step 2. Restart the device. Open EpochField 5.2. You do not need to configure the app or login. Sometimes it isn't necessary to ever open EpochField to get the disconnects, but this is the most reliable way to reproduce the situation. Repeat step 2. The TN3270 app will now disconnect when suspended, even if EpochField is closed. You may need to wait a few seconds after suspending. Uninstall EpochField 5.2. Repeat step 2: the TN3270 app will now remain connected when suspended.

Samsung's Quick Share uses Wi-Fi Aware to achieve one-to-many concurrent sharing. Can Apple's Wi-Fi Aware achieve one-to-many concurrent sharing? Apple's AirDrop does support one-to-many concurrent sharing.

Hello everyone, I'm developing a macOS application with an integrated Content Filter System Extension. Both the main app and the extension are signed with a Developer ID Application provisioning profile. When building in Xcode, I'm encountering an entitlement mismatch error. I've inspected the provisioning profile using the command: security cms -D -i FilterContentExtension-prod-profile.provisionprofile | grep -A 10 com.apple.developer.networking.networkextension And found that the com.apple.developer.networking.networkextension section only contains values with the -systemextension suffix, for example: content-filter-provider-systemextension. However, when I enable Network Extension → Content Filter in Xcode, the .entitlements file is generated with: content-filter-provider. This leads to the error: "Provisioning profile 'FilterContentExtension-prod-profile' doesn't match the entitlements file’s value for the com.apple.developer.networking.networkextension entitlement." My specific questions are: Why does this error occur? How can I use the content-filter-provider entitlement? If I want to use the content-filter-provider entitlement inside com.apple.developer.networking.networkextension for my Content Filter System Extension, what should I do?

Hello everyone, I'm developing a macOS application with an integrated Content Filter System Extension. Both the main app and the extension are signed with a Developer ID Application provisioning profile. When building in Xcode, I'm encountering an entitlement mismatch error. I've inspected the provisioning profile using the command: security cms -D -i FilterContentExtension-prod-profile.provisionprofile | grep -A 10 com.apple.developer.networking.networkextension And found that the com.apple.developer.networking.networkextension section only contains values with the -systemextension suffix, for example: content-filter-provider-systemextension. However, when I enable Network Extension → Content Filter in Xcode, the .entitlements file is generated with: content-filter-provider. This leads to the error: "Provisioning profile 'FilterContentExtension-prod-profile' doesn't match the entitlements file’s value for the com.apple.developer.networking.networkextension entitlement." My specific questions are: Why does this error occur? How can I use the content-filter-provider entitlement? If I want to use the content-filter-provider entitlement inside com.apple.developer.networking.networkextension for my Content Filter System Extension, what should I do?

Hello, I have a question about developing an iOS app for general public. Can such an app use DNS Proxy Provider? The TN3134: Network Extension provider deployment article states that DNS Proxy Provider has the following restriction: "per-app on managed devices". Does this imply that a DNS Proxy Provider that can be used in a regular iOS App Store app? On the other hand, NEDNSProxyProvider only works with NEAppProxyFlow, is it possible to make it NOT per-app?

Hi, I am trying to create an App which connects to a Device via Wifi and then has to do some HTTP Requests. Connecting to the Wifi is working properly but when I try to make an HTTP API Call I get the response that the Domain is unavailable (No Internet Connection). I created the App in Flutter on Android everything works perfectly. The packages are all iOS Compatible. But in Safari the URL works so it is probably a permission Issue. I have the Following permissions granted: NSAppTransportSecurity NSBonjourServices NSLocalNetworkUsageDescription I even have Multicast Networking When I test the App I get asked to grant the access to local Network which I am granting. I don´t know what I should do next can somebody help? Feel free to ask for more Information

I am seeking clarification regarding the capabilities and limitations of deploying content filter profiles, such as web content filters, on unsupervised iOS devices through MDM solutions. Specifically, is per-app content filtering supported on unsupervised devices, or is it restricted to supervised devices only? If such restrictions exist, are there recognized workarounds? Additionally, I would like to understand if there are specific permissions or entitlements that enable apps to perform advanced filtering or monitoring functions on unsupervised devices. Any guidance or references to official documentation would be greatly appreciated.

Hi everyone, I'm trying to establish a connection to a server that requires mutual TLS (mTLS) using NSURLSession in an iOS app. The server is configured with a self-signed root CA (in the project, we are using ca.cer) and requires clients to present a valid certificate during the TLS handshake. What I’ve done so far: Server trust is working: I manually trust the custom root CA using SecTrustSetAnchorCertificates and SecTrustEvaluateWithError. I also configured the necessary NSAppTransportSecurity exception in Info.plist to allow the server certificate to pass ATS. This is confirmed by logs showing: Server trust succeeded The .p12 identity is correctly created: Contains the client certificate and private key. Loaded using SecPKCS12Import with the correct password. I implemented the delegate method: func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust { // Server trust override code (working) ... } if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodClientCertificate { print("🔐 Client cert challenge triggered") if let identity = loadIdentity() { let credential = URLCredential(identity: identity, certificates: nil, persistence: .forSession) completionHandler(.useCredential, credential) } else { completionHandler(.cancelAuthenticationChallenge, nil) } return } completionHandler(.performDefaultHandling, nil) } The session is correctly created using my custom delegate: let delegate = MTLSDelegate(identity: identity, certificates: certs) let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) Despite everything above, the client certificate is never sent, and the request fails with: Error Domain=NSURLErrorDomain Code=-1206 "The server requires a client certificate." From logs, it's clear the delegate is being hit for NSURLAuthenticationMethodServerTrust, but not for NSURLAuthenticationMethodClientCertificate.

how can I prevent handshake when certificate is user installed for example if user is using Proxyman or Charles proxy and they install their own certificates now system is trusting those certificates I wanna prevent that, and exclude those certificates that are installed by user, and accept the handshake if CA certificate is in a real valid certificate defined in OS I know this can be done in android by setting something like <network-security-config> <base-config> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config> </network-security-config>

The path from Network Extension’s in-provider networking APIs to Network framework has been long and somewhat rocky. The most common cause of confusion is NWEndpoint, where the same name can refer to two completely different types. I’ve helped a bunch of folks with this over the years, and I’ve decided to create this post to collect together all of those titbits. If you have questions or comments, please put them in a new thread. Put it in the App & System Services > Networking subtopic and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" NWEndpoint History and Advice A tale that spans three APIs, two languages, and ten years. The NWEndpoint type has a long and complex history, and if you’re not aware of that history you can bump into weird problems. The goal of this post is to explain the history and then offer advice on how to get around specific problems. IMPORTANT This post focuses on NWEndpoint, because that’s the type that causes the most problems, but there’s a similar situation with NWPath. The History In iOS 9 Apple introduced the Network Extension (NE) framework, which offers a convenient way for developers to create a custom VPN transport. Network Extension types all have the NE prefix. Note I’m gonna use iOS versions here, just to keep the text simple. If you’re targeting some other platform, use this handy conversion table: iOS | macOS | tvOS | watchOS | visionOS --- + ----- + ---- + ------- + -------- 9 | 10.11 | 9 | 2 | - 12 | 10.14 | 12 | 5 | - 18 | 15 | 18 | 11 | 2 At that time we also introduced in-provider networking APIs. The idea was that an NE provider could uses these Objective-C APIs to communicate with its VPN server, and thereby avoiding a bunch of ugly BSD Sockets code. The in-provider networking APIs were limited to NE providers. Specifically, the APIs to construct an in-provider connection were placed on types that were only usable within an NE provider. For example, a packet tunnel provider could create a NWTCPConnection object by calling -createTCPConnectionToEndpoint:enableTLS:TLSParameters:delegate:] and -createTCPConnectionThroughTunnelToEndpoint:enableTLS:TLSParameters:delegate:, which are both methods on NEPacketTunnelProvider. These in-provider networking APIs came with a number of ancillary types, including NWEndpoint and NWPath. At the time we thought that we might promote these in-provider networking APIs to general-purpose networking APIs. That’s why the APIs use the NW prefix. For example, it’s NWTCPConnection, not NETCPConnection. However, plans changed. In iOS 12 Apple shipped Network framework as our recommended general-purpose networking API. This actually includes two APIs: A Swift API that follows Swift conventions, for example, the connection type is called NWConnection A C API that follows C conventions, for example, the connection type is called nw_connection_t These APIs follow similar design patterns to the in-provider networking API, and thus have similar ancillary types. Specifically, there are an NWEndpoint and nw_endpoint_t types, both of which perform a similar role to the NWEndpoint type in the in-provider networking API. This was a source of some confusion in Swift, because the name NWEndpoint could refer to either the Network framework type or the Network Extension framework type, depending on what you’d included. Fortunately you could get around this by qualifying the type as either Network.NWEndpoint or NetworkExtension.NWEndpoint. The arrival of Network framework meant that it no longer made sense to promote the in-provider networking APIs to general-purposes networking APIs. The in-provider networking APIs were on the path to deprecation. However, deprecating these APIs was actually quite tricky. Network Extension framework uses these APIs in a number of interesting ways, and so deprecating them required adding replacements. In addition, we’d needed different replacements for Swift and Objective-C, because Network framework has separate APIs for Swift and C-based languages. In iOS 18 we tackled that problem head on. To continue the NWTCPConnection example above, we replaced: -createTCPConnectionToEndpoint:enableTLS:TLSParameters:delegate:] with nw_connection_t -createTCPConnectionThroughTunnelToEndpoint:enableTLS:TLSParameters:delegate: with nw_connection_t combined with a new virtualInterface property on NEPacketTunnelProvider Of course that’s the Objective-C side of things. In Swift, the replacement is NWConnection rather than nw_connection_t, and the type of the virtualInterface property is NWInterface rather than nw_interface_t. But that’s not the full story. For the two types that use the same name in both frameworks, NWEndpoint and NWPath, we decided to use this opportunity to sort out that confusion. To see how we did that, check out the <NetworkExtension/NetworkExtension.apinotes> file in the SDK. Focusing on NWEndpoint for the moment, you’ll find two entries: … - Name: NWEndpoint SwiftPrivate: true … SwiftVersions: - Version: 5.0 … - Name: NWEndpoint SwiftPrivate: false … The first entry applies when you’re building with the Swift 6 language mode. This marks the type as SwiftPrivate, which means that Swift imports it as __NWEndpoint. That frees up the NWEndpoint name to refer exclusively to the Network framework type. The second entry applies when you’re building with the Swift 5 language mode. It marks the type as not SwiftPrivate. This is a compatible measure to ensure that code written for Swift 5 continues to build. The Advice This sections discusses specific cases in this transition. NWEndpoint and NWPath In Swift 5 language mode, NWEndpoint and NWPath might refer to either framework, depending on what you’ve imported. Add a qualifier if there’s any ambiguity, for example, Network.NWEndpoint or NetworkExtension.NWEndpoint. In Swift 6 language mode, NWEndpoint and NWPath always refer to the Network framework type. Add a __ prefix to get to the Network Extension type. For example, use NWEndpoint for the Network framework type and __NWEndpoint for the Network Extension type. Direct and Through-Tunnel TCP Connections in Swift To create a connection directly, simply create an NWConnection. This support both TCP and UDP, with or without TLS. To create a connection through the tunnel, replace code like this: let c = self.createTCPConnectionThroughTunnel(…) with code like this: let params = NWParameters.tcp params.requiredInterface = self.virtualInterface let c = NWConnection(to: …, using: params) This is for TCP but the same basic process applies to UDP. UDP and App Proxies in Swift If you’re building an app proxy, transparent proxy, or DNS proxy in Swift and need to handle UDP flows using the new API, adopt the NEAppProxyUDPFlowHandling protocol. So, replace code like this: class AppProxyProvider: NEAppProxyProvider { … override func handleNewUDPFlow(_ flow: NEAppProxyUDPFlow, initialRemoteEndpoint remoteEndpoint: NWEndpoint) -> Bool { … } } with this: class AppProxyProvider: NEAppProxyProvider, NEAppProxyUDPFlowHandling { … func handleNewUDPFlow(_ flow: NEAppProxyUDPFlow, initialRemoteFlowEndpoint remoteEndpoint: NWEndpoint) -> Bool { … } } Creating a Network Rule To create an NWHostEndpoint, replace code like this: let ep = NWHostEndpoint(hostname: "1.2.3.4", port: "12345") let r = NENetworkRule(destinationHost: ep, protocol: .TCP) with this: let ep = NWEndpoint.hostPort(host: "1.2.3.4", port: 12345) let r = NENetworkRule(destinationHostEndpoint: ep, protocol: .TCP) Note how the first label of the initialiser has changed from destinationHost to destinationHostEndpoint.