General: DevForums 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 DevForums 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 Extra-ordinary Networking DevForums post Foundation networking: DevForums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Network framework: DevForums 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 DevForums 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: DevForums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: DevForums 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 DevForums tags: 5G, QUIC, Bonjour On FTP DevForums post Using the Multicast Networking Additional Capability DevForums post Investigating Network Latency Problems DevForums post WirelessInsights framework documentation iOS Network Signal Strength Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

But the NMI and NDI of Samsung's Wi Fi Aware are not the same MAC address. May I ask Apple engineers why they are different from Samsung？

Hi. We are writing to report a critical issue we've encountered following the recent release of iOS 26 beta 6. After updating our test devices, we discovered that our application is no longer able to establish HTTPS connections to several of our managed FQDNs. This issue was not present in beta 5 and appears to be a direct result of changes introduced in beta 6. The specific FQDNs that are currently unreachable are: d.socdm.com i.socdm.com tg.scodm.com We have reviewed the official iOS & iPadOS 26 Beta 6 Release Notes, particularly the updates related to TLS. While the notes mention changes, we have confirmed that our servers for all affected FQDNs support TLS 1.2, so we believe they should still be compliant. We have also investigated several of Apple's support documents regarding TLS connection requirements (e.g., HT214774, HT214041), but the information does not seem to apply to our situation, and we are currently unable to identify the root cause of this connection failure. https://support.apple.com/en-us/102028 https://support.apple.com/en-us/103214 Although we hope this issue might be resolved in beta 7 or later, the official release is fast approaching, and this has become a critical concern for us. Could you please provide any advice or insight into what might be causing this issue? Any guidance on potential changes in the networking or security frameworks in beta 6 that could affect TLS connections would be greatly appreciated. We have attached the relevant code snippet that triggers the error, along with the corresponding Xcode logs, for your review. Thank you for your time and assistance. #import "ViewController.h" @interface ViewController () @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; NSURL *url = [NSURL URLWithString:@"https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js"]; NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:30.0]; [self sendWithRequest:req completionHandler:^(NSData *_Nullable data, NSHTTPURLResponse *_Nonnull response, NSError *_Nullable error) { if (error){ NSLog(@"Error occurred: %@", error.localizedDescription); return; }else{ NSLog(@"Success! Status Code: %ld", (long)response.statusCode); } }]; } - (void) sendWithRequest:(NSMutableURLRequest *)request completionHandler:(void (^ _Nullable)(NSData *_Nullable data, NSHTTPURLResponse *response, NSError *_Nullable error))completionHandler { NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration]; NSURLSession *session = nil; session = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:nil]; NSURLSessionTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { [session finishTasksAndInvalidate]; NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response; if (error) { if (completionHandler) { completionHandler(nil, httpResponse, error); } } else { if (completionHandler) { completionHandler(data, httpResponse, nil); } } }]; [task resume]; } @end error Connection 1: default TLS Trust evaluation failed(-9807) Connection 1: TLS Trust encountered error 3:-9807 Connection 1: encountered error(3:-9807) Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> HTTP load failed, 0/0 bytes (error code: -1202 [3:-9807]) Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> finished with error [-1202] Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>", "<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>" ), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSErrorFailingURLStringKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSUnderlyingError=0x1062bf960 {Error Domain=kCFErrorDomainCFNetwork Code=-1202 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x10609d140>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9807, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9807, kCFStreamPropertySSLPeerCertificates=( "<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>", "<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>" )}}, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>" ), _kCFStreamErrorCodeKey=-9807, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x10609d140>, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk.} Error occurred: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk. 折りたたむ

我的完整报错信息： 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请求

Our goal is to establish a Wi‑Fi Aware data path (NDP) between Apple and Android devices. Apple will act as the Publisher, and Android will act as the Subscriber. Apple-to-Android pairing has already been completed. The Android device can be normally displayed on the Apple official Wi-Fi Aware Sample. However, the indicator is not green. During pairing, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingSetupSucceeded. During pairing verification, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingVerificationSucceed. The Android side sends an NDP request to Apple (as shown in the figure 1), but Apple does not reply. Note: Qualcomm’s NDI and NMI are different. In addition, after Apple-to-Apple pairing is completed, the paired device will be recorded in “Settings → Privacy &amp; Security → Paired Devices”. However, after Android-to-Apple pairing is completed, the device is not saved to this list. My iPhone model: iPhone 13, iOS 26.0 (23A5287g).

After Apple-to-Apple pairing is completed, the paired device will be recorded in “Settings → Privacy &amp; Security → Paired Devices”. However, after Android-to-Apple pairing is completed, the device is not saved to this list. Android device can be normally displayed on the Apple official Wi-Fi Aware Sample. However, the indicator is not green. During pairing, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingSetupSucceeded. During pairing verification, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingVerificationSucceed. My iPhone is iPhone 13， iOS 26.0 （23A5287g）

