hi everybody, When I use the following code to connect to WiFi network, an error message of "error=null" or "error='Error Domain=NEHotspotConfigurationErrorDomain Code=11 "" UserInfo={NSLocalizedDescription=}' " will occur. It has been uploaded to Feedback. Feedback ID： FB16819345 (WiFi-无法加入网络) NEHotspotConfiguration *hotspotConfig = [[NEHotspotConfiguration alloc] initWithSSID:ssid passphrase:psk isWEP:NO]; [[NEHotspotConfigurationManager sharedManager] applyConfiguration:hotspotConfig completionHandler:^(NSError * _Nullable error) { }];

I am trying to activate an application which sends my serial number to a server. The send is being blocked. The app is signed but not sandboxed. I am running Sequoia on a recent iMac. My network firewall is off and I do not have any third party virus software. I have selected Allow Applications from App Store & Known Developers. My local network is wifi using the eero product. There is no firewall or virus scanning installed with this product. Under what circumstances will Mac OS block outgoing internet connections from a non-sandboxed app? How else could the outgoing connection be blocked?

For important background information, read Extra-ordinary Networking before reading this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Working with a Wi-Fi Accessory Building an app that works with a Wi-Fi accessory presents specific challenges. This post discusses those challenges and some recommendations for how to address them. Note While my focus here is iOS, much of the info in this post applies to all Apple platforms. IMPORTANT iOS 18 introduced AccessorySetupKit, a framework to simplify the discovery and configuration of an accessory. I’m not fully up to speed on that framework myself, but I encourage you to watch WWDC 2024 Session 10203 Meet AccessorySetupKit and read the framework documentation. IMPORTANT iOS 26 introduced WiFiAware, a framework for setting up communication with Wi-Fi Aware accessories. Wi-Fi Aware is an industry standard to securely discover, pair, and communicate with nearby devices. This is especially useful for stand-alone accessories (defined below). For more on this framework, watch WWDC 2025 Session 228 Supercharge device connectivity with Wi-Fi Aware and read the framework documentation. For information on how to create a Wi-Fi Aware accessory that works with iPhone, go to Developer > Accessories, download Accessory Design Guidelines for Apple Devices, and review the Wi-Fi Aware chapter. Accessory Categories I classify Wi-Fi accessories into three different categories. A bound accessory is ultimately intended to join the user’s Wi-Fi network. It may publish its own Wi-Fi network during the setup process, but the goal of that process is to get the accessory on to the existing network. Once that’s done, your app interacts with the accessory using ordinary networking APIs. An example of a bound accessory is a Wi-Fi capable printer. A stand-alone accessory publishes a Wi-Fi network at all times. An iOS device joins that network so that your app can interact with it. The accessory never provides access to the wider Internet. An example of a stand-alone accessory is a video camera that users take with them into the field. You might want to write an app that joins the camera’s network and downloads footage from it. A gateway accessory is one that publishes a Wi-Fi network that provides access to the wider Internet. Your app might need to interact with the accessory during the setup process, but after that it’s useful as is. An example of this is a Wi-Fi to WWAN gateway. Not all accessories fall neatly into these categories. Indeed, some accessories might fit into multiple categories, or transition between categories. Still, I’ve found these categories to be helpful when discussing various accessory integration challenges. Do You Control the Firmware? The key question here is Do you control the accessory’s firmware? If so, you have a bunch of extra options that will make your life easier. If not, you have to adapt to whatever the accessory’s current firmware does. Simple Improvements If you do control the firmware, I strongly encourage you to: Support IPv6 Implement Bonjour [1] These two things are quite easy to do — most embedded platforms support them directly, so it’s just a question of turning them on — and they will make your life significantly easier: Link-local addresses are intrinsic to IPv6, and IPv6 is intrinsic to Apple platforms. If your accessory supports IPv6, you’ll always be able to communicate with it, regardless of how messed up the IPv4 configuration gets. Similarly, if you support Bonjour, you’ll always be able to find your accessory on the network. [1] Bonjour is an Apple term for three Internet standards: RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses RFC 6762 Multicast DNS RFC 6763 DNS-Based Service Discovery WAC For a bound accessory, support Wireless Accessory Configuration (WAC). This is a relatively big ask — supporting WAC requires you to join the MFi Program — but it has some huge benefits: You don’t need to write an app to configure your accessory. The user will be able to do it directly from Settings. If you do write an app, you can use the EAWiFiUnconfiguredAccessoryBrowser class to simplify your configuration process. HomeKit For a bound accessory that works in the user’s home, consider supporting HomeKit. This yields the same onboarding benefits as WAC, and many other benefits as well. Also, you can get started with the HomeKit Open Source Accessory Development Kit (ADK). Bluetooth LE If your accessory supports Bluetooth LE, think about how you can use that to improve your app’s user experience. For an example of that, see SSID Scanning, below. Claiming the Default Route, Or Not? If your accessory publishes a Wi-Fi network, a key design decision is whether to stand up enough infrastructure for an iOS device to make it the default route. IMPORTANT To learn more about how iOS makes the decision to switch the default route, see The iOS Wi-Fi Lifecycle and Network Interface Concepts. This decision has significant implications. If the accessory’s network becomes the default route, most network connections from iOS will be routed to your accessory. If it doesn’t provide a path to the wider Internet, those connections will fail. That includes connections made by your own app. Note It’s possible to get around this by forcing your network connections to run over WWAN. See Binding to an Interface in Network Interface Techniques and Running an HTTP Request over WWAN. Of course, this only works if the user has WWAN. It won’t help most iPad users, for example. OTOH, if your accessory’s network doesn’t become the default route, you’ll see other issues. iOS will not auto-join such a network so, if the user locks their device, they’ll have to manually join the network again. In my experience a lot of accessories choose to become the default route in situations where they shouldn’t. For example, a bound accessory is never going to be able to provide a path to the wider Internet so it probably shouldn’t become the default route. However, there are cases where it absolutely makes sense, the most obvious being that of a gateway accessory. Acting as a Captive Network, or Not? If your accessory becomes the default route you must then decide whether to act like a captive network or not. IMPORTANT To learn more about how iOS determines whether a network is captive, see The iOS Wi-Fi Lifecycle. For bound and stand-alone accessories, becoming a captive network is generally a bad idea. When the user joins your network, the captive network UI comes up and they have to successfully complete it to stay on the network. If they cancel out, iOS will leave the network. That makes it hard for the user to run your app while their iOS device is on your accessory’s network. In contrast, it’s more reasonable for a gateway accessory to act as a captive network. SSID Scanning Many developers think that TN3111 iOS Wi-Fi API overview is lying when it says: iOS does not have a general-purpose API for Wi-Fi scanning It is not. Many developers think that the Hotspot Helper API is a panacea that will fix all their Wi-Fi accessory integration issues, if only they could get the entitlement to use it. It will not. Note this comment in the official docs: NEHotspotHelper is only useful for hotspot integration. There are both technical and business restrictions that prevent it from being used for other tasks, such as accessory integration or Wi-Fi based location. Even if you had the entitlement you would run into these technical restrictions. The API was specifically designed to support hotspot navigation — in this context hotspots are “Wi-Fi networks where the user must interact with the network to gain access to the wider Internet” — and it does not give you access to on-demand real-time Wi-Fi scan results. Many developers look at another developer’s app, see that it’s displaying real-time Wi-Fi scan results, and think there’s some special deal with Apple that’ll make that work. There is not. In reality, Wi-Fi accessory developers have come up with a variety of creative approaches for this, including: If you have a bound accessory, you might add WAC support, which makes this whole issue go away. In many cases, you can avoid the need for Wi-Fi scan results by adopting AccessorySetupKit. You might build your accessory with a barcode containing the info required to join its network, and scan that from your app. This is the premise behind the Configuring a Wi-Fi Accessory to Join the User’s Network sample code. You might configure all your accessories to have a common SSID prefix, and then take advantage of the prefix support in NEHotspotConfigurationManager. See Programmatically Joining a Network, below. You might have your app talk to your accessory via some other means, like Bluetooth LE, and have the accessory scan for Wi-Fi networks and return the results. Programmatically Joining a Network Network Extension framework has an API, NEHotspotConfigurationManager, to programmatically join a network, either temporarily or as a known network that supports auto-join. For the details, see Wi-Fi Configuration. One feature that’s particularly useful is it’s prefix support, allowing you to create a configuration that’ll join any network with a specific prefix. See the init(ssidPrefix:) initialiser for the details. For examples of how to use this API, see: Configuring a Wi-Fi Accessory to Join the User’s Network — It shows all the steps for one approach for getting a non-WAC bound accessory on to the user’s network. NEHotspotConfiguration Sample — Use this to explore the API in general. Secure Communication Users expect all network communication to be done securely. For some ideas on how to set up a secure connection to an accessory, see TLS For Accessory Developers. Revision History 2025-11-05 Added a link to the Accessory Design Guidelines for Apple Devices. 2025-06-19 Added a preliminary discussion of Wi-Fi Aware. 2024-09-12 Improved the discussion of AccessorySetupKit. 2024-07-16 Added a preliminary discussion of AccessorySetupKit. 2023-10-11 Added the HomeKit section. Fixed the link in Secure Communication to point to TLS For Accessory Developers. 2023-07-23 First posted.

