Getting -10985 error from urlSession while attempting to make a connection. Not sure why this is happening if anyone is aware please help

Hello all, Does anyone know how long it will take Apple to approve multicast entitlement approval after the Apple form is submitted? Any input would be appreciated. Thank you Allyson

Configure the App ID in the Apple Developer Portal. In the Network Extensions section, the Packet Tunnel section is not displayed, as shown in the figure below How to proceed with the configuration of App ID. In the Network Extensions section: Display the Packet Tunnel section Our account is a China region account

We're seeing an issue with bonjour services since macOS 15.4 onwards, specifically when running xcuitests on simulators that communicate with an app via bonjour services, the NWListener fails with -65555: NoAuth Interestingly it only fails on subsequent iterations of the test, first iteration always succeeds. The same code works fine on macOS 15.3.1 and earlier, but not 15.4 or 15.5. Is this related to, or the same issue as here? https://aninterestingwebsite.com/forums/thread/780655 Also raised in feedback assistant: FB17804120

On "Accessory Interface Specification CarPlay Addendum R10", it says that it is recommended that the accessory uses a MIMO (2x2) hardware configuration, does this imply that WiFi 5 and SISO (1X1) will be phased out in the near future? When will WiFi 6 MIMO (2x2) become mandatory? On "Accessory Interface Specification CarPlay Addendum R10", it says that Spatial Audio is mandatory. However, for aftermarket in-vehicle infotainment (IVI) system due to the number of speakers are less than 6, is it allowed not to support spatial audio for this type of aftermarket IVI system?

fetchCurrent(completionHandler:) https://aninterestingwebsite.com/documentation/networkextension/nehotspotnetwork/fetchcurrent(completionhandler:) The same code works fine in Xcode 16, but when I run the same project in Xcode 26, it doesn't work

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

