General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk TCP and UDP ports used by Apple software products support article Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Wi-Fi (general): How to modernize your captive network developer news post Wi-Fi Fundamentals forums post Filing a Wi-Fi Bug Report forums post Working with a Wi-Fi Accessory forums post — This is part of the Extra-ordinary Networking series. Wi-Fi (iOS): TN3111 iOS Wi-Fi API overview technote Wi-Fi Aware framework documentation WirelessInsights framework documentation iOS Network Signal Strength forums post Network Extension Resources Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. WWDC 2025 Session 314 Get ahead with quantum-secure cryptography Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Prepare your network environment for stricter security requirements support article — This is primarily of interest to folks developing management software, for example, an MDM server. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

Hi everyone, I’m looking for some clarification regarding "Transparent Proxy configurations on macOS". We have a requirement where multiple security/networking solutions may need to use a "Transparent Proxy" on the same macOS device. For example, one solution may be used for web security/SSL inspection while another solution is required for a different security or network traffic use case. My questions are: 1.Does macOS support configuring and running multiple Transparent Proxy providers simultaneously on the same device? 2. If multiple Transparent Proxy configurations are deployed through MDM, how does macOS determine which proxy handles the traffic? 3.Is there any limitation on the number of Transparent Proxy configurations/providers that can be configured? 4.Can multiple Transparent Proxy providers coexist if they handle different traffic, applications, or network interfaces? 5. If multiple providers are configured, is there a supported mechanism to define priority, ordering, or traffic routing between them? 6. Are there any differences or limitations across recent macOS versions, particularly macOS 15 and macOS 26? 7. Is there any Apple documentation or recommended architecture for deploying multiple Transparent Proxy providers on the same Mac? If anyone has implemented or tested a setup with multiple Transparent Proxy providers on macOS, I’d appreciate any insights, documentation, or real-world experience. Thanks! Vijay

Summary Our Live Caller ID Lookup deployment works end-to-end from an Xcode-signed build but fails on the App Store build of the same app, on the same device, same network, same Apple ID. On the production build every authenticated request fails locally in ~47 ms, before any packet leaves the device. Our Identity & Trust configuration in CloudKit Console has read "Approved" since 2026-08-08. Device log at the moment of failure nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed" ciphermld(CipherML) <Error>: queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token _NSURLErrorPrivacyProxyFailureKey=true NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"} (_NSURLErrorNWPathKey=satisfied, Wi-Fi up, LQM: good) Control experiment: the device's privacy proxy stack is healthy at that exact moment 0.93 seconds before our extension is refused, the same device attaches a proxy to another connection without any problem: 11:51:59.417 mDNSResponder nw_endpoint_proxy_add_config_if_applicable Adding proxy masque Proxy: https://mask.icloud.com:443 11:52:00.337 ciphermld [C15 ... bundle id: <our extension>, proxy fail closed] start 11:52:00.346 ciphermld Proxies not present, but required to fail closed System state in the same capture: Privacy Proxy Service Status: 1 Privacy Proxy User Tier: 1 Privacy Proxy Networks: (<Cellular, Active>, <WiFi, Active>) Counts across the capture: nw_endpoint_proxy_add_config_if_applicable appears twice (mDNSResponder and Safari SafeBrowsing), while Proxies not present appears 16 times, all from ciphermld, all for our extension's bundle id. No connection made on behalf of our extension is ever given a proxy configuration. Reproduced on two networks and after a device restart, with the device charging and Low Power Mode off. Apple's own endpoint already recognises our issuer 11:51:59.405 ciphermld(CipherML) Fetching token issuer directory from https://gateway.icloud.com/pat-issuer-directory?issuer=<our-issuer-host> 11:52:00.332 200, 1511 bytes, 928 ms Our validation Bearer token from the onboarding submission also returns 200 on /token-key-for-user-token when Apple's validator calls it, which we observe on our server several times a day. A second observation that may be the key In apple/pir-service-example issue #139 an Apple engineer stated that once onboarding is complete, "all requests ... will automatically use OHTTP even when it is a development build". We captured our development build today with full device logging. Every one of its connections goes directly to our PIR host over QUIC, with no proxy fail closed stamp, and the words ohttp, oblivious, mask.icloud and our OHTTP gateway hostname appear zero times in the capture: 16 connections, all: Hostname#<our-pir-host>:443, attribution: developer "proxy fail closed": 0 "Proxies not present": 0 If a completed onboarding forces OHTTP even for development builds, then our development build going direct indicates the relay configuration was never distributed for our extension's bundle id, despite the console showing "Approved". Fleet-level data, not a single device On the day of release, 40 distinct premium accounts on the current App Store build fetched their user tier token from our backend. Across that entire day our PIR service saw zero Privacy Pass issuances and zero queries from App Store builds. For contrast, a single development-signed device produced 144 /issue requests in one day earlier in the month. What we already checked and fixed on our side HTTP/2 ALPN negotiates on all three hosts (service, issuer, gateway). The DNS TXT ownership record is in place. The OHTTP gateway serves a valid key config (X25519 / HKDF-SHA256 / AES-128-GCM). The PIR use case names match the required <extension bundle id>.block / .identity format exactly. The validation identity +1 408 555 1212 "Johnny Appleseed" is present in the live corpus. We found and fixed a real defect of our own: our OHTTP gateway's allowed target origin list was missing the issuer host. We corrected it and restarted the gateway (its HPKE key config was byte-identical afterwards, so no key rotation occurred). The failure reproduced with an identical signature seven minutes later, and the device log confirms these hops never touch our gateway anyway. Questions Is relay / privacy proxy provisioning for a production bundle id a separate step after the Identity & Trust configuration is approved, and what is the expected propagation time? Is there any way for a developer to check provisioning status? Right now an "Approved" badge and a completely non-functional production build look identical from our side. Is there a supported way to exercise the production privacy proxy path before shipping to the App Store? Development builds bypass it by design, so the first real test of the production path was made by paying customers. This seems likely to affect other adopters. Is provisioning keyed on the extension bundle id, the app bundle id, or the team id? Other system consumers on the same device receive proxy configurations normally. We accidentally submitted two identical configurations three minutes apart on 2026-08-08 and both show "Approved". Can a duplicate block or confuse provisioning, and should one be revoked? Environment: iPhone 17 Pro Max, iOS 26.6.1, Xcode 26.5 (17F42). App Store build version 14 (36). Feedback Assistant report with full device logs: FB24501570 GitHub issue with the same detail: https://github.com/apple/pir-service-example/issues/162 Configuration ID: 693155e2-b8ba-4b47-9b6c-64fd97677386 and a1959377-8069-4225-87b9-c1ff81016611