I am learning how to use DNS-SD from swift and have created a basic CLI app, however I am not getting callback results. I can get results from cli. Something I am doing wrong here? dns-sd -G v6 adet.local 10:06:08.423 Add 40000002 22 adet.local. FE80:0000... dns-sd -B _adt._udp. 11:19:10.696 Add 2 22 local. _adt._udp. adet import Foundation import dnssd var reference: DNSServiceRef? func dnsServiceGetAddrInfoReply(ref: DNSServiceRef?, flags: DNSServiceFlags, interfaceIndex: UInt32, errorCode: DNSServiceErrorType, hostname: UnsafePointer<CChar>?, address: UnsafePointer<sockaddr>?, ttl: UInt32, context: UnsafeMutableRawPointer?) { print("GetAddr'd") print(hostname.debugDescription.utf8CString) print(address.debugDescription.utf8CString) } var error = DNSServiceGetAddrInfo(&reference, 0, 0, DNSServiceProtocol(kDNSServiceProtocol_IPv6), "adet.local", dnsServiceGetAddrInfoReply, nil) print("GetAddr: \(error)") func dnsServiceBrowseReply(ref: DNSServiceRef?, flags: DNSServiceFlags, interfaceIndex: UInt32, errorCode: DNSServiceErrorType, serviceName: UnsafePointer<CChar>?, regType: UnsafePointer<CChar>?, replyDomain: UnsafePointer<CChar>?, context: UnsafeMutableRawPointer?) { print("Browsed") print(serviceName.debugDescription.utf8CString) print(replyDomain.debugDescription.utf8CString) } error = DNSServiceBrowse(&reference, 0, 0, "_adt._udp", nil, dnsServiceBrowseReply, nil) print("Browse: \(error)") Foundation.RunLoop.main.run() Info.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSLocalNetworkUsageDescription</key> <string>By the Hammer of Grabthor</string> <key>NSBonjourServices</key> <array> <string>_adt._udp.</string> <string>_http._tcp.</string> <string>_http._tcp</string> <string>_adt._udp</string> </array> </dict> </plist>