When filtering traffic to localhost (127.0.0.1), it causes Maven repository synchronization to fail in IntelliJ IDEA. However, Maven works correctly when local traffic is not filtered. I will provide a minimal code reproduction below. - (void)startFilterWithCompletionHandler:(void (^)(NSError *error))completionHandler { // Add code to initialize the filter NSMutableArray *rules = [NSMutableArray array]; NENetworkRule * rule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolTCP direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:rule action:NEFilterActionFilterData]]; rule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolUDP direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:rule action:NEFilterActionFilterData]]; NWHostEndpoint *hostEndpointIpv4 = [NWHostEndpoint endpointWithHostname:@"127.0.0.1" port:@"0"]; NENetworkRule *localHostRuleIpv4 = [[NENetworkRule alloc] initWithRemoteNetwork:hostEndpointIpv4 remotePrefix:32 localNetwork:hostEndpointIpv4 localPrefix:32 protocol:NENetworkRuleProtocolAny direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:localHostRuleIpv4 action:NEFilterActionFilterData]]; NEFilterSettings *filterSetting = [[NEFilterSettings alloc] initWithRules:rules defaultAction:NEFilterActionAllow]; [self applySettings:filterSetting completionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"Failed to apply filter settring: %@", error.localizedDescription); } completionHandler(error); }]; } Maven Sync error: System Log: 默认 17:35:13.184509+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 3bb6402f58a82e37 - flags 0x800840 0x80> lport 63166 fport 29735 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.184510+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so d6dde374c8cb613b - flags 0x800840 0x80> lport 63165 fport 29735 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.529546+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so cc915e74ba29f8cb - flags 0x800840 0x80> lport 63169 fport 39066 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.529546+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 2e15c3e54ebcc45 - flags 0x800840 0x80> lport 63168 fport 39066 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:14.046094+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 71f6d3a53472131f - flags 0x800840 0x80> lport 63172 fport 53241 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:14.046145+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so c88a367c9717185b - flags 0x800840 0x80> lport 63171 fport 53241 laddr 127.0.0.1 faddr 127.0.0.1 Environment Details: Operating System: macOS 15.5 (Sequoia) IDE: IntelliJ IDEA 2025.1 Relevant Technology: NEFilterDataProvider (Network Extension) I have found reports of similar problems online： https://discussionschinese.apple.com/thread/255270330?sortBy=rank https://blog.csdn.net/weixin_42339552/article/details/137402307 They all seem to be caused by network extension。

I cannot find in the documentation and samples how exactly the Bloom filter is generated. Is there any code sample for that?

For our outdoor power supply company that builds public WiFi networks at camping sites, we want to implement the following features in our app: Scan surrounding WiFi networks When detecting specific public WiFi SSIDs, provide users with corresponding passwords Automatically connect to those WiFi networks Regarding the NEHotspotHelper API permission application, when I clicked on https://aninterestingwebsite.com/contact/request/network-extension, it redirected me to https://aninterestingwebsite.com/unauthorized/. I'm not sure where to properly apply for this permission now.

We have a content filter system extension as part of our macOS app. The filter normally works correctly, activation and deactivation works as expected but occasionally we see an issue when the content filter is activated. When this issues occurs, the filter activation appears to behave correctly, no errors are reported. Using "systemextensionsctl list" we see the filter is labelled as "[activated enabled]". However, the installed content filter executable does not run. We have seen this issue on macOS 15.3 and later and on the beta macOS 26.1 RC. It happens only occasionally but when it does there is no indication as to why the executable is not running. There are no crash logs or errors in launchd logs. Both rebooting and deactivating/activating the filter do not resolve the issue. The only fix appears to be completely uninstalling the app (including content filter) and reinstalling. I have raised a FB ticket, FB20866080. Does anyone have any idea what could cause this?

We are a Layer 3 VPN provider offering a comprehensive SASE (Secure Access Service Edge) solution that includes TLS inspection, threat protection, granular access control, and secure access to private resources. One of the key challenges we face involves TLS inspection. Many mobile applications, especially on iOS, implement certificate pinning, which causes them to fail when TLS inspection is applied. These apps expect connections to be secured with a specific certificate or trusted certificate authority, and inspection disrupts this trust model. On iOS, the current limitation is that the Packet Tunnel Provider extension does not provide visibility into the originating application (i.e., there is no API to obtain the app’s bundle ID or package name associated with a given network connection). Due to this, we are unable to dynamically determine whether TLS inspection should be bypassed for a particular app. While Apple’s Per-App VPN is one possible solution, it introduces a significant drawback: any applications that are excluded from the VPN configuration are entirely outside the VPN tunnel. This means they do not benefit from any of our SASE features — including secure access to internal resources, DNS/web content filtering, or threat detection. This limits the effectiveness of our solution in environments where both inspection and secure access are critical. We would like to understand whether iOS has any current or planned capabilities to associate a network flow (e.g., a 5-tuple: source IP, destination IP, source port, destination port, and protocol) with the originating app. Such a capability would allow us to programmatically identify certificate-pinned apps and selectively disable TLS inspection without excluding them entirely from the VPN, thereby preserving the full set of SASE protections. Is there any guidance or roadmap update from Apple that addresses this use case?

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

I was having a look through the documentation for NEPacketTunnelProvider, and wanted to know if it's possible for startTunnel(..) and stopTunnel(..) to run simultaneously, and thus require synchronization between resources they deal with? For example, if the VPN is toggled rapidly from system settings, could the setup that occurs in my startTunnel() definition (class instantiation and setTunnelNetworkSettings(value)) potentially occur after the tear-down logic (resource cleanup, setTunnelNetworkSettings(nil)), leaving the system in a state where the VPN is deactivated, but the configuration is in place?

Network.framework: Happy Eyeballs cancels also-ran only after WebSocket handshake (duplicate WS sessions) Hi everyone 👋 When using NWConnection with NWProtocolWebSocket, I’ve noticed that Happy Eyeballs cancels the losing connection only after the WebSocket handshake completes on the winning path. As a result, both IPv4 and IPv6 attempts can send the GET / Upgrade request in parallel, which may cause duplicate WebSocket sessions on the server. Standards context RFC 8305 §6 (Happy Eyeballs v2) states: Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. This “SHOULD” is intentionally non-mandatory — implementations may reasonably delay cancellation to account for additional factors (e.g. TLS success or ALPN negotiation). So Network.framework’s current behavior — canceling after the WebSocket handshake — is technically valid, but it can have practical side effects at the application layer. Why this matters WebSocket upgrades are semantically HTTP GET requests (RFC 6455 §4.1). Per RFC 9110 §9.2, GET requests are expected to be safe and idempotent — they should not have side effects on the server. In practice, though, WebSocket upgrades often: include Authorization headers or cookies create authenticated or persistent sessions So if both IPv4 and IPv6 paths reach the upgrade stage, the server may create duplicate sessions before one connection is canceled. Questions / Request Is there a way to make Happy Eyeballs cancel the losing path earlier — for example, right after TCP or TLS handshake — when using NWProtocolWebSocket? If not, could Apple consider adding an option (e.g. in NWProtocolWebSocket.Options) to control the cancellation threshold, such as: after TCP handshake after TLS handshake after protocol handshake (current behavior) That would align the implementation more closely with RFC 8305 and help prevent duplicate, non-idempotent upgrade requests. Context I’m aware of Quinn’s post Understanding Also-Ran Connections. This report focuses specifically on the cancellation timing for NWProtocolWebSocket and the impact of duplicate upgrade requests. Although RFC 6455 and RFC 9110 define WebSocket upgrades as safe and idempotent HTTP GETs, in practice they often establish authenticated or stateful sessions. Thus, delaying cancellation until after the upgrade can create duplicate sessions — even though the behavior is technically RFC-compliant. Happy to share a sysdiagnose and sample project via Feedback if helpful. Thanks! 🙏 Example log output With Network Link Conditioner (Edge): log stream --info --predicate 'subsystem == "com.apple.network" && process == "WS happy eyeballs"' 2025-11-03 17:02:48.875258 [C3] create connection to wss://echo.websocket.org:443 2025-11-03 17:02:48.878949 [C3.1] starting child endpoint 2a09:8280:1::37:b5c3:443 # IPv6 2025-11-03 17:02:48.990206 [C3.1] starting child endpoint 66.241.124.119:443 # IPv4 2025-11-03 17:03:00.251928 [C3.1.1] Socket received CONNECTED event # IPv6 TCP up 2025-11-03 17:03:00.515837 [C3.1.2] Socket received CONNECTED event # IPv4 TCP up 2025-11-03 17:03:04.543651 [C3.1.1] Output protocol connected (WebSocket) # WS ready on IPv6 2025-11-03 17:03:04.544390 [C3.1.2] nw_endpoint_handler_cancel # cancel IPv4 path 2025-11-03 17:03:04.544913 [C3.1.2] TLS warning: close_notify # graceful close IPv4

Dear Developers, I would like to suggest an optimization for the logic governing the download and installation queue for app updates. Currently, when multiple applications are awaiting updates, the prioritization does not appear to consider the update payload size. My proposal is to implement a logic that prioritizes the download and installation of updates with a smaller delta size (fewer MB) before those with a larger delta. Practical Example: A 1MB update would be processed before a 500MB update, even if their arrival order in the queue was inverted. Potential Benefits: Perceived Speed Optimization (UX): Users would gain access to functional applications more quickly, especially in scenarios with multiple pending updates. Network Efficiency: In limited or intermittent bandwidth scenarios, completing smaller downloads first can reduce the chance of download failures and optimize network resource utilization. Device Resource Management: Frees up temporary storage and processing resources more rapidly for smaller updates. I believe this optimization would bring significant gains in terms of User Experience (UX) and the operational efficiency of the platform. Thank you for your attention and consideration. Sincerely,

I'm developing an iOS application in Swift that performs API calls using URLSession.shared. The requests work correctly when the app is in the foreground. However, when the app transitions to the background (for example, when the user switches to another app), the ongoing API calls are either paused or do not complete as expected. What I’ve tried: Using URLSession.shared.dataTask(with:) to initiate the API requests Observing application lifecycle events like applicationDidEnterBackground, but haven't found a reliable solution to allow requests to complete when backgrounded Goal: I want certain API requests to continue running or be allowed to complete even if the app enters the background. Question: What is the correct approach to allow API calls to continue running or complete when the app moves to the background? Should I be using a background URLSessionConfiguration instead of URLSession.shared? If so, how should it be properly configured and used in this scenario?

Hi, I am making a AI-Powered app that makes api requests to the openai API. However, for security, I set up a vercel backend that handles the API calls securely, while my frontend makes a call to my vercel-hosted https endpoint. Interestingly, whenever I try to make that call on my device, an iPhone, I get this error: Task <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10> finished with error [-1003] Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={_kCFStreamErrorCodeKey=-72000, NSUnderlyingError=0x1435783f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorDomainKey=10, _kCFStreamErrorCodeKey=-72000, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 3ms using unknown from query, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[lte], ipv4, ipv6, dns, expensive, uses cell}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10>" ), NSLocalizedDescription=A server with the specified hostname could not be found., NSErrorFailingURLStringKey=https://[my endpoint], NSErrorFailingURLKey=https://[my endpoint], _kCFStreamErrorDomainKey=10} I'm completely stuck because when I directly make https requests to other api's like openai's endpoint, without the proxy, it finds the server completely fine. Running my endpoint on terminal with curl also works as intended, as I see api key usages. But for some reason, on my project, it does not work. I've looked through almost every single post I could find online, but a lot all of the solutions are outdated and unhelpful. I'm willing to schedule a call, meeting, whatever to resolve this issue and get help more in depth as well.

I have an iOS app that connects to a server running on macOS by leveraging NWListener & NWBrowser. It also makes use of the peerToPeer functionality / AWDL offered via the Network framework. This works great in the iOS app. Now I would like to add support for Shortcuts / App Intents in general. The NWConnection on its own is also working great in the App Intent, but only if I provide the host/port manually, which means I can't use the peer to peer functionality. If I try to run my NWBrowser in the AppIntent it immediately changes its state to failed with a NoAuth (-65555) error: nw_browser_cancel [B1517] The browser has already been cancelled, ignoring nw_browser_cancel(). nw_browser_fail_on_dns_error_locked [B1518] DNSServiceBrowse failed: NoAuth(-65555) NWClientManager: Browser failed: -65555: NoAuth I haven't found documentation/information on whether NWBrowser should work in an AppIntent extension or not.

I'm developing an iOS application in Swift that performs API calls using URLSession.shared. The requests work correctly when the app is in the foreground. However, when the app transitions to the background (for example, when the user switches to another app), the ongoing API calls are either paused or do not complete as expected. What I’ve tried: Using URLSession.shared.dataTask(with:) to initiate the API requests Observing application lifecycle events like applicationDidEnterBackground, but haven't found a reliable solution to allow requests to complete when backgrounded Goal: I want certain API requests to continue running or be allowed to complete even if the app enters the background. Question: What is the correct approach to allow API calls to continue running or complete when the app moves to the background? Should I be using a background URLSessionConfiguration instead of URLSession.shared? If so, how should it be properly configured and used in this scenario?