Hello, We are developing an enterprise iOS application for cellular network benchmarking, performance validation, and network analytics. After reviewing the publicly available iOS frameworks and APIs, including CoreTelephony, we have not identified a supported public API that provides access to the following cellular RF and network measurements: • ARFCN • Band • Bandwidth (BW) • Cell ID • PCI (Physical Cell Identity) • CQI (Channel Quality Indicator) • RSRP (Reference Signal Received Power) • RSRQ (Reference Signal Received Quality) • SINR / SNR • RSSI • TAC (Tracking Area Code) • TA (Timing Advance) As an example, we are interested in obtaining information similar to the following: { "arfcn": "", "band": "", "bw": "", "cellId": "", "cqi": "", "pci": "", "rsrp": "", "rsrq": "", "sinr": "", "rssi": "", "ta": "", "tac": "" } Could Apple please clarify whether any of these measurements are available through an officially supported mechanism, including but not limited to: • Public iOS frameworks or APIs • Special entitlements • Carrier partner programs or integrations • Apple-approved diagnostics or measurement frameworks • Any other Apple-supported programs or access mechanisms We are not seeking to use private APIs, reverse-engineering techniques, or unsupported approaches. Our objective is solely to determine whether Apple provides a legitimate and supported method for an application to access any of these cellular network metrics on iOS devices. If access to any subset of these measurements is supported, we would greatly appreciate guidance regarding the relevant documentation, framework, entitlement, carrier program, or enrollment process. Our use case is limited to: • Cellular network benchmarking • Performance validation and testing • Network quality analytics Thank you for your guidance and assistance.