Dear Apple: In our app, we will call the - (void) applyConfiguration:(NEHotspotConfiguration *) configuration completionHandler:(void (^)(NSError * error)) completionHandler; interface of NEHotspotConfigurationManager on Apple devices. However, we are encountering a problem where the connection to the 2.4G hotspot fails, and the error is nil when it fails. We checked the Wi-Fi air interface and found that the Apple phone does not send a probe request before connecting to the hotspot. However, we are unclear why the Apple device does not send the probe request frame. Could you please help us understand when the probe request frame is not sent during the hotspot connection and how to trigger it to send the probe request frame every time? Thank you.

Hi, i have a crash received in my Firebase Crashlytics. I couldn't figure out the root cause of the issue. Could anyone please help me with it. Crashed: com.apple.CFNetwork.Connection 0 libobjc.A.dylib 0x20b8 objc_retain_x19 + 16 1 CFNetwork 0x47398 HTTP3Fields::appendField(NSString*, NSString*) + 72 2 CFNetwork 0x41250 invocation function for block in HTTP3Stream::_buildRequestHeaders() + 240 3 CoreFoundation 0x249f0 __NSDICTIONARY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 4 CoreFoundation 0x565dc ____NSDictionaryEnumerate_block_invoke_2 + 56 5 CoreFoundation 0x55b10 CFBasicHashApply + 148 6 CoreFoundation 0x8abfc __NSDictionaryEnumerate + 520 7 CFNetwork 0x793d4 HTTP3Stream::scheduleAndOpenWithHandler(CoreSchedulingSet const*, void (__CFHTTPMessage*, NSObject<OS_dispatch_data>*, CFStreamError const*) block_pointer, void (unsigned char) block_pointer) + 1120 8 CFNetwork 0x1665c HTTPProtocol::useNetStreamInfoForRequest(MetaNetStreamInfo*, HTTPRequestMessage const*, unsigned char) + 4044 9 CFNetwork 0x80c80 HTTP3ConnectionCacheEntry::enqueueRequestForProtocol(MetaConnectionCacheClient*, HTTPRequestMessage const*, MetaConnectionOptions) + 2540 10 CFNetwork 0x7fab8 HTTP3ConnectionCacheWrapper::ingestTube(Tube*, bool) + 2924 11 CFNetwork 0x257dc TubeManager::newTubeReady(Tube*, CFStreamError) + 4284 12 CFNetwork 0x57b64 invocation function for block in TubeManager::_onqueue_createNewTube(HTTPConnectionCacheKey*) + 72 13 CFNetwork 0x2fe30 Tube::_onqueue_invokeCB(CFStreamError) + 360 14 CFNetwork 0x2fc20 NWIOConnection::_signalEstablished() + 652 15 CFNetwork 0x4ba1c invocation function for block in NWIOConnection::_handleEvent_ReadyFinish() + 748 16 CFNetwork 0x4b5b0 invocation function for block in Tube::postConnectConfiguration(NSObject<OS_tcp_connection>*, NSObject<OS_nw_parameters>*, void () block_pointer) + 860 17 CFNetwork 0x4b220 BlockHolderVar<std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError>::invoke_normal(std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError) + 64 18 CFNetwork 0x32f2c ProxyConnectionEstablishment::postProxyConnectionConfiguration(__CFAllocator const*, std::__1::shared_ptr<TransportConnection>, NSObject<OS_nw_parameters>*, __CFHTTPMessage*, HTTPConnectionCacheKey*, std::__1::shared_ptr<MetaAuthClient>, SmartBlockWithArgs<std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError>) + 664 19 CFNetwork 0x32bbc Tube::postConnectConfiguration(NSObject<OS_tcp_connection>*, NSObject<OS_nw_parameters>*, void () block_pointer) + 744 20 CFNetwork 0xc19b0 invocation function for block in NWIOConnection::_setupConnectionEvents() + 2360 21 libdispatch.dylib 0x132e8 _dispatch_block_async_invoke2 + 148 22 libdispatch.dylib 0x40d0 _dispatch_client_callout + 20 23 libdispatch.dylib 0xb6d8 _dispatch_lane_serial_drain + 744 24 libdispatch.dylib 0xc214 _dispatch_lane_invoke + 432 25 libdispatch.dylib 0xd670 _dispatch_workloop_invoke + 1732 26 libdispatch.dylib 0x17258 _dispatch_root_queue_drain_deferred_wlh + 288 27 libdispatch.dylib 0x16aa4 _dispatch_workloop_worker_thread + 540 28 libsystem_pthread.dylib 0x4c7c _pthread_wqthread + 288 29 libsystem_pthread.dylib 0x1488 start_wqthread + 8 [Here is the complete crash report.](https://developer.apple.com/forums/content/attachment/58b5bb7d-7c90-4eec-906c-4fb76861d44b)