This is a major issue. After my iPhone 12 Pro was upgraded to iOS 26 beta 6, Apple's official Wi-Fi Aware Sample APP crashed immediately and couldn't be opened. It just force closes. Has any developer encountered this problem?

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 () =&gt; { for (let i = 0; i &lt; 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 =&gt; 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 new to App development, so I am looking for some advice. I want to develop an app for iPhone, which downloads files (pdf, jpg)from a server to the local storage. I also want to get data from the server to be used in my app. This could be a database access or just simple xml files. I want a secure access based on userid and password. Since in a later version, my app should also run on Android Phones, I am reluctant to use iCloud. I was thinking sftp, but that does not seem to be supported for iOS.

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?

I am trying to setup remote Java debugging between two machines running macOS (15.6 and 26). I am able to get the Java program to listen on a socket. However, I can connect to that socket only from the same machine, not from another machine on my local network. I use nc to test the connection. It reports Connection refused when trying to connect from the other machine. This issue sounds like it could be caused by the Java program lacking Local Network system permission. I am familiar with that issue arising when a program attempts to connect to a port on the local network. In that case, a dialog is displayed and System Settings can be used to grant Local Network permission to the client program. I don't know whether the same permission is required on the program that is receiving client requests. If it is, then I don't know how to grant that permission. There is no dialog, and System Settings does not provide any obvious way to grant permission to a program that I specify. Note that a Java application is a program run by the java command, not a bundled application. The java command contains a hard-wired Info.plist which, annoyingly, requests permission to use the microphone, but not Local Network access.

I'm writing an application that implements a Bonjour service and browser for the purpose of connecting to Logic Pro and interacting with a MIDI Device Script. Because it's connecting to Logic Pro running on the same system as the application, the service and browser do not need to access anything else on the local network. I'm creating the service and browser with calls like this: err = DNSServiceRegister( &serviceRef, 0, kDNSServiceInterfaceIndexLocalOnly, "MyService", "_osc._udp", "local", nullptr, 52854, txtLen, txtRecord, static_cast<DNSServiceRegisterReply>(myCallback), context ); err = DNSServiceBrowse( &browserRef, 0, kDNSServiceInterfaceIndexLocalOnly, "_osc._udp", nullptr, static_cast<DNSServiceBrowseReply>(browserCallback), context ); Despite the fact that I'm passing in kDNSServiceInterfaceIndexLocalOnly for the network interface, it still triggers an "Allow 'Application' to find devices on local networks?" permissions prompt. How can I avoid that prompt? It is both a significant failure point (in case users don't notice it or click 'Don't Allow' by mistake) but it may also scare them away, since it strongly implies my application is scanning devices on the local network, even though it's doing no such thing!

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

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

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?

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

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?

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

With Let's Encrypt having completely dropped support for OCSP recently [1], I wanted to ask if macOS has a means of keeping up to date with their CRLs and if so, roughly how often this occurs? I first observed an issue where a revoked-certificate test site, "revoked.badssl.com" (cert signed by Let's Encrypt), was not getting blocked on any browser, when a revocation policy was set up using the SecPolicyCreateRevocation API, in tandem with the kSecRevocationUseAnyAvailableMethod and kSecRevocationPreferCRL flags. After further investigation, I noticed that even on a fresh install of macOS, Safari does not block this test website, while Chrome and Firefox (usually) do, due to its revoked certificate. Chrome and Firefox both have their own means of dealing with CRLs, while I assume Safari uses the system Keychain and APIs. I checked cert info for the site here [2]. It was issued on 2025-07-01 20:00 and revoked an hour later. [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=revoked.badssl.com

I am developing an iOS application using NWPathMonitor for network connectivity monitoring. We discovered a reproducible issue where disabling and re-enabling WiFi triggers an unexpected network status sequence. ENVIRONMENT: iOS Version: 17.x Device: iPhone (various models tested) Network Framework: NWPathMonitor from iOS Network framework STEPS TO REPRODUCE: Device connected to WiFi normally Disable WiFi via Settings or Control Center Re-enable WiFi via Settings or Control Center EXPECTED BEHAVIOR: WiFi reconnects and NWPathMonitor reports stable satisfied status ACTUAL BEHAVIOR: T+0s: WiFi re-enables, NWPathMonitor reports path.status = .satisfied T+8s: NWPathMonitor unexpectedly reports path.status = .unsatisfied with unsatisfiedReason = .notAvailable T+9-10s: NWPathMonitor reports path.status = .satisfied again Connection becomes stable afterward NETWORK PATH TIMELINE: T+0s: satisfied (IPv4: true, DNS: false) T+140ms: satisfied (IPv4: true, DNS: true) T+8.0s: unsatisfied (reason: notAvailable, no interfaces available) T+10.0s: satisfied (IPv4: true, DNS: true) KEY OBSERVATIONS: Timing consistency: unsatisfied event always occurs ~8 seconds after reconnection resolution: "Reset Network Settings" eliminates this behavior TECHNICAL QUESTIONS: What causes the 8-second delayed unsatisfied status after WiFi re-enablement? Is this expected behavior that applications should handle? Why does reset network setting in iPhone fix this issue?

Hi everyone, I’m running a dual-homed IPv6-mostly LAN where two on-link routers advertise distinct global Provider-Assigned prefixes (one per ISP). On Linux, the host stack appears to follow RFC 8028. It keeps one default route per prefix, and packets appear to leave through a router that recognises their source address and pass ISP BCP 38 (https://datatracker.ietf.org/doc/bcp38/) checks. On macOS Sequoia, I'm only seeing a single un-scoped default route. As a result, traffic sourced from prefix B often exits via router A and is dropped upstream. Questions: Is the single-default-per-interface model in macOS an intentional design choice or simply legacy behaviour that has not yet been updated to RFC 8028? Does the kernel perform any hidden next-hop selection that isn’t reflected in netstat -rn output? Are there any road-map items for fully adopting RFC 8028 in macOS? As a bonus, I'd be very interested in any info you might be able to provide on the status of implementation/support for https://datatracker.ietf.org/doc/html/rfc8978 (Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events).