TN3135 describes the exception that lets a watchOS app use low-level networking while it holds an active audio session. I have that working, and the app functions — but the network path is withdrawn and restored on a strikingly regular cycle, and I would like to know whether that is expected behaviour rather than something I am doing wrong. Setup Apple Watch Series 10 (Watch7,9), watchOS 26.5. Reproduced on a Series 6 (Watch6,2). UIBackgroundModes: [audio]; AVAudioSession category .playAndRecord, mode .spokenAudio; activated with the async activate(options:completionHandler:). NWConnection with NWProtocolWebSocket to a WebSocket relay over TLS. The app streams 16 kHz mono PCM continuously while transmitting and holds the socket open otherwise. Symptom NWPathMonitor reports .unsatisfied, then .satisfied about two seconds later, over and over. Measured with the iPhone powered off, so the watch was on its own Wi-Fi: Uptime between drops Outage 36.4 s 2.1 s 36.7 s 1.9 s 36.9 s 2.1 s The regularity is what prompts the question — uptime varies by ±0.3 s and the outage is consistently 2.0 s. That reads as a timeout expiring rather than radio behaviour. What I have ruled out Not the network or the server. A browser client on the same relay, same TLS, same wire protocol, holds a WebSocket indefinitely. Not the interface. Identical cadence over the companion ipsec1 tunnel with the iPhone present, and over the watch's own en0 with the iPhone powered off. Pinning requiredInterfaceType = .wifi while the iPhone is reachable fails outright — the path offers only ipsec1. Not audio-session interruption. I observe interruptionNotification, routeChangeNotification, mediaServicesWereResetNotification and silenceSecondaryAudioHintNotification. None fire at a drop. At the moment the path goes .unsatisfied, the engine is running and the player node is actively playing. Not session idleness. Playing continuous silence for the whole session, rather than only while reconnecting, made no difference — still 36.4 s. The control that surprised me To test whether this affects any long-lived watch socket or only audio-unlocked ones, I built a second app with no AVAudioSession at all, no audio background mode, holding a URLSessionWebSocketTask and kept alive by a WKExtendedRuntimeSession so screen sleep was not a factor. It never connected. NWPathMonitor reported .unsatisfied once and never changed, across a 30 s run, and every request failed with "The Internet connection appears to be offline." I had expected URLSession to be permitted regardless. Questions Does the audio-session networking exception in TN3135 have a defined lifetime, and is a periodic revoke/re-grant cycle expected? If so, is there a supported way to hold it continuously — or is the correct design simply to expect the interruption and reconnect through it? Is it expected that an app with no audio session gets no network path at all on watchOS, including via URLSession, even in the foreground with an extended runtime session?

Hello , We are developing an enterprise iOS application for cellular network benchmarking, performance validation, and analytics. We have reviewed the publicly available iOS APIs, including CoreTelephony, and have not identified a public API that provides access to the following cellular RF/network measurements: ARFCN / EARFCN / NRARFCN Band Bandwidth (BW) Cell ID PCI (Physical Cell Identity) CQI (Channel Quality Indicator) RSRP (Reference Signal Received Power) RSRQ (Reference Signal Received Quality) SINR / SNR RSSI TAC (Tracking Area Code) TA (Timing Advance) Could Apple please clarify whether any of the above measurements can be accessed through an officially supported mechanism, including but not limited to: Public iOS frameworks or APIs Special entitlements Managed or supervised-device capabilities Enterprise-specific capabilities Carrier-partner programs or integrations Apple-approved diagnostic or measurement frameworks Other approved mechanisms or programs We are not seeking to use private APIs, reverse-engineering techniques, or unsupported mechanisms. Our goal is to understand whether Apple provides any legitimate and supported way for an enterprise application to obtain these measurements on iOS devices. If access to any subset of these metrics is supported, could you please point us to the relevant documentation, framework, entitlement, carrier program, or enrollment process? Our use case is limited to cellular network benchmarking, performance validation, and network analytics on iOS devices. Thank you for your guidance.

We deploy WPA3-EAP for co-working spaces (EU/US). That means BYOD and no ability to enforce MDM. Each co-working space issue wifi credentials to their individual members, usually in the form of PEAP/TTLS. The user joins the SSID for EAP and is prompted to enter username + password, and then to accepts our radius certificate (prompted as "not trusted" of course). Does the certificate validity period of 825 days or fewer apply to our radius leaf certs? The question has come up as we read: https://support.apple.com/en-us/102028 --"This change will not affect certificates issued from user-added or administrator-added Root CAs" https://support.apple.com/en-ca/103769 --"Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:" ..... "TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate)." lastly, while PEAP/TTLS is the primary method. Second is delivering a .mobileconfig that can be downloaded by the user containing EAP-TLS authentication. These also require user acceptance as there again is no MDM possible. We dont have any issues currently, but are we going to wake up one morning and find that all apple devices have dropped off the networks?