I've just watched Scott Herschel's WWDC 25 session "Use structured concurrency with Network framework" and I am more than overjoyed to see said framework offer these new features. However, the documentation has not yet been updated (or it's not where I expect to find it) .. Is there more that I can read about the enhancements to the framework? One specific question is whether the structured concurrency portion of the framework's enhancement is backward compatible to before "26"?

Hi! My project has the Local Push Connectivity entitlement for a feature we have requiring us to send low-latency critical notifications over a local, private Wi-Fi network. We have our NEAppPushProvider creating a SSE connection using the Network framework with our hardware running a server. The server sends a keep-alive message every second. On an iPhone 16 with iOS 18+, the connection is reliable and remains stable for hours, regardless of whether the iOS app is in the foreground, background, or killed. One of our QA engineers has been testing on an iPhone 13 running iOS 16, and has notice shortly after locking the phone, specifically when not connected to power the device seems to turn off the Wi-Fi radio. So when the server sends a notification, it is not received. About 30s later, it seems to be back on. This happens on regular intervals. When looking at our log data, the provider does seem to be getting stopped, then restarted shortly after. The reason code is NEProviderStopReasonNoNetworkAvailable, which further validates that the network is getting dropped by the device in regular intervals. My questions are: Were there possibly silent changes to the framework between iOS versions that could be the reason we're seeing inconsistent behavior? Is there a connection type we could use, instead of SSE, that would prevent the device from disconnecting and reconnecting to the Wi-Fi network? Is there an alternative approach to allow us to maintain a persistent network connection with the extension or app?

Description: I'm noticing that when using the completion handler variant of URLSession.dataTask(with:), the delegate method urlSession(_:dataTask:didReceive:) is not called—even though a delegate is set when creating the session. Here's a minimal reproducible example: ✅ Case where delegate method is called: class CustomSessionDelegate: NSObject, URLSessionDataDelegate { func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) { print("✅ Delegate method called: Data received") } } let delegate = CustomSessionDelegate() let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) let request = URLRequest(url: URL(string: "https://httpbin.org/get")!) let task = session.dataTask(with: request) // ✅ No completion handler task.resume() In this case, the delegate method didReceive is called as expected. ❌ Case where delegate method is NOT called: class CustomSessionDelegate: NSObject, URLSessionDataDelegate { func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) { print("❌ Delegate method NOT called") } } let delegate = CustomSessionDelegate() let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) let request = URLRequest(url: URL(string: "https://httpbin.org/get")!) let task = session.dataTask(with: request) { data, response, error in print("Completion handler called") } task.resume() Here, the completion handler is executed, but the delegate method didReceive is never called. Notes: I’ve verified this behavior on iOS 16, 17, and 18. Other delegate methods such as urlSession(_:task:didFinishCollecting:) do get called with the completion handler API. This happens regardless of whether swizzling or instrumentation is involved — the issue is reproducible even with direct method implementations. Questions: Is this the expected behavior (i.e., delegate methods like didReceive are skipped when a completion handler is used)? If yes, is there any official documentation that explains this? Is there a recommended way to ensure delegate methods are invoked, even when using completion handler APIs? Thanks in advance!

