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.

Note Much of this content has been rolled into URL Loading System documentation, but I’m leaving this doc here for my own reference. URLSession background sessions are optimised for transferring a small number of large resources. Moreover, it’s best if the transfer is resumable. This design makes the best use of client device resources and the available network bandwidth. If your app runs a lot of tasks in a background session, you should rethink its design. Below you’ll find a number of options you might consider. Most of these options require server-side support. If your server does not have this support, and you can’t add it — perhaps you’re writing a client app for a server you don’t control — you won’t be able to implement these options directly. In that case consider creating your own server that sits between your app and the final server and implements the necessary smarts required to optimise your app’s network usage. If that’s not possible, a final option is to not use a background session but instead take advantage of the Background Tasks framework. See Background Tasks Framework, below. Basics The basic strategy here is to have the sender (the server for a download, your app for an upload) pack the data into some sort of archive, transfer that archive over the network, and then have the receiver unpack it. There are, however, a number of complications, as described in the subsequent sections. Archive Format The obvious choices for the archive format are zip and tar. macOS has lots of options for handling these formats but none of that support is present on iOS (r. 22151959). OTOH, it’s easy to find third-party libraries to fill in this gap. Incremental Transfers It’s common to have a corpus of data at one end of the connection that you need to replicate at the other. If the data is large, you don’t want to transfer the whole thing every time there’s an update. Consider using the following strategies to deal with this: Catalogue diff — In this approach the receiver first downloads a catalogue from the sender, then diffs its current state against that catalogue, then requests all the things that are missing. Alternatively, the receiver passes a catalogue of what it has to the sender, at which point the sender does the diff and returns the things that are missing. The critical part is that, once the diff has been done, all of the missing resources are transferred in a single archive. The biggest drawback here is resume. If the sender is working with lots of different receivers, each of which has their own unique needs, the sender must keep a lot of unique archives around so it can resume a failed transfer. This can be a serious headache. Versions — In this approach you manage changes to the data as separate versions. The receiver passes the version number it has to the sender, at which point the sender knows exactly what data the receiver needs. This approach requires a bit more structure but it does avoid the above-mentioned problem with resume. The sender only needs to maintain a limited number of version diffs. In fact, you can balance the number of diffs against your desire to reduce network usage: Maintaining a lot of diffs means that you only have to transfer exactly what the receiver needs, while maintaining fewer diffs makes for a simpler server at the cost of a less efficient use of the network. Download versus Upload The discussion so far has applied equally to both downloads and uploads. Historically, however, there was one key difference: URLSession did not support resumable uploads. IMPORTANT Starting with iOS 17, URLSession supports resumable uploads. See WWDC 2023 Session 10006 Build robust and resumable file transfers for the details. The rest of this section assumes that you don’t have access to that support, either because you’re working on an older system or because the server you’re uploading to doesn’t support this feature. When doing a non-resumable upload you have to balance the number of tasks you submit to the session against the negative effects of a transfer failing. For example, if you do a single large upload then it’s annoying if the transfer fails when it’s 99% complete. On the other hand, if you do lots of tiny uploads, you’re working against the URLSession background session design. It is possible to support resumable uploads with sufficient server-side support. For example, you could implement an algorithm like this: Run an initial request to allocate an upload ID. Start the upload with that upload ID. If it completes successfully, you’re done. If it fails, make a request with the upload ID to find out how much the server received. Start a new upload for the remaining data. Indeed, this is kinda how the built-in resumable upload support works. If you’re going to implement something like this, it’s best to implement that protocol. (r. 22323347) Background Tasks Framework If you’re unable to use an URLSession background session effectively, you do have an alternative, namely, combining a standard session with the Background Tasks framework. There are two options that you might find useful. The first is a processing task. This allows you to request extended background processing time from the system. Once you’ve been granted that time, use it to run your many small network requests in a standard session. The main drawback to this approach is latency: The system may not grant your request for many hours. Indeed, it’s common for these requests to run overnight, once the user has connected their device to a power source. The second is a continued processing task. This allow you to request continued execution in the background to complete a user-visible task that the user has started in the foreground. This approach has some limitations: You have to start the work when your app is in the foreground. The task is visible to the user, who can cancel it. The system may expire the task for its own reasons. Background Assets Framework If you’re using URLSession to download assets for your app or game, check out the Background Assets framework. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2026-05-27 Updated the Background Tasks Framework section to talk about continued processing task. 2023-09-27 Added information about the new resumable upload support. Added the Background Assets Framework section. Made significant editorial changes. 2022-01-31 Fixed the formatting and tags. Added a link to the official docs. 2018-03-24 Added the Background Tasks Framework section. Other editorial changes. 2015-08-18 First written.