I am working on a Network Extension (Transparent Proxy) which is used by a DLP to prevent data leaks over the network. For each incoming NEAppProxyTCPFlow, the extension instantiates a custom wrapper object that creates an outbound nw_connection_t to the target host and port using Network framework. When a client application connects to unreachable or blocked ports (e.g., 5222), our extension proxies this connection. As the destination is unreachable, the newly created connection transitions into nw_connection_state_waiting in Network Extension. Since macOS keeps nw_connection_t in the nw_connection_state_waiting state indefinitely, such connections cause system resource leaks. Over time, this leads to: exhaustion of system file descriptors and sockets. system-wide network unavailability until the extension process is killed. Could you provide best-practice recommendations for handling nw_connection_state_waiting in a Network Extension to prevent such resource leaks?

Following up on TN3135 and the resolution in https://developer.apple.com/forums/thread/773362 — that thread solved establishing a low-level connection on watchOS (the asynchronous AVAudioSession.activate(options:completionHandler:) instead of the synchronous setActive()). This question is about a connection staying established, which I could not find discussed anywhere. Environment: Apple Watch, watchOS 26.6 (23U67). Audio app, WKBackgroundModes = ["self-care"]. Real device, TestFlight build, not the simulator. What works Opening an NWConnection WebSocket to my own server is reliable — 8 attempts out of 8 reached .ready in 0.28–0.98 s, and an echo frame round-tripped in 27–89 ms. Interestingly, in my measurements it opens under BOTH activation variants: the asynchronous activate(options:completionHandler:) AND the synchronous setActive(true). The two are within ~0.2 s of each other. I mention it only because the thread above concluded the synchronous one is insufficient; on 26.6 I cannot reproduce that difference for establishment. What fails The connection goes quiet after roughly half a minute, and an NWPathMonitor running alongside it shows why: the path transitions to .unsatisfied. Four runs: +34.0 s (cellular) +34.6 s (cellular) +36.0 s (Wi-Fi) +34.3 s (companion link only — availableInterfaces ["other", "other"]) The server sends a heartbeat frame every 5 s and closes the socket on a schedule, so I can tell "the peer closed" from "we stopped receiving". The client receives beats 1–6 (5 s … 30 s) and then nothing; the scheduled close never arrives. What I ruled out Server side. The same client construction run on macOS against the same endpoint receives all 8 heartbeats and the scheduled close at 45.1 s. Both audio-session activation variants — no difference, as above. Network type — cellular, Wi-Fi and companion-link-only all drop at ~35 s. The app being suspended. The app keeps logging densely throughout, and in the last run it held a WKExtendedRuntimeSession (delegate reported extendedRuntimeSessionDidStart) and was actively playing audio through AVAudioEngine from the first second — i.e. the audio-streaming condition TN3135 describes — for the entire window. The path dropped anyway, at +34.3 s. An idle socket. Server traffic arrives every 5 s until the drop. The comparison that puzzles me The same app, on the same watch, the same afternoon, relays the same realtime audio session over plain HTTPS (URLSession) instead — and that runs for 64 s continuously without a stall, including straight through a WatchConnectivity "reachability settled: unreachable" transition. So a high-level URLSession request stream survives a period in which a low-level NWConnection's path is reported unsatisfied. That is consistent with the note in thread 773362 that "on watchOS every session is kinda like a background session, where the actual work is done out of process" — but it leaves me unsure what the intended behaviour is. Questions Is a ~35 s path lifetime the expected behaviour for low-level networking on watchOS, or does it indicate something wrong on my side? Does the TN3135 audio-streaming exception cover only the establishment of a low-level connection, or is it also supposed to keep the path available for the duration of the audio streaming? If it is supposed to persist: is there something beyond an active audio session, flowing audio and a WKExtendedRuntimeSession that an app must do to keep the path alive? If ~35 s is the expected ceiling, is a WebSocket a supported transport for a multi-minute conversational audio session on watchOS at all — or is relaying over URLSession the intended approach despite the guidance to prefer Network framework? Happy to file a bug with a sysdiagnose and a reduced sample project if that is more useful — please say the word and I will attach the numbers above.