I am in the middle of investigating an issue arising in the call to setsockopt syscall where it returns an undocumented and unexpected errno. As part of that, I'm looking for a way to list any socket content filters or any such extensions are in play on the system where this happens. To do that, I ran: systemextensionsctl list That retuns the following output: 0 extension(s) which seems to indicate there's no filters or extensions in play. However, when I do: netstat -s among other things, it shows: net_api: 2 interface filters currently attached 2 interface filters currently attached by OS 2 interface filters attached since boot 2 interface filters attached since boot by OS ... 4 socket filters currently attached 4 socket filters currently attached by OS 4 socket filters attached since boot 4 socket filters attached since boot by OS What would be the right command/tool/options that I could use to list all the socket filters/extensions (and their details) that are in use and applicable when a call to setsockopt is made from an application on that system? Edit: This is on a macosx-aarch64 with various different OS versions - 13.6.7, 14.3.1 and even 14.4.1.

I implemented a Network Extension in the macOS, use NETransparentProxyProvider. After installing and enabling it, I implemented a UDP client to test its. I found that the UDP client failed to send the data successfully (via sendto, and it returned a success), and when using Wireshark to capture the network data packet, I still couldn't see this UDP data packet. The code for Network Extension is like this: @interface MyTransparentProxyProvider : NETransparentProxyProvider @end @implementation MyTransparentProxyProvider - (void)startProxyWithOptions:(NSDictionary *)options completionHandler:(void (^)(NSError *))completionHandler { NETransparentProxyNetworkSettings *objSettings = [[NETransparentProxyNetworkSettings alloc] initWithTunnelRemoteAddress:@"127.0.0.1"]; // included rules NENetworkRule *objIncludedNetworkRule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolAny direction:NETrafficDirectionOutbound]; NSMutableArray<NENetworkRule *> *arrIncludedNetworkRules = [NSMutableArray array]; [arrIncludedNetworkRules addObject:objIncludedNetworkRule]; objSettings.includedNetworkRules = arrIncludedNetworkRules; // apply [self setTunnelNetworkSettings:objSettings completionHandler: ^(NSError * _Nullable error) { // TODO } ]; if (completionHandler != nil) completionHandler(nil); } - (BOOL)handleNewFlow:(NEAppProxyFlow *)flow { if (flow == nil) return NO; char szProcPath[PROC_PIDPATHINFO_MAXSIZE] = {0}; audit_token_t *lpAuditToken = (audit_token_t*)flow.metaData.sourceAppAuditToken.bytes; if (lpAuditToken != NULL) { proc_pidpath_audittoken(lpAuditToken, szProcPath, sizeof(szProcPath)); } if ([flow isKindOfClass:[NEAppProxyTCPFlow class]]) { NWHostEndpoint *objRemoteEndpoint = (NWHostEndpoint *)((NEAppProxyTCPFlow *)flow).remoteEndpoint; LOG("-MyTransparentProxyProvider handleNewFlow:] TCP flow! Process: (%d)%s, %s Remote: %s:%s, %s", lpAuditToken != NULL ? audit_token_to_pid(*lpAuditToken) : -1, flow.metaData.sourceAppSigningIdentifier != nil ? [flow.metaData.sourceAppSigningIdentifier UTF8String] : "", szProcPath, objRemoteEndpoint != nil ? (objRemoteEndpoint.hostname != nil ? [objRemoteEndpoint.hostname UTF8String] : "") : "", objRemoteEndpoint != nil ? (objRemoteEndpoint.port != nil ? [objRemoteEndpoint.port UTF8String] : "") : "", ((NEAppProxyTCPFlow *)flow).remoteHostname != nil ? [((NEAppProxyTCPFlow *)flow).remoteHostname UTF8String] : "" ); } else if ([flow isKindOfClass:[NEAppProxyUDPFlow class]]) { NSString *strLocalEndpoint = [NSString stringWithFormat:@"%@", ((NEAppProxyUDPFlow *)flow).localEndpoint]; LOG("-[MyTransparentProxyProvider handleNewFlow:] UDP flow! Process: (%d)%s, %s LocalEndpoint: %s", lpAuditToken != NULL ? audit_token_to_pid(*lpAuditToken) : -1, flow.metaData.sourceAppSigningIdentifier != nil ? [flow.metaData.sourceAppSigningIdentifier UTF8String] : "", szProcPath, strLocalEndpoint != nil ? [strLocalEndpoint UTF8String] : "" ); } else { LOG("-[MyTransparentProxyProvider handleNewFlow:] Unknown flow! Process: (%d)%s, %s", lpAuditToken != NULL ? audit_token_to_pid(*lpAuditToken) : -1, flow.metaData.sourceAppSigningIdentifier != nil ? [flow.metaData.sourceAppSigningIdentifier UTF8String] : "", szProcPath ); } return NO; } @end The following methods can all enable UDP data packets to be successfully sent to the UDP server: 1.In -[MyTransparentProxyProvider startProxyWithOptions:completionHandler:], add the exclusion rule "The IP and port of the UDP server, the protocol is UDP"; 2.In -[MyTransparentProxyProvider startProxyWithOptions:completionHandler:], add the exclusion rule "All IPs and ports, protocol is UDP"; 3.In -[MyTransparentProxyProvider handleNewFlow:] or -[MyTransparentProxyProvider handleNewUDPFlow:initialRemoteEndpoint:], process the UDP Flow and return YES. Did I do anything wrong?

