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 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. 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 Network Extension (including Wi-Fi on iOS): See Network Extension Resources Wi-Fi Fundamentals TN3111 iOS Wi-Fi API overview Wi-Fi Aware framework documentation Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). 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. 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 WirelessInsights framework documentation iOS Network Signal Strength Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

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?

我的完整报错信息： Task <0568A3A0-A40C-42A8-9491-2FC52D71EFFF>.<4> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "似乎已断开与互联网的连接。" UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x107db5590 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 1ms using unknown from cache, _NSURLErrorNWPathKey=unsatisfied (Denied over Wi-Fi interface), interface: en0[802.11], ipv4, dns, uses wifi}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <0568A3A0-A40C-42A8-9491-2FC52D71EFFF>.<4>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <0568A3A0-A40C-42A8-9491-2FC52D71EFFF>.<4>" ), NSLocalizedDescription=似乎已断开与互联网的连接。, NSErrorFailingURLStringKey=https://sharkserver.dypc.top/shark_user/login, NSErrorFailingURLKey=https://sharkserver.dypc.top/shark_user/login, _kCFStreamErrorDomainKey=1} 请求失败：似乎已断开与互联网的连接。 以下是问题的具体描述 我的A手机（15pro max 版本18,6,1） 使用xcode直接在A手机上运行我的程序 尝试发起post请求的时候得到了该报错。 我做了以下尝试 1.检查了A手机网络，一切正常，浏览器和其他app均可正常访问网络 2.检查了A手机上我的app权限，确认我因为为我的程序打开了无线网络和蜂窝流量 3.重启A手机，还原A手机网络设置，还原A手机所有设置，重启mac电脑 以上做法均无效，依旧报上面的错误 4.然后我尝试使用B手机(iPhone13 版本18.5)安装该程序 ，B手机可以正常运行并成功发起post请求，证明我的代码没有问题 5.我将代码上传至testfight 然后使用A手机下载testfight里的该程序 ，程序可以成功发起post请求没有任何错误，我再次使用xcode运行该程序到真机，又得到了Code=-1009错误 无法发起post请求

Hello. I have implemented background delivery for detecting changes in health kit with HKObserverQuery. It works well, I am reading changes. And I am sending this changes to an https endpoint with using an URLSession.shared.dataTask inside the HKObserverQuery callback while my app is terminated. I have several questions about this: Is starting a URLSession.shared.dataTask inside HKObserverQuery callback is correct way to do it? I am calling HKObserverQuery completion handler whatever dataTask returned success or failure but I am wondering what if the network connection is low and this dataTask response could not received in 2-3 seconds. I have read HealthKit background deliveries should take 1-2 seconds. Should I use background task somehow for sending those HTTPS requests?