iPhone 12 pro with iOS 26.0 (23A5276f) App: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps We aim to use Wi-Fi Aware to establish file transfer between Android and Apple devices. Apple will act as the Publisher, and Android will act as the Subscriber. According to the pairing process outlined in the Wi-Fi Aware protocol (Figure 49 in the Wi-Fi Aware 4.0 specification), the three PASN Authentication frames have been successfully exchanged. Subsequently, Android sends the encrypted Follow-up PMF to Apple, but the Apple log shows: Failed to parse event. Please refer to the attached complete log. We request Apple to provide a solution. apple Log-20250808a.txt

Dear Apple: We are currently developing and debugging WiFi NAN (Neighbor Awareness Networking) connectivity for Android and Apple devices. We have encountered a multi-device connection issue. Specifically, we have one Android device (Device A), and two Apple devices (Device B and Device C). Both Apple devices run the same application, which allows them to enter the publish state. Assuming Android Device A has already paired with both Apple devices, when we next want to connect specifically to Apple Device B, and both Apple devices happen to be in the publish state at the same time, how can we distinguish between the two devices during service discovery and connection? Because the apps on the two Apple devices are identical, the service names they publish are also the same.

Hi all, I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection: nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135. Questions How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS? Does NECP enforce additional restrictions even with background audio enabled, and how can I address this? Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated. Thanks!

I am currently using macOS 27 beta 4, but this issue also existed on macOS 26.5 before I updated to macOS 27. I am not sure whether earlier system versions had the same problem, as I had never encountered a similar issue before. I am developing through the local network, including using VSCode Remote SSH to connect to a local server, and using a Swift app to establish a WebSocket connection with the local server. Recently, I have encountered multiple cases where the local server connection suddenly failed. Checking the logs showed messages such as Permission denied or similar errors. AI assistants explained that this usually means the target app does not have Local Network permission enabled in Privacy & Security settings. However, I checked the settings page and confirmed that the target apps already have Local Network permission enabled. Previously, when VSCode Remote SSH failed, I observed the following behavior: after updating VSCode, if the local server was not running, VSCode Remote SSH immediately reported that the target server could not be found. After starting the local server, it immediately reported that there was no route to the host (I do not remember the exact English error message, but it was a common network error). Checking the logs showed Permission denied. I even noticed two VSCode entries in the Local Network permission list that could be enabled or disabled independently. Just now, my Swift app failed in a similar way. I verified that the server was running and listening because websocat could successfully connect to the local server. The app uses Starscream, and client.connect() was executed but the connection could not be established. Checking log stream --predicate 'process == "name"' --level debug showed: 2026-08-08 14:48:38.620396 ... nw_endpoint_handler_path_change [C1 ... waiting parent-flow (unsatisfied (Local network prohibited), interface: bridge100, ipv4)] However, after successfully applying the workaround described below, I saw the backend server print related output, proving that the server received the app's ping frame. At the same time, the Local Network permission page did not show this app as an entry, and no permission prompt appeared asking me to authorize Local Network access. Therefore, I am no longer certain that this issue is strictly related to Local Network permission. All of the above cases involve third-party components: VSCode Remote SSH, UTM providing a server at 192.168.64.3, and Starscream instead of the WebSocket implementation provided by Foundation. I am not an expert in networking, so I cannot completely rule out issues caused by third-party software. However, I found that running the following commands in macOS Recovery Mode: #!/bin/bash cd "/Volumes/Data/Library/Preferences/" rm -f com.apple.networkextension.plist rm -f com.apple.networkextension.uuidcache.plist rm -f com.apple.networkextension.control.plist rm -f com.apple.networkextension.necp.plist and then rebooting can resolve the situation where one specific app suddenly cannot access the local network while other apps continue to work normally. Running tccutil reset All com.bundle.id did not solve the problem. This command was suggested by Claude Sonnet 5. I am not even sure whether Local Network permission is managed by TCC, but I am including this information because the five commands above appear to modify NetworkExtension-related files rather than the TCC database. This issue cannot currently be reproduced reliably. I do not know when it will happen. After it occurs, I have not found a normal-system-environment solution. The only workaround I have found is booting into Recovery Mode and clearing the local network authorization-related files.

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle guarantees provided by the Network framework for NWListener and NWConnection when an iOS application transitions to the background and is subsequently suspended. I was going through this Technical Note TN2277 (specifically the Listening socket section), which describes that if the app has gone into the background and eventually gets suspended, then even though the underlying socket is still active/functional, new connections might be immediately rejected by the kernel. In the scenario where the system suspends the app and later reclaims the resources from underneath the listening socket, the app will no longer be able to listen for incoming connections. On resumption, it might be possible that the app is not even notified that the underlying resource has been reclaimed. Relevant Quotes from the Tech note: Once your app goes into the background, it may be suspended. Once it is suspended, it's unable to properly process incoming connections on the listening socket. However, the socket is still active as far as the kernel is concerned. If a client connects to the socket, the kernel will accept the connection but your app won't communicate over it. Eventually the client will give up, but that might take a while. Thus, it's better to close the listening socket when going into the background, which will cause incoming connections to be immediately rejected by the kernel. If the system suspends your app and then, later on, reclaims the resources from underneath your listening socket, your app will no longer be listening for connections, even after it has been resumed. The app may or may not be notified of this, depending on how it manages the listening socket. It's generally easier to avoid this problem entirely by closing the listening socket when the app is in the background. Does the above hold true for Network Framework UDP sockets, or is the stateUpdateHandler of the corresponding NWListener executed on resumption, indicating that the socket has been reclaimed and the state is either cancelled/failed (non-recoverable) or waiting (recoverable)? If yes, should the app close the NWListener when going into background since it might not be able to determine whether the underlying socket resource has been reclaimed or not on resumption? Additionally, for NWConnection client/accepted-client sockets, does the same semantics apply?