Platform and Version Platform: iOS iOS Version: 17.0+ Development Environment: .NET MAUI (C#, .NET 9) Network Layer: HttpClient with HttpClientHandler Description of the Problem We are facing an issue where HttpClientHandler.ServerCertificateCustomValidationCallback is not being invoked when the app is in a terminated (kill) state. In normal app lifecycle states (foreground/background), the callback is triggered as expected and allows us to handle server certificate validation (e.g., for certificate pinning or custom validation logic). However, when the app is in a killed state and is relaunched due to a notification action, the callback does not execute. We would like to understand: Why ServerCertificateCustomValidationCallback is not invoked in this scenario Whether this behavior is expected within iOS networking/runtime constraints Any recommended approach or workaround to ensure certificate validation still occurs when handling notification-triggered flows from a terminated state Steps to Reproduce Ensure the app is force-terminated (kill mode) Configure a push notification with category: "INVITE_CATEGORY" Include custom notification action buttons Tap one of the custom actions This triggers app launch and network call using HttpClient Expected Behavior ServerCertificateCustomValidationCallback should be invoked during the network request initiated after tapping the notification action, allowing custom certificate validation.

I'm keeping most information in an actor and I would like to save also a closure in it that I get from func application( _ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) Task.init{ await GeoreferenceQueue.shared.setBackgroundCompletionHandler(completionHandler) } } where GeoreferenceQueue is and actor, while the caller is a class. yet I receive error: Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure and Sending task-isolated 'completionHandler' to actor-isolated instance method 'setBackgroundCompletionHandler' risks causing data races between actor-isolated and task-isolated uses

According to documentation, the URLSession background tasks continue even when the app is suspended. What is the lifespan of the URLSessionDownloadDelegate object when app is suspended or terminated? Will it get re-created and re-initialize properties when the app re-launches, or will it somehow restore the existing property values? Also, urlSessionDidFinishEvents not getting called, and what do we need to do there with the backgroundCompletionHandler? Any insights are much appreciated. We are getting ready to launch and this is a roadblock. (visionOS26.4) Thank you. @Observable class DownloadManager: NSObject, URLSessionDownloadDelegate { ... let config = URLSessionConfiguration.background(withIdentifier: "TestDL") config.sessionSendsLaunchEvents = true var urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil) func downloadFiles(... { // initiate multiple file downloads concurrently for url in urlList { let task = urlSession.downloadTask(with: url) task.resume() } } func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) { ... func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) { ... func urlSession(_: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) { ... // Not getting called ?? // Is this only called when app is suspended/terminated? func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) { print("didFinishEvents") Task { @MainActor in //urlSession?.finishTasksAndInvalidate() //urlSession = nil // not sure what to do here: if let appDelegate = UIApplication.shared.delegate as? AppDelegate, let completionHandler = appDelegate.backgroundCompletionHandler { completionHandler() appDelegate.backgroundCompletionHandler = nil } } }

Hello, I am investigating a recurring crash that appears to be originating within the system's network stack. OS Version: iPhone OS 26.1 (23B85) Role: Foreground Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Triggered by Thread: 19 Description: The crash is triggered by Thread 19 and occurs deep within libquic.dylib during a QUIC recovery timer event. Based on the backtrace, the failure happens in quic_recovery_pto. The issue seems to occur when a protocol instance schedules a wakeup, leading to a null pointer dereference in the system library. Crashed Thread Backtrace snippet:Thread 19 Crashed: Thread 19 Crashed: 0 libquic.dylib 0x00000001a00a38cc quic_recovery_pto + 72 (quic_recovery.c:1259) 1 libquic.dylib 0x00000001a00a3390 quic_recovery_timer_fired + 132 (quic_recovery.c:1460) 2 libquic.dylib 0x00000001a00a1f8c quic_timer_run + 248 (quic_timer.c:210) 3 Network 0x000000018ec76cbc __nw_protocol_instance_schedule_wakeup_block_invoke + 76 (protocol_implementation.cpp:5847) 4 Network 0x000000018eba34e0 __nw_context_reset_timer_block_with_time_block_invoke + 268 (context.cpp:2224) 5 libdispatch.dylib 0x00000001c84727ec _dispatch_client_callout + 16 (client_callout.mm:85) 6 libdispatch.dylib 0x00000001c845d664 _dispatch_continuation_pop + 596 (queue.c:349) 7 libdispatch.dylib 0x00000001c8470528 _dispatch_source_latch_and_call + 396 (source.c:601) 8 libdispatch.dylib 0x00000001c846f1fc _dispatch_source_invoke + 844 (source.c:966) 9 libdispatch.dylib 0x00000001c8463288 _dispatch_workloop_invoke + 1612 (queue.c:4761) 10 libdispatch.dylib 0x00000001c846c3ec _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265) 11 libdispatch.dylib 0x00000001c846bce4 _dispatch_workloop_worker_thread + 692 (queue.c:6859) 12 libsystem_pthread.dylib 0x00000001ec0623b8 _pthread_wqthread + 292 (pthread.c:2696) 13 libsystem_pthread.dylib 0x00000001ec0618c0 start_wqthread + 8 (:-1) Can anyone provide insights into what might be causing libquic to access an invalid address in this context? Any help or suggestions for further diagnostics would be greatly appreciated.

I've just implemented background session downloads, and in testing (with 1044 downloadTasks), I'm seeing some strange behavior that's not 100% reproducible. Sometimes when I background the app, when I foreground it (or the OS does), the URLSessionDownloadDelegate's function urlSession(_:downloadTask:didFinishDownloadingTo:) gets called twice. I'm also logging the URLSessionTaskDelegate's function urlSession(_:task:didCompleteWithError:) and in this case, it does not get called between calls to didFinishDownloadingTo. Both cases are being called with the exactly same task, session and location. The first call copies the location to a semi-permanent destination (and I confirmed that file is correct), and the second call fails on move because the destination already exists. I can obviously work around this fairly easily, but wondering if I'm missing something or if there's a bug. It does appear to happen more reliably when I background for 15 seconds or longer. A second issue which is reproducible is that while backgrounded, some files are completing downloads and never calling the download delegate's urlSession(_:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:) I tried resuming one or all of the tasks in applicationDidBecomeActive as suggested in multiple other forums posts, but neither of those seems to resolve the issue. Again, I can work around this (using a combination of totalBytesWritten and the known size of files which have completed downloads), but I'm wondering if I'm missing something obvious. I actually thought that perhaps the resume() workaround was causing the first issue, but removing it does not have an effect.

Our business interface requests require disabling HTTP(s) proxies. We configured URLSessionConfiguration.connectionProxyDictionary as before, but found that it does not work on iOS 26 1.Core code: let configuration = URLSessionConfiguration.default configuration.connectionProxyDictionary = [ "HTTPEnable": false, "HTTPSEnable": false, "SOCKSEnable": false, ] let session = URLSession(configuration: configuration) let request = URLRequest(url: URL(string: "https://www.baidu.com")!,timeoutInterval: Double.infinity) // 发送请求 let task = session.dataTask(with: request) { data, response, error in if let error = error { print("网络请求失败: \(error)") } if let data = data { print("网络请求成功，返回数据长度: \(data.count)") if let responseString = String(data: data, encoding: .utf8) { print("返回数据: \(responseString.prefix(100))...") } } } task.resume() 2.Specific steps: We captured traffic using Proxyman and Charles. With the same code, requests cannot be captured on iOS 18 and iOS 16.1, but can be captured on iOS 26.2 and 26.1. Conclusion:Therefore, we suspect there is a bug with URLSessionConfiguration.connectionProxyDictionary on iOS 26.x. Please let us know whether this is a bug. If not, how should we properly disable HTTP(s) proxies? Note: We need to exclude PAC proxies, which are commonly used in corporate internal networks. 3.Devices & Software Xcode 16.4 iPhone 26.2、Simulator 26.1 iPhone 16、Simulator 18.0、Simulator 18.6 Proxyman、Charles

Hello Apple Support Team, We are experiencing a performance issue with HTTP/3 in our iOS application during testing. Problem Description: Network requests using HTTP/3 are significantly slower than expected. This issue occurs on both Wi-Fi and 4G networks, with both IPv4 and IPv6. The same setup worked correctly in an earlier experiment. Key Observations: The slowdown disappears when the device uses: · A personal hotspot. · Network Link Conditioner (with no limitations applied). · Internet sharing from a MacBook via USB (where traffic was also inspected with Wireshark without issues). The problem is specific to HTTP/3 and does not occur with HTTP/2. The issue is reproducible on iOS 15, 18.7, and the latest iOS 26 beta. HTTP/3 is confirmed to be active (via assumeHttp3Capable and Alt-Svc header). Crucially, the same backend endpoint works with normal performance on Android devices and using curl with HTTP/3 support from the same network. I've checked the CFNetwork logs in the Console but haven't found any suspicious errors or obvious clues that explain the slowdown. We are using a standard URLSession with basic configuration. Attempted to collect qlog diagnostics by setting the QUIC_LOG_DIRECTORY=~/ tmp environment variable, but the logs were not generated. Question: What could cause HTTP/3 performance to improve only when the device is connected through a hotspot, unrestricted Network Link Conditioner, or USB-tethered connection? The fact that Android and curl work correctly points to an issue specific to the iOS network stack. Are there known conditions or policies (e.g., related to network interface handling, QoS, or specific packet processing) that could lead to this behavior? Additionally, why might the qlog environment variable fail to produce logs, and are there other ways to obtain detailed HTTP/3 diagnostic information from iOS? Any guidance on further diagnostic steps or specific system logs to examine would be greatly appreciated. Thank you for your assistance.

Some mobile phones frequently report an error "bad URL" with the domain set to NSURLErrorDomain and the code set to -1000. However, I never encounter this error, and I'm not sure what's going wrong，The error log is as follows: HttpInterceptor:81 didReceive(_:target:): moya error: underlying(Alamofire.AFError.sessionTaskFailed(error: Error Domain=NSURLErrorDomain Code=-1000 "bad URL" UserInfo={_kCFStreamErrorCodeKey=22, NSUnderlyingError=0x1119f91d0 {Error Domain=kCFErrorDomainCFNetwork Code=-1000 "(null)" UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: utun4[endc_sub6], ipv4, dns, uses cell, LQM: unknown, _kCFStreamErrorCodeKey=22, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <7FF86D00-1379-43D4-9F9B-0C300AEC57C8>.<4>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <7FF86D00-1379-43D4-9F9B-0C300AEC57C8>.<4>" ), NSLocalizedDescription=bad URL, NSErrorFailingURLStringKey=https://update.flashforge.com/api/updates/check?app_id=46&entity_id=9E8D3B0C-2E61-46AF-91B9-B4AFFACF2788&platform=23&version=v1.3.4, NSErrorFailingURLKey=https://update.flashforge.com/api/updates/check?app_id=46&entity_id=9E8D3B0C-2E61-46AF-91B9-B4AFFACF2788&platform=23&version=v1.3.4, _kCFStreamErrorDomainKey=1}), nil)

Our business interface requests require disabling HTTP(s) proxies. We configured URLSessionConfiguration.connectionProxyDictionary as before, but found that it does not work on iOS 16.2 and 16.3.1. 1.Core code: let configuration = URLSessionConfiguration.default configuration.connectionProxyDictionary = [ "HTTPEnable": false, "HTTPSEnable": false, "SOCKSEnable": false, ] let session = URLSession(configuration: configuration) let request = URLRequest(url: URL(string: "https://www.baidu.com")!,timeoutInterval: Double.infinity) // 发送请求 let task = session.dataTask(with: request) { data, response, error in if let error = error { print("网络请求失败: \(error)") } if let data = data { print("网络请求成功，返回数据长度: \(data.count)") if let responseString = String(data: data, encoding: .utf8) { print("返回数据: \(responseString.prefix(100))...") } } } task.resume() 2.Specific steps: We captured traffic using Proxyman and Charles. With the same code, requests cannot be captured on iOS 18 and iOS 16.1, but can be captured on iOS 26.2 and 26.1. Conclusion:Therefore, we suspect there is a bug with URLSessionConfiguration.connectionProxyDictionary on iOS 26.x. Please let us know whether this is a bug. If not, how should we properly disable HTTP(s) proxies? Note: We need to exclude PAC proxies, which are commonly used in corporate internal networks. 3.Devices & Soft Xcode 16.4 iPhone 26.2、Simulator 26.1 Proxyman、Charles

Summary On macOS 26.4.1 (25E253), iCloud Drive file uploads can enter a silent deadlock where every upload attempt fails at the transport layer. No error is surfaced anywhere — not in Finder, not in System Settings, not in the iCloud status panel. The upload queue simply stops. Other iCloud services (Photos, Mail, App Store) continue to work normally through the same networking infrastructure at the same time. Root Cause The issue is a stale HTTP/3 (QUIC) session cached in the user-level nsurlsessiond process's BackgroundConnectionPool. The deadlock cycle: cloudd requests an upload to the GCS storage endpoint nsurlsessiond provides the cached (broken) HTTP/3 session The TLS handshake succeeds, but the body upload dies mid-transfer (err=T, requestDuration=-1.000, responseHeaderBytes=0) cloudd retries with a new connectionUUID — but nsurlsessiond still routes through the same poisoned QUIC session This repeats indefinitely Killing cloudd alone does not help — nsurlsessiond retains the poisoned pool. Only killing both the user-level cloudd and nsurlsessiond clears the pool and forces a fresh protocol negotiation. The Smoking Gun After killing both daemons, the system falls back to HTTP/1.1 for the stuck uploads — and they complete instantly: Before Kill After Kill Protocol h3 (QUIC) http/1.1 (TCP) Largest upload Failed at partial offsets 26 MB in 1.6 seconds Server response 0 bytes 596 bytes (normal) Same endpoint, same files, same network interface (en5), same power state. The only change was the protocol negotiation after a fresh nsurlsessiond. Reproduction Reproduced 3 times on April 11, 2026 using a standardized set of 8 test files (8 bytes to 20 MB) in a non-shared iCloud Drive folder. Each run showed the identical pattern: Small files (<100 KB) squeeze through before the QUIC session stalls Larger files trigger the deadlock every time 5–6 retries with fresh connectionUUIDs, all failing over protocol=h3 After kill cloudd + nsurlsessiond: immediate flush via protocol=http/1.1 An automated evidence-collection script (collect_h3_deadlock_evidence.sh) captures paired before-kill / after-kill logs. Included in the Feedback report. Symptom Check (for others hitting this) /usr/bin/log show --predicate 'process == "cloudd"' --last 5m 2>&1 \ | grep "putContainer.*err=T.*requestDuration=-1.000.*protocol=h3" | wc -l Output > 0 = this deadlock. Output = 0 = different issue. Recovery (one-liner) kill $(ps -axo user,pid,command | awk -v u="$USER" \ '($1==u && /CloudKitDaemon.framework.*cloudd/ && !/--system/) \ || ($1==u && /\/usr\/libexec\/nsurlsessiond/ && !/--privileged/) \ {print $2}') Both daemons respawn within 1–2 seconds. Do not use killall nsurlsessiond — it would also kill the privileged system instance. What was ruled out Network connectivity (Photos uploaded 8 MB through the same pool simultaneously) iCloud account (metadata operations succeeding, only body uploads failing) File type/content (random data, correlation is with size, not type) Storage quota (1.65 TB free) CFNetworkHTTP3Enabled=false (key is ineffective in 26.4.1) Suggested fixes (from the Feedback report) CFNetwork: Invalidate the QUIC session after N consecutive requestDuration=-1.000 failures CloudKit/NSURLSession: Expose a pool invalidation API like [NSURLSession invalidatePoolEntryForEndpoint:] cloudd: Self-healing retry — create a fresh NSURLSession after M consecutive deadlock-signature failures Finder: At minimum, surface the stuck state to the user instead of failing silently Filed as FB22476701 — includes full reproduction timelines, request/connection UUIDs, sysdiagnose, and a 12-page investigation PDF with architecture diagrams and protocol comparison tables. If you're experiencing the same issue, please file a duplicate referencing FB22476701 — Apple prioritizes by duplicate count. System MacBook Air, macOS 26.4.1 (25E253) iCloud Drive with Desktop & Documents sync en0 (WLAN) + en5 (USB-LAN via Studio Display)

How do I make a basic request with URLSession? See https://stackoverflow.com/questions/30573898 for reference. Also https://developer.apple.com/documentation/ has details.

URLSession question

I'm encountering a null pointer dereference crash pointing to the internals of CFNetwork library code on iOS. I'm spawning URLSessionTasks at a decently fast rate (~1-5 per second), with the goal being to generate application layer network traffic. I can reliably encounter this crash pointing to NetConnection::dequeue right after a new task has been spawned and had the resume method called. I suspect that this is perhaps a race condition or some delegate/session object lifecycle bug. The crash appears to be more easily reproduced with a higher rate of spawning URLSessionTasks. I've included the JSON crash file, the lldb stack trace, and the source code of my URLSession(Task) usage. urlsession_stuff_stacktrace.txt urlsession_stuff_source.txt urlsession_crash_report.txt

com.apple.main-thread 0 StarMaker 0x5c40854 _isPlatformVersionAtLeast.cold.2 + 4425680980 1 StarMaker 0x526d278 -[FPRScreenTraceTracker displayLinkStep] + 191 (FPRScreenTraceTracker.m:191) 2 QuartzCore 0xbe924 CA::Display::DisplayLinkItem::dispatch(CA::SignPost::Interval<(CA::SignPost::CAEventCode)835322056>&) + 64 3 QuartzCore 0x9bf38 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 880 4 QuartzCore 0xaf770 CA::Display::DisplayLink::dispatch_deferred_display_links(unsigned int) + 360 5 UIKitCore 0x7dee4 _UIUpdateSequenceRunNext + 128 6 UIKitCore 0x7d374 schedulerStepScheduledMainSectionContinue + 60 7 UpdateCycle 0x1560 UC::DriverCore::continueProcessing() + 84 8 CoreFoundation 0x164cc __CFMachPortPerform + 168 9 CoreFoundation 0x460b0 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 60 10 CoreFoundation 0x45fd8 __CFRunLoopDoSource1 + 508 11 CoreFoundation 0x1dc1c __CFRunLoopRun + 2168 12 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 13 GraphicsServices 0x1498 GSEventRunModal + 120 14 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 15 UIKitCore 0x46e54 UIApplicationMain + 336 16 StarMaker 0x50c965c main + 18 (main.m:18) 17 ??? 0x19a9dae28 (缺少) Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x27d30 zorro::KbLog::Loop() + 88 (kblog.cc:88) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8 Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19a4e4 zorro::ZkbLog::Loop() + 157 (zlog.cc:157) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8 Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19c4d8 zorro::QosManager::Loop() + 966 (string:966) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8

We are developing a watchOS application that records long audio sessions and uploads them to our backend in chunks (~5 MB each) using pre-signed URLs and URLSession background upload. Current behavior: While audio recording is active, uploads continue successfully even when the app is in the background. Once the recording stops, if multiple chunks (e.g., 10+) are still pending, the remaining uploads do not proceed in the background and appear to be suspended. We attempted to use WKExtendedRuntimeSession (mindfulness type) to allow sufficient time to enqueue background upload tasks, but the session is invalidated when the app goes to the background (e.g., wrist down or app inactive), which prevents reliable scheduling of uploads. Additionally, we added the entitlement: com.apple.developer.extended-runtime-session (mindfulness) in the Watch app entitlements file, but Xcode automatic signing fails with: “Provisioning profile does not include the com.apple.developer.extended-runtime-session entitlement.” It appears that the provisioning profile is not being updated to include this entitlement. Our questions: Is WKExtendedRuntimeSession (mindfulness) expected to support scheduling background URLSession uploads after the app goes to background? How should we reliably complete pending background uploads on watchOS after a long recording session ends? Is there any additional entitlement or recommended approach for this use case? Why is the extended runtime entitlement not being applied to the provisioning profile despite being added in the entitlements file? We are aiming to follow Apple-recommended practices for long-running tasks and background uploads on watchOS. Any guidance would be greatly appreciated.

Hello there, Starting from iOS 18.4, support was included for QWAC Validation and QCStatements. Using the official QWAC Validator at: https://eidas.ec.europa.eu/efda/qwac-validation-tool I was able to check that the domain "eidas.ec.europa.eu" has a valid QWAC certificate. However, when trying to obtain the same result using the new API, I do not obtain the same result. Here is my sample playground code: import Foundation import Security import PlaygroundSupport PlaygroundPage.current.needsIndefiniteExecution = true @MainActor class CertificateFetcher: NSObject, URLSessionDelegate { private let url: URL init(url: URL) { self.url = url super.init() } func start() { let session = URLSession(configuration: .ephemeral, delegate: self, delegateQueue: nil) let task = session.dataTask(with: url) { data, response, error in if let error = error { print("Error during request: \(error)") } else { print("Request completed.") } } task.resume() } nonisolated func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -&gt; Void) { guard let trust = challenge.protectionSpace.serverTrust else { completionHandler(.cancelAuthenticationChallenge, nil) return } if let certificates = SecTrustCopyCertificateChain(trust) as? [SecCertificate] { self.checkQWAC(certificates: certificates) } let credential = URLCredential(trust: trust) completionHandler(.useCredential, credential) } nonisolated func checkQWAC(certificates: [SecCertificate]) { let policy = SecPolicyCreateSSL(true, nil) var trust: SecTrust? guard SecTrustCreateWithCertificates(certificates as CFArray, policy, &amp;trust) == noErr, let trust else { print("Unable to create SecTrust") return } var error: CFError? guard SecTrustEvaluateWithError(trust, &amp;error) else { print("Trust evaluation failed") return } guard let result = SecTrustCopyResult(trust) as? [String : Any] else { print("No result dictionary") return } let qwacStatus = result[kSecTrustQWACValidation as String] let qcStatements = result[kSecTrustQCStatements as String] print("QWAC Status: \(String(describing: qwacStatus))") print("QC Statements: \(String(describing: qcStatements))") } } let url = URL(string: "https://eidas.ec.europa.eu/")! let fetcher = CertificateFetcher(url: url) fetcher.start() Which prints: QWAC Status: nil QC Statements: nil Request completed. Am I making a mistake while using the Security framework? I would greatly appreciate any help or guidance you can provide.

I am referencing: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

Hi， Apps crashed when GCDAsyncSocket closeWithError，since iOS 16 。 Crash stack like this： Hardware Model: iPhone10,1 Code Type: ARM-64 (Native) Parent Process: [1] Date/Time: 2022-06-09 08:59:02.201 +0800 OS Version: 16.0 (20A5283p) Report Version: 104 Last Exception : 0 libsystem_platform.dylib 0x000000021bc1f08c 0x000000021bc19000 + 24716 1 libsystem_platform.dylib 0x000000021bc19898 0x000000021bc19000 + 2200 2 CoreFoundation 0x00000001a4dfa3e0 CFSocketInvalidate + 132 3 CFNetwork 0x00000001a5667830 _CFNetworkErrorGetLocalizedDescription + 307856 4 CoreFoundation 0x00000001a4d55f4c CFArrayApplyFunction + 72 5 CFNetwork 0x00000001a56453ac _CFNetworkErrorGetLocalizedDescription + 167436 6 CoreFoundation 0x00000001a4d5d118 0x00000001a4d49000 + 82200 7 CoreFoundation 0x00000001a4dfa718 CFSocketInvalidate + 956 8 CFNetwork 0x00000001a5651e84 _CFNetworkErrorGetLocalizedDescription + 219364 9 CoreFoundation 0x00000001a4d631d4 0x00000001a4d49000 + 106964 10 *** 0x000000010c1bc490 -[GCDAsyncSocket closeWithError:] + 260 11 *** 0x000000010c1c0b54 -[GCDAsyncSocket doReadEOF] + 360 12 *** 0x000000010c1bf1fc __69-[GCDAsyncSocket setupReadAndWriteSourcesForNewlyConnectedSocket:]_block_invoke + 88 13 libdispatch.dylib 0x00000001a4a330f4 0x00000001a4a2f000 + 16628 14 libdispatch.dylib 0x00000001a4a36584 0x00000001a4a2f000 + 30084 15 libdispatch.dylib 0x00000001a4a49b04 0x00000001a4a2f000 + 109316 16 libdispatch.dylib 0x00000001a4a3a684 0x00000001a4a2f000 + 46724 17 libdispatch.dylib 0x00000001a4a3b2f8 0x00000001a4a2f000 + 49912 18 libdispatch.dylib 0x00000001a4a45ebc 0x00000001a4a2f000 + 93884 19 libsystem_pthread.dylib 0x000000021bc210a8 _pthread_wqthread + 288