Hello. I have implemented background delivery for detecting changes in health kit with HKObserverQuery. It works well, I am reading changes. And I am sending this changes to an https endpoint with using an URLSession.shared.dataTask inside the HKObserverQuery callback while my app is terminated. I have several questions about this: Is starting a URLSession.shared.dataTask inside HKObserverQuery callback when app is terminated is correct way to do it? I am calling HKObserverQuery completion handler whatever dataTask returned success or failure but I am wondering what if the network connection is low and this dataTask response could not received in 2-3 seconds. I have read background deliveries should take 1-2 seconds. Should I use an URL session with background configuration for sending those HTTPS requests? If so, should I use download task or upload task (they don't fit my requirements I am sending a simple json)?

My app does really large uploads. Like several GB. We use the AWS SDK to upload to S3. It seemed like using BGContinuedProcessingTask to complete a set of uploads for a particular item may improve UX as well as performance and reliability. When I tried to get BGContinuedProcessingTask working with the AWS SDK I found that the task would fail after maybe 30 seconds. It looked like this was because the app stopped receiving updates from the AWS upload and the task wants consistent updates. The AWS SDK always uses a background URLSession and this is not configurable. I understand the background URLSession runs in a separate process from the app and maybe that is why progress updates did not continue when the app was in the background. Is it expected that BGContinuedProcessingTask and background URLSession are not really compatible? It would not be shocking since they are 2 separate background APIs. Would the Apple recommendation be to use a normal URLSession for this, in which case AWS would need to change their SDK? Or does Apple think that BGContinuedProcessingTask should just not be used with uploads? In other words use an upload specific API. Thanks!

We are experiencing an issue with Safari in all versions from 18.0 to 18.5 that does not occur in version 17. It affects both iPhones and Macs. And does not happen in Chrome or Windows. The problem is impacting our customers, and our monitoring tools show a dramatic increase in error volume as more users buy/upgrade to iOS 18. The issue relates to network connectivity that is lost randomly. I can reliably reproduce the issue online in production, as well as on my local development environment. For example our website backoffice has a ping, that has a frequency of X seconds, or when user is doing actions like add to a cart increasing the quantity that requires backend validation with some specific frequency the issue is noticable... To test this I ran a JS code to simulate a ping with a timer that calls a local-dev API (a probe that waits 2s to simulate "work") and delay the next HTTP requests with a dynamic value to simulate network conditions: Note: To even make the issue more clear, I'm using GET with application/json payload to make the request not simple, and require a Pre-flight request, which doubles the issue. (async () => { for (let i = 0; i < 30; i++) { try { console.log(`Request start ${i} ${new Date().toLocaleString()}`); const res = await fetch(`https://api.redated.com:8090/1/*****/probe?`, { method: 'GET', mode: "cors", //headers: {'Content-Type': 'text/plain'}, headers: { 'Content-Type': 'application/json' }, }); console.log(`Request end ${i} ${new Date().toLocaleString()} status:`, res.status); } catch (err) { console.error(`Request ${i} ${new Date().toLocaleString()} error:`, err); } let delta = Math.floor(Math.random() * 10); console.log("wait delta",delta); await new Promise(r => setTimeout(r, 1000 - delta)); } })(); For simplicity lets see a case where it fails 1 time only out of 10 requests. (Adjusting the "delta" var on the time interval create more or less errors...) This are the results: The network connection was lost error, which is false, since this is on my localhost machine, but this happens many times and is very reproducible in local and production online. The dev-tools and network tab shows empty for status error, ip, connection_id etc.. its like the request is being terminated very soon. Later I did a detailed debugging with safari and wireshark to really nail down the network flow of the problem: I will explain what this means: Frame 10824 – 18:52:03.939197: new connection initiated (SYN, ACK, ECE). Frame 10831 – 18:52:04.061531: Client sends payload (preflight request) to the server. Frame 10959 – 18:52:09.207686: Server responds with data to (preflight response) to the client. Frame 10960 – 18:52:09.207856: Client acknowledges (ACK) receipt of the preflight response. Frame 10961 – 18:52:09.212188: Client sends the actual request payload after preflight OK and then server replies with ACK. Frame 11092 – 18:52:14.332951: Server sends the final payload (main request response) to the client. Frame 11093 – 18:52:14.333093: captures the client acknowledging the final server response, which marks the successful completion of the main request. Frame 11146 – 18:52:15.348433: [IMPORTANT] the client attempts to send another new request just one second later, which is extremely close to the keep-alive timeout of 1 second. The last message from the server was at 18:52:14.332951, meaning the connection’s keep-alive timeout is predicted to end around 18:52:15.332951 but it does not. The new request is sent at 18:52:15.348433, just microseconds after the predicted timeout. The request leaves before the client browser knows the connection is closed, but by the time it arrives at the server, the connection is already dead. Frame 11147 – 18:52:15.356910: Shows the server finally sending the FIN,ACK to indicate the connection is closed. This happens slightly later than the predicted time, at microsecond 356910 compared to the expected 332951. The FIN,ACK corresponds to sequence 1193 from the ACK of the last data packet in frame 11093. Conclusions: The root cause is related to network handling issues, when the server runs in a setting of keep-alive behavior and keep-alive timeout (in this case 1s) and network timming issue with Safari reusing a closed connection without retrying. In this situation the browser should retry the request, which is what other browsers do and what Safari did before version 18, since it did not suffer from this issue. This behaviour must differ from previous Safari versions (however i read all the public change logs and could not related the regression change). Also is more pronounced with HTTP/1.1 connections due to how the keep-alive is handled. When the server is configured with a short keep-alive timeout of 1 second, and requests are sent at roughly one-second intervals, such as API pings at fixed intervals or user actions like incrementing a cart quantity that trigger backend calls where the probability of failure is high. This effect is even more apparent when the request uses a preflight with POST because it doubles the chance, although GET requests are also affected. This was a just a test case, but in real production our monitoring tools started to detect a big increment with this network error at scale, many requests per day... which is very disrupting, because user actions are randomly being dropped when the user actions and timming happens to be just near a previous connection, where keep alive timeout kicks-in, but because the browser is not yet notified it re-uses the same connection, but by the time it arrived the server is a dead connection. The safari just does nothing about it, does not even retry, be it a pre-flight or not, it just gives this error. Other browsers don't have this issue. Thanks!

Hello, I am currently investigating if we can disable usage of QUIC on application level. I know we can set enable_quic from /Library/Preferences/com.apple.networkd.plist to false but it will have a global impact since this is a system file, all the applications on machine will stop using QUIC. I don't want that. What i am looking for is to disable QUIC only for my application. Is there any way i can modify URLSession object in my application and disable QUIC? or modify URLSessionConfiguration so system will not use QUIC?

We are experiencing a large number of crashes in our production environment, mainly occurring on iOS 16 systems and iPhone 8 and iPhone X devices. The crash log and stack trace are as follows: Error: Assertion failed: (false) function _onqueue_rdar53306264_addWaiter file TubeManager.cpp line 1042 Crashed: com.apple.CFNetwork.LoaderQ 0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8 1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208 2 libsystem_c.dylib 0x1c4b8 abort + 124 3 libsystem_c.dylib 0x70d8c err + 266 4 CFNetwork 0x1eb80 CFURLRequestSetMainDocumentURL + 6288 5 CFNetwork 0x44fd8 CFURLCacheRemoveAllCachedResponses + 22624 6 CFNetwork 0x39460 _CFHostIsDomainTopLevel + 968 7 CFNetwork 0x1f754 CFURLRequestSetMainDocumentURL + 9316 8 CFNetwork 0x233e0 CFURLRequestSetRequestPriority + 8792 9 CFNetwork 0x20d38 CFURLRequestCopyHTTPRequestBodyStream + 1612 10 CFNetwork 0x4f950 CFHTTPCookieStorageCopyCookies + 16276 11 CFNetwork 0x15878 CFURLRequestSetURL + 7600 12 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24 13 libdispatch.dylib 0x64780 _dispatch_client_callout + 16 14 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600 15 libdispatch.dylib 0x401e4 _dispatch_lane_invoke$VARIANT$armv81 + 432 16 libdispatch.dylib 0x41304 _dispatch_workloop_invoke$VARIANT$armv81 + 1620 17 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608 18 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284 19 libsystem_pthread.dylib 0x1720 start_wqthread + 8 Have you encountered a similar issue before?

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?

Body:
Hi all, I’m seeing a puzzling discrepancy in behavior between NSURLSession (with multipathServiceType = NSURLSessionMultipathServiceTypeInteractive) and WKWebView when the device is connected to a Wi-Fi SSID that has no internet (e.g., a hardware device’s AP). I have the Multipath entitlement properly enabled, and in this scenario: NSURLSession requests automatically fall back to cellular and succeed (no user intervention, fast switch). WKWebView loads fail or stall: the web content does not appear, and it seems like the web view is not using the cellular path even though the system network path becomes satisfied and real Internet reachability is confirmed. Environment: iOS version: (e.g., iOS 18.4) Device: (e.g., iPhone 15 Pro) Multipath entitlement: enabled in the app, using NSURLSessionMultipathServiceTypeInteractive Connected SSID: hardware device Wi-Fi with no external internet Expected fallback: automatic to cellular once the Wi-Fi has no internet, as observed with NSURLSession What I’ve done / observed: NSURLSession using Multipath works as expected:
NSURLSessionConfiguration *cfg = [NSURLSessionConfiguration defaultSessionConfiguration];
cfg.multipathServiceType = NSURLSessionMultipathServiceTypeInteractive;
NSURLSession *session = [NSURLSession sessionWithConfiguration:cfg];
NSURLRequest *req = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.apple.com/library/test/success.html"]];
NSURLSessionDataTask *task = [session dataTaskWithRequest:req completionHandler:^(NSData *data, NSURLResponse *resp, NSError *err) {
NSLog(@"NSURLSession result: %@, error: %@", resp, err);
}];
[task resume];
When connected to the device Wi-Fi (no external internet), the session quietly shifts to cellular and completes successfully. WKWebView fails to load under the same conditions:
[self.webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.apple.com/library/test/success.html"]]];
The web view either shows a load failure or just hangs, even though lower-level monitoring reports that the network path is satisfied and real Internet connectivity is available. Network path monitoring logic: I use the C API nw_path_monitor to watch for nw_path_status_satisfied. Once satisfied is observed, I perform a true connectivity check using nw_connection (e.g., connecting tohttps://www.apple.com/library/test/success.html) to verify that real Internet traffic can flow over cellular. That check passes, confirming fallback to cellular, but WKWebView still does not load content. Meanwhile, NSURLSession requests in the same condition succeed immediately. Sample logging trace:
[+] nw_path_status_satisfied=1, hasWiFi=1, hasCellular=1
[+] Internet connectivity test: ready (via nw_connection)
[-] WKWebView load failed / stalled
[+] NSURLSession request completed successfully Questions: Why does NSURLSession with the multipath service type seamlessly use cellular when the Wi-Fi has no internet, but WKWebView does not exhibit the same fallback behavior? Is WKWebView not honoring the system’s multipath fallback the same way? Does it use a different networking stack or ignore the multipath entitlement in this scenario? Is there a supported way to force WKWebView to behave like NSURLSession here? For example, can I bridge content through a multipath-enabled NSURLSession and inject it into WKWebView via a custom scheme? Are there any WKWebView configuration flags, preferences, or policies that enable the same automatic interface switching? Are there known limitations or documented differences in how WKWebView handles network interface switching, path satisfaction, or multipath compared to raw NSURLSession? What I’ve ruled out / tried: Verified the Multipath entitlement is included and active. Confirmed network path is “satisfied” and that real Internet reachability succeeds before calling [webView loadRequest:]. Delayed the WKWebView load until after connectivity verification. Observed that NSURLSession requests succeed under identical connectivity conditions. Any insight into internal differences, recommended workarounds, or Apple-recommended patterns for making web content robust in a “Wi-Fi with no internet” + automatic fallback-to-cellular scenario would be greatly appreciated. Thank you!

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 have FileProvider based MacOS application, where user is trying to copy the folder having mix of small and large files. Large files are having size ~ 1.5 GB from FileProvider based drive to locally on Desktop. Since the folder was on cloud and not downloaded the copy action triggered the download. Small files were downloaded successfully however during large file download the URLSession timed out. We are using default timeout for URLSession which is 1 min. I tried to capture logs Console.app where i found FileProvider daemon errors. PFA Solutions tried so far: Increased timeout for URLSession from 5 to 10 mins - configuration.timeoutIntervalForRequest Set timeout for resource - configuration.timeoutIntervalForResource It happens when we have low network bandwidth. Network connectivity is there but the bandwidth is low. Any clue by looking at these errors?

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.

If I was to build an app that opened a web server at local host on a random port that resolved subdomains for local host at that port, but there was no certificate authority, signed certificate available to provide HTTPS security, would this be in violation of apples ATS policy

Our app connects to the headend to get a IDP login URL for each connection session, for example: “https://myvpn.ocwa.com/+CSCOE+/saml/sp/login?ctx=3627097090&acsamlcap=v2” and then open embedded webview to load the page. (Note: the value of ctx is session token which changes every time). Quite often the webview shows blank white screen. After user cancel the connection and re-connect, the 2nd time webview loads the content successfully. The working case logs shows: didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called twice didReceiveAuthenticationChallenge is called decidePolicyForNavigationResponse is called didReceiveAuthenticationChallenge is called But the failure case shows: Filed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x11461c240 {Error Domain=RBSRequestErrorDomain Code=3 "No such process found" UserInfo={NSLocalizedFailureReason=No such process found}}} didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called decidePolicyForNavigationResponse is called If we stop calling evaluateJavaScript code to get userAgent, the blank page happens less frequently. Below is the code we put in makeUIView(): func makeUIView(context: Context) -> WKWebView { if let url = URL(string: self.myUrl) { let request = URLRequest(url: url) webview.evaluateJavaScript("navigator.userAgent") { result, error in if let error = error { NSLog("evaluateJavaScript Error: \(error)") } else { let agent = result as! String + " " + self.myUserAgent webview.customUserAgent = agent webview.load(request) } } } return self.webview } Found some posts saying call evaluateJavaScript only after WKWebView has finished loading its content. However, it will block us to send the userAgent info via HTTP request. And I don’t think it is the root cause since the problem still occurs with less frequency. There is no problem to load same web page on Windows desktop and Android devices. The problem only occurs on iOS and macOS which both use WKWebview APIs. Is there a bug in WKWebview? Thanks, Ying

Starting with iOS 18.3, we are getting infrequent crash reports somehow related to web sockets. Are there any new caveats we should be aware of or is it just a CFNetwork bug? Incident Identifier: 0D4343CE-3089-4514-841D-80CEC353B6B8 Distributor ID: com.apple.AppStore Hardware Model: iPhone16,2 AppStoreTools: 16C7015 AppVariant: 1:iPhone16,2:18 Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Date/Time: 2025-03-18 15:42:14.1732 -0400 Launch Time: 2025-03-15 20:38:20.7015 -0400 OS Version: iPhone OS 18.3.1 (22D72) Release Type: User Baseband Version: 2.40.05 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4373233664 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 104aa4000-104aa8000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/EDB47FCF-9E2C-4BE3-A771-F6F84BFCAF31/<redacted> Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [4454] Thread 10 Crashed: 0 CFNetwork 0x0000000193c46aac -[__NSURLSessionWebSocketTask _onqueue_receiveMessageWithCompletionHandler:] + 256 (LocalWebSocketTask.mm:486) 1 CFNetwork 0x0000000193c438b0 -[__NSURLSessionWebSocketTask _onqueue_ioTick] + 636 (LocalWebSocketTask.mm:355) 2 CFNetwork 0x0000000193c46918 __67-[__NSURLSessionWebSocketTask receiveMessageWithCompletionHandler:]_block_invoke + 356 (LocalWebSocketTask.mm:97) 3 libdispatch.dylib 0x000000019a2e9248 _dispatch_call_block_and_release + 32 (init.c:1549) 4 libdispatch.dylib 0x000000019a2eafa8 _dispatch_client_callout + 20 (object.m:576) 5 libdispatch.dylib 0x000000019a2f25cc _dispatch_lane_serial_drain + 768 (queue.c:3934) 6 libdispatch.dylib 0x000000019a2f3158 _dispatch_lane_invoke + 432 (queue.c:4025) 7 libdispatch.dylib 0x000000019a2fe38c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 8 libdispatch.dylib 0x000000019a2fdbd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 9 libsystem_pthread.dylib 0x000000021d2e4680 _pthread_wqthread + 288 (pthread.c:2696) 10 libsystem_pthread.dylib 0x000000021d2e2474 start_wqthread + 8 (:-1) Thread 10 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x00000000000003f0 x3: 0x0000000000000001 x4: 0x0000000000000010 x5: 0x00000000b04d793d x6: 0x00000000000013c0 x7: 0x0000000000000000 x8: 0x0000000000000378 x9: 0x0000000000000001 x10: 0x00000001fabc6b40 x11: 0x000000000000000f x12: 0x0000000000ddf700 x13: 0x000000012a1bc1c0 x14: 0x00000001fabc9798 x15: 0x00000001fabc9798 x16: 0x000000018faa1c4c x17: 0x000000019a2ea664 x18: 0x0000000000000000 x19: 0x0000000303a83420 x20: 0x0000000000000000 x21: 0x000000012b42d900 x22: 0x00000001fc8000a8 x23: 0x00000001fc8000a8 x24: 0x00000003036913c0 x25: 0x00000003036913c0 x26: 0x0000000000000001 x27: 0x0000000303afc870 x28: 0x0000000000000001 fp: 0x000000016b95a1f0 lr: 0x0000000193c46a04 sp: 0x000000016b95a170 pc: 0x0000000193c46aac cpsr: 0x40001000 esr: 0x92000006 (Data Abort) byte read Translation fault

We are developing an iOS application that is interacting with HTTP APIs that requires us to put a unique UUID (a nonce) as an header on every request (obviously there's more than that, but that's irrilevant to the question here). If the same nonce is sent on two subsequent requests the server returns a 412 error. We should avoid generating this kind of errors as, if repeated, they may be flagged as a malicious activity by the HTTP APIs. We are using URLSession.shared.dataTaskPublisher(for: request) to call the HTTP APIs with request being generated with the unique nonce as an header. On our field tests we are seeing a few cases of the same HTTP request (same nonce) being repeated a few seconds on after the other. Our code has some retry logic only on 401 errors, but that involves a token refresh, and this is not what we are seeing from logs. We were able to replicate this behaviour on our own device using Network Link Conditioner with very bad performance, with XCode's Network inspector attached we can be certain that two HTTP requests with identical headers are actually made automatically, the first request has an "End Reason" of "Retry", the second is "Success" with Status 412. Our questions are: can we disable this behaviour? can we provide a new request for the retry (so that we can update headers)? Thanks, Francesco

This happens when trying to connect to my development web server. The app works fine when connecting to my production server. The production server has a certificate purchased from a CA. My development web server has a locally generated certificate (from mkcert). I have dragged and dropped the rootCA.pem onto the Simulator, although it doesn't indicate it has been loaded the certificate does appear in the Settings app and is checked to be trusted. I have enabled "App Sandbox" and "Outgoing connections (Client)". I have tested the URL from my local browser which is working fine. What am I missing?

Question: What is the standard, most reliable way to manage temporary files associated with a URLSessionDownloadTask that has been terminated abnormally due to a network error or other issues? Details Hello, I'm currently developing a feature to download multiple files concurrently on iOS using URLSessionDownloadTask, and I have a question regarding the lifecycle of the temporary files created during this process. As I understand it, URLSessionDownloadTask stores incoming data in a temporary file within the tmp directory, typically with a name like CFNetworkDownload_*.tmp. In my testing, temporary files are managed correctly in the normal scenario. For instance, when I call the cancel() method on an active downloadTask and then release all references to it, the corresponding temporary file is automatically cleaned up from the tmp directory shortly after. However, the problem occurs when a download is interrupted abnormally due to external factors, such as a lost network connection. In this situation, the urlSession(_:task:didCompleteWithError:) delegate method is called, but the associated temporary file is not deleted and remains in the tmp directory. I've observed a particularly interesting behavior related to this. Immediately after the error occurs, if I check my app's storage usage in the iOS Settings app, the data size appears to have decreased momentarily. However, the tmp file has not actually been deleted, and after a short while, the storage usage is recalculated to include the size of this orphaned temporary file. Since my app does not support resuming interrupted downloads, these leftover files become orphaned and unnecessarily consume storage. Therefore, I want to ensure they are all reliably deleted. With this context, I'd like to ask the community: What is the standard, most reliable way to manage temporary files associated with a URLSessionDownloadTask that has been terminated abnormally due to a network error or other issues? I am wondering if there is an official guide or a framework-level API to handle these orphaned files. I would appreciate any advice from those with experience in this area. Thank you.

(related post: How to optimize my app for for a carrier-provided satellite network? ) I am trying to implement an app so that it works under a carrier-provided satellite network. The app uses (AS)WebAuthenticationSession for signing in. If the app is entitled to access a satellite network, will (AS)WebAuthenticationSession work as well? How about WKWebView and SFSafariViewController? Is there a way to test(simulate) a ultra-constrained network on a device or a simulator to see the expected behavior? Thanks,