Development environment Xcode 26.0 Beta 6 iOS 26 Simulator macOS 15.6.1 To verify TLS 1.3 session resumption behavior in URLSession, I configured URLSessionConfiguration as follows and sent an HTTP GET request: let config = URLSessionConfiguration.ephemeral config.tlsMinimumSupportedProtocolVersion = .TLSv13 config.tlsMaximumSupportedProtocolVersion = .TLSv13 config.httpMaximumConnectionsPerHost = 1 config.httpAdditionalHeaders = ["Connection": "close"] config.enablesEarlyData = true let session = URLSession(configuration: config, delegate: nil, delegateQueue: nil) let url = URL(string: "https://www.google.com")! var request = URLRequest(url: url) request.assumesHTTP3Capable = true request.httpMethod = "GET" let task = session.dataTask(with: request) { data, response, error in if let error = error { print("Error during URLSession data task: \(error)") return } if let data = data, let responseString = String(data: data, encoding: .utf8) { print("Received data via URLSession: \(responseString)") } else { print("No data received or data is not UTF-8 encoded") } } task.resume() However, after capturing the packets, I found that the ClientHello packet did not include the early_data extension. It seems that enablesEarlyData on URLSessionConfiguration is not being applied. How can I make this work properly?

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle of the DispatchQueue associated with an NWConnection instance. Let's assume I have an NWConnection instance, and I associate it with a dispatch queue using the start(queue:) API, such that network OS events for the NWConnection instance can be delivered to this queue. My understanding is that this association would result in NWConnection holding a strong reference to the DispatchQueue object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the following steps. Also, assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the DispatchQueue, in which case whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

I want to know the right way/API/usage to use NWConnectionGroup to send both datagram and non-datagram stream. I am currently working on an P2P video streaming app. I want to leverage NWConnectionGroup over QUIC to handle both message channel (traditionally handled by a TCP connection) and media channel (traditionally handled by sth. over UDP) to transmit SRT packets back and forth. I created a NWConnectionGroup and it worked fine on non-datagram parts. The problems are with datagram part. I tried extracting a connection with datagram = true either from the group or from message, doesn't and in some cases it breaks other non-datagram connections. I currently send datagram directly using the NWConnectionGroup.send(content:completion). It kinda works but I keep seeing it canceled a lot of messages, which breaks SRT shortly after start. The warnings belong flooded my console. (Seems like want me to create a connection to transmit datagram, how?) nw_connection_create_with_connection [C1600] Original connection not yet connected nw_connection_group_create_connection_for_endpoint_and_parameters [G1] failed to create connection with parameters quic, local: fe80::439:68b4:6ec2:694%en0.60517, definite, attribution: developer, server I must use it in wrong way. What should I do to fix it?

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