Goal : Block all outbound connections to a static list of hosts (both In-app requests and WKWebView/Safari). App & both extensions have Network Extension entitlement with content-filter-provider and filter-control-provider What’s working: Safari and WKWebView requests matching the block list are dropped. What’s broken: In-app traffic never reaches the Data Provider—those requests always succeed. Setup: • NEFilterProviderConfiguration with both Data & Control providers, filterBrowsers = true, filterSockets = true • Data Provider implements handleNewFlow for socket/browser flows • Control Provider implements handleNewFlow for browser flows • Enabled via saveToPreferences() and toggled ON in Settings

Just tried to re-run the code below (previously discussed https://developer.apple.com/forums/thread/747815) and filed as bug: https://feedbackassistant.apple.com/feedback/13678278 Still broken on macOS 26 first beta. Any chance anything can be done about this @eskimo? thanks, Martin import Foundation import Network let localPort: NWEndpoint.Port = 12345 var connections: [NWConnection] = [] func startFlow(remotePort: UInt16) { let params = NWParameters.udp params.allowLocalEndpointReuse = true params.requiredLocalEndpoint = NWEndpoint.hostPort(host: "0.0.0.0", port: localPort) let conn = NWConnection(host: "93.184.216.34", port: .init(rawValue: remotePort)!, using: params) conn.stateUpdateHandler = { newState in print("connection \(remotePort) did change state, new: \(newState)") } conn.start(queue: .main) connections.append(conn) } func main() { startFlow(remotePort: 23456) startFlow(remotePort: 23457) dispatchMain() } main()

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.

Recently, my application was having trouble connecting socket using TCP protocol after it was reinstalled. The cause of the problem was initially that I did not grant local network permissions when I reinstalled, I was aware of the problem, so socket connect interface worked fine after I granted permissions. However, the next time I repeat the previous operation, I also do not grant local network permissions, and then turn it back on in the Settings, and socket connect interfcae does not work properly (connect interface return errno 65, the system version and code have not changed). Fortunately, socket connect success after rebooting the phone, and more importantly, I was able to repeat the problem many times. So I want to know if the process between when I re-uninstall the app and deny local network permissions, and when I turn it back on in Settings, is that permissions have been granted normally, and not fake, and not required a reboot to reset something for socket coonnect to take effect.

Question 1: After NetworkExtension is installed, when the software receives a pushed uninstall command, it needs to download the entire software but fails to uninstall this NetworkExtension. Are there any solutions? Question 2: How can residual, uninstalled NetworkExtensions be cleaned up when SIP (System Integrity Protection) is enabled?

(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,

Hello Everyone, I’m working on a project that involves multicast communication between processes running on different devices within the same network. For all my Apple devices (macOS, iOS, etc.), I am using NWConnectionGroup, which listens on a multicast address "XX.XX.XX.XX" and a specific multicast port. The issue occurs when a requestor (such as a non-Apple process) sends a multicast request, and the server, which is a process running on an Apple device using NWConnectionGroup (the responder), attempts to reply. The problem is that the response is sent from a different ephemeral port rather than the port on which the multicast request was received. If the client is behind a firewall that blocks unsolicited traffic, the firewall only allows incoming packets on the same multicast port used for the initial request. Since the multicast response is sent from a different ephemeral port, the firewall blocks this response, preventing the requestor from receiving it. Questions: Is there a recommended approach within the NWConnectionGroup or Network.framework to ensure that responses to multicast requests are sent from the same port used for the request? Are there any best practices for handling multicast responses in scenarios where the requestor is behind a restrictive firewall? Any insights or suggestions on how to account for this behavior and ensure reliable multicast communication in such environments would be greatly appreciated. Thanks, Harshal

[Q] How many instances of the same NEFilterDataProvider subclass can there be in a single running Network Extension at any given time? I would expect that there can be only 1 instance but I'm looking at a memgraph where 2 instances are listed. As it's the Network Extension framework that is responsible for creating, starting and stopping these instances, this is rather strange.

We are implementing a connection between iPad and iPhone devices using LocalPushConnectivity, and have introduced SimplePushProvider into the project. We will have it switch between roles of Server and Client within a single project. ※ iPad will be Server and the iPhone will be Client. Communication between Server and Client is via TLS, with Server reading p12 file and Client setting public key. Currently, a TLS error code of "-9836" (invalid protocol version) is occurring when communicating from Client's SimplePushProvider to Server. I believe that Client is sending TLS1.3, and Server is set to accept TLS1.2 to 1.3. Therefore, I believe that the actual error is not due to TLS protocol version, but is an error that is related to security policy or TLS communication setting. Example: P12 file does not meet some requirement NWProtocolTLS.Options setting is insufficient etc... I'm not sure what the problem is, so please help. For reference, I will attach you implementation of TLS communication settings. P12 file is self-signed and was created by exporting it from Keychain Access. Test environment: iPad (OS: 16.6) iPhone (OS: 18.3.2) ConnectionOptions: TLS communication settings public enum ConnectionOptions { public enum TCP { public static var options: NWProtocolTCP.Options { let options = NWProtocolTCP.Options() options.noDelay = true options.enableFastOpen return options } } public enum TLS { public enum Error: Swift.Error { case invalidP12 case unableToExtractIdentity case unknown } public class Server { public let p12: URL public let passphrase: String public init(p12 url: URL, passphrase: String) { self.p12 = url self.passphrase = passphrase } public var options: NWProtocolTLS.Options? { guard let data = try? Data(contentsOf: p12) else { return nil } let pkcs12Options = [kSecImportExportPassphrase: passphrase] var importItems: CFArray? let status = SecPKCS12Import(data as CFData, pkcs12Options as CFDictionary, &amp;importItems) guard status == errSecSuccess, let items = importItems as? [[String: Any]], let importItemIdentity = items.first?[kSecImportItemIdentity as String], let identity = sec_identity_create(importItemIdentity as! SecIdentity) else { return nil } let options = NWProtocolTLS.Options() sec_protocol_options_set_min_tls_protocol_version(options.securityProtocolOptions, .TLSv12) sec_protocol_options_set_max_tls_protocol_version(options.securityProtocolOptions, .TLSv13) sec_protocol_options_set_local_identity(options.securityProtocolOptions, identity) sec_protocol_options_append_tls_ciphersuite(options.securityProtocolOptions, tls_ciphersuite_t.RSA_WITH_AES_128_GCM_SHA256) return options } } public class Client { public let publicKeyHash: String private let dispatchQueue = DispatchQueue(label: "ConnectionParameters.TLS.Client.dispatchQueue") public init(publicKeyHash: String) { self.publicKeyHash = publicKeyHash } // Attempt to verify the pinned certificate. public var options: NWProtocolTLS.Options { let options = NWProtocolTLS.Options() sec_protocol_options_set_min_tls_protocol_version(options.securityProtocolOptions, .TLSv12) sec_protocol_options_set_max_tls_protocol_version(options.securityProtocolOptions, .TLSv13) sec_protocol_options_set_verify_block( options.securityProtocolOptions, verifyClosure, dispatchQueue ) return options } private func verifyClosure( secProtocolMetadata: sec_protocol_metadata_t, secTrust: sec_trust_t, secProtocolVerifyComplete: @escaping sec_protocol_verify_complete_t ) { let trust = sec_trust_copy_ref(secTrust).takeRetainedValue() guard let serverPublicKeyData = publicKey(from: trust) else { secProtocolVerifyComplete(false) return } let keyHash = cryptoKitSHA256(data: serverPublicKeyData) guard keyHash == publicKeyHash else { // Presented certificate doesn't match. secProtocolVerifyComplete(false) return } // Presented certificate matches the pinned cert. secProtocolVerifyComplete(true) } private func cryptoKitSHA256(data: Data) -&gt; String { let rsa2048Asn1Header: [UInt8] = [ 0x30, 0x82, 0x01, 0x22, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x82, 0x01, 0x0f, 0x00 ] let data = Data(rsa2048Asn1Header) + data let hash = SHA256.hash(data: data) return Data(hash).base64EncodedString() } private func publicKey(from trust: SecTrust) -&gt; Data? { guard let certificateChain = SecTrustCopyCertificateChain(trust) as? [SecCertificate], let serverCertificate = certificateChain.first else { return nil } let publicKey = SecCertificateCopyKey(serverCertificate) return SecKeyCopyExternalRepresentation(publicKey!, nil)! as Data } } } }