I've a iOT companion app, in which I'll connect to iOT's Wi-Fi and then communicate the device with APIs, for the above functionality we needed local network permission So we enabled neccessary keys in info.plist and at the time of App Launch we trigger local network permission using the following code info.plist <string>This app needs local network access permission to connect with your iOT device and customize its settings</string> <key>NSBonjourServices</key> <array> <string>_network-perm._tcp</string> <string>_network-perm._udp</string> </array> Network Permission Trigger Methods import Foundation import MultipeerConnectivity class NetworkPermissionManager: NSObject { static let shared = NetworkPermissionManager() private var session: MCSession? private var advertiser: MCNearbyServiceAdvertiser? private var browser: MCNearbyServiceBrowser? private var permissionCallback: ((String) -> Void)? func requestPermission(callback: @escaping (String) -> Void) { self.permissionCallback = callback do { let peerId = MCPeerID(displayName: UUID().uuidString) session = MCSession(peer: peerId, securityIdentity: nil, encryptionPreference: .required) session?.delegate = self advertiser = MCNearbyServiceAdvertiser( peer: peerId, discoveryInfo: nil, serviceType: "network-perm" ) advertiser?.delegate = self browser = MCNearbyServiceBrowser( peer: peerId, serviceType: "network-perm" ) browser?.delegate = self advertiser?.startAdvertisingPeer() browser?.startBrowsingForPeers() // Stop after delay DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { [weak self] in self?.stopAll() // If no error occurred until now, consider permission triggered self?.permissionCallback?("granted") self?.permissionCallback = nil } } catch { permissionCallback?("error: \(error.localizedDescription)") permissionCallback = nil } } func stopAll() { advertiser?.stopAdvertisingPeer() browser?.stopBrowsingForPeers() session?.disconnect() } } extension NetworkPermissionManager: MCSessionDelegate { func session(_: MCSession, peer _: MCPeerID, didChange _: MCSessionState) {} func session(_: MCSession, didReceive _: Data, fromPeer _: MCPeerID) {} func session(_: MCSession, didReceive _: InputStream, withName _: String, fromPeer _: MCPeerID) {} func session(_: MCSession, didStartReceivingResourceWithName _: String, fromPeer _: MCPeerID, with _: Progress) {} func session(_: MCSession, didFinishReceivingResourceWithName _: String, fromPeer _: MCPeerID, at _: URL?, withError _: Error?) {} } extension NetworkPermissionManager: MCNearbyServiceAdvertiserDelegate { func advertiser(_: MCNearbyServiceAdvertiser, didReceiveInvitationFromPeer _: MCPeerID, withContext _: Data?, invitationHandler: @escaping (Bool, MCSession?) -> Void) { invitationHandler(false, nil) } func advertiser(_: MCNearbyServiceAdvertiser, didNotStartAdvertisingPeer error: Error) { print("❌ Advertising failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } } extension NetworkPermissionManager: MCNearbyServiceBrowserDelegate { func browser(_: MCNearbyServiceBrowser, foundPeer _: MCPeerID, withDiscoveryInfo _: [String: String]?) {} func browser(_: MCNearbyServiceBrowser, lostPeer _: MCPeerID) {} func browser(_: MCNearbyServiceBrowser, didNotStartBrowsingForPeers error: Error) { print("❌ Browsing failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } }``` I want to satisfy this following cases but it's not working as expected # Case1 Working App launches --> trigger permission using above code --> user granted permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should return success response # Case2 Not working App launches --> trigger permission using above code --> user denied permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should throw an error I double checked the permission status in the app settings there also showing disabled state In my case case 2 is also return success, even though user denied the permission I got success response. I wonder why this happens the same above 2 cases working as expected in iOS 17.x versions

Hi, I’m using Network Framework to implement a UDP client via NWConnection, and I’m looking for clarification about the correct and fully safe shutdown procedure, especially regarding resource release. I have initiated some pending receive calls on the NWConnection (using receive). After calling connection.cancel(), do we need to wait for the cancellation of these pending receives? As mentioned in this thread, NWConnection retains references to the receive closures and releases them once they are called. If a receive closure holds a reference to the NWConnection itself, do we need to wait for these closures to be called to avoid memory leaks? Or, if there are no such retained references, we don't need to wait for the cancellation of the pending I/O and cancelled state for NWConnection?

Dear Apple: 1、We want to create a socket application using the C language interface on the WiFi Aware channel, utilizing native socket APIs such as socket, connect, bind, etc., to transmit data through the established WiFi Aware channel. However, we wrote a demo and tested it. On the iOS side, when initiating a socket connect, we received error code 65. We also used the IPv6 protocol. We would like to ask for help: Is it impossible to use native socket APIs for programming on the WiFi Aware channel? 2、If native sockets are not available, which interfaces are recommended for WiFi Aware communication on iOS? Thanks.