General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. 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 Network Extension (including Wi-Fi on iOS): See Network Extension Resources Wi-Fi Fundamentals TN3111 iOS Wi-Fi API overview Wi-Fi Aware framework documentation Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). 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. Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post WirelessInsights framework documentation iOS Network Signal Strength 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.

I'm facing an issue where if a WiFi network is turned off and back on within a short time frame (2-4 seconds), iOS still shows the device as connected but does not send a new DHCP request. This causes a problem for my network device, which relies on the DHCP request to assign an IP address. Without the request, the device is unable to establish a socket connection properly. Is there any way to force iOS to send a DHCP request immediately when reconnecting to the network in this scenario? Are there any known workarounds or configurations that might help ensure the DHCP process is re-triggered? Any insights would be appreciated. Thanks!

Dear Apple： We found that after mirroring an iPhone and a Mac, calling the NEHotspotConfigurationManager applyConfiguration interface on the iPhone fails to connect to Wi-Fi. Are there any restrictions on using this interface in mirror mode?

We've observed intermittent crashes in our production environment, pls help to take a look at this, thx

Hi we want to use CONNECT-IP extension within the MASQUE protocol suite. we want to be able to reroute ICMP packets from our machine and redirect them to our MASQUE proxy. we want to avoid a creation of virtual interface or modifying the routing tables. is it possible, if so, how can it be achieved. thanks

I was trying to call getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED, ...), and by mistake passed a wrong value for the second parameter where it should be SOL_LOCAL. But the call still succeeded. Then I did more experiments and passed more random values for the second parameter, all succeeded. It seems there is a lack of parameter check in the implementation of getsockopt() , where it should return errors if people pass invalid parameters instead of succeeding silently. Hope the Apple engineers can help to validate and fix it.

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

I am developing an App based on Network Extension that lets all network requests on device access the Internet through a private Relay. I created an empty iOS App and only the entitlements file and ViewController.swift(Main.storyboard) file have been modified. The code was copied from the official video https://developer.apple.com/videos/play/wwdc2023/10002/ But, running the App on iPhone, the saveToPreferences API reported Error Domain=NERelayErrorDomain Code=3 "(null)" and the App doesn't look like it's changed at all (it doesn't jump to the Settings - VPN&Relay). Does anyone know why？Any reply would be greatly appreciated. The contents of the entitlements file: <?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>com.apple.developer.networking.networkextension</key> <array> <string>relay</string> </array> </dict> </plist> ViewController.swift: import UIKit import NetworkExtension class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. } @IBAction func tap(_ sender: Any) { let newRelay = NERelay() let relayURL = URL(string: "https://relay.example.com:443/") newRelay.http3RelayURL = relayURL newRelay.http2RelayURL = relayURL newRelay.additionalHTTPHeaderFields = ["Authorization" : "PrivateToken=123"] let manager = NERelayManager.shared() manager.relays = [newRelay] manager.matchDomains = ["internal.example.com"] manager.isEnabled = false manager.saveToPreferences { err in print(err) } } }

I have a question regarding /etc/pf.conf. If I use this rule, rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 all other traffic on bridge100 will not function properly, even the traffic that is not destined for 192.168.2.104. Additionally, the hotspot generated through bridge100 will also become unavailable. Even if I comment out this rule and run sudo pfctl -e -f /etc/pf.conf, the problem still persists. The situation will only return to normal when I restart my Mac. my macos:15.3.2 my /etc/pf.conf # scrub-anchor "com.apple/*" nat-anchor "com.apple/*" rdr-anchor "com.apple/*" rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 dummynet-anchor "com.apple/*" anchor "com.apple/*" load anchor "com.apple" from "/etc/pf.anchors/com.apple"

Hi there, I'm trying to build a MacOS VPN application from scratch. My VPN application is slightly from normal ones, It will include an authentication token and underlying process information (pid, application path etc.) in each connection made to the VPN gateway. Consider it a poor man's zerotrust implementation. NetworkExtension and PacketTunnel is a must, thus to retrieve process information via audit tokens. However, I'm unable to find any working examples that can be built on MacOS 15.X. I tried to open an TSI case but didn't receive anything useful. Anyone?

I am working on a macos application that uses NetworkExtension and works fine in the debug environment. However, when I use the Release package, I am always prompted that my description file does not contain NetworkExtension. I am sure that my description file does contain NetworkExtension. How to solve this problem

We use Boost ***** (1.86.0) for WebSockets in an iOS application using a self-signed certificate. The ***** WebSocket client works fine on iOS 18.1 and every other OS (Windows, Android, Linux, etc...) but not iOS 18.3.1 and possibly versions before 18.3.1 but later than iOS 18.1. Has anyone else ran into this issue and how did you resolve? What could have changed after iOS 18.1 that would prevent a WSS Websocket from connecting that works fine on iOS 18.1?

I have a question regarding /etc/pf.conf. If I use this rule, rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 all other traffic on bridge100 will not function properly, even the traffic that is not destined for 192.168.2.104. Additionally, the hotspot generated through bridge100 will also become unavailable. Even if I comment out this rule and run sudo pfctl -e -f /etc/pf.conf, the problem still persists. The situation will only return to normal when I restart my Mac. my macos:15.3.2 my /etc/pf.conf # scrub-anchor "com.apple/*" nat-anchor "com.apple/*" rdr-anchor "com.apple/*" rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 dummynet-anchor "com.apple/*" anchor "com.apple/*" load anchor "com.apple" from "/etc/pf.anchors/com.apple"

We're experiencing an issue with Local Network Permission. When trying to connect to a socket, the Local Network Permission alert pops up. To trigger the permission request at the start of the app, we used the following code to ask for permission and receive a callback on whether it's granted. However, this approach doesn't always trigger the permission alert, or it gets automatically dismissed after 30 seconds, only to reappear later. What could be causing this inconsistent behavior? func checkLocalNetworkPermission(_ completed: Optional&lt;(Bool) -&gt; Void&gt; = .none) { DispatchQueue.global(qos: .userInitiated).async { let hostName = ProcessInfo.processInfo.hostName let isGranted = hostName.contains(".local") if let completed { DispatchQueue.main.async { completed(isGranted) } } } }

Please consider this very trivial C code, which was run on 15.3.1 of macos: #include <stdio.h> #include <stdlib.h> #include <netinet/in.h> #include <arpa/inet.h> #include "sys/socket.h" #include <string.h> #include <unistd.h> #include <ifaddrs.h> #include <net/if.h> // prints out the sockaddr_in6 void print_addr(const char *msg_prefix, struct sockaddr_in6 sa6) { char addr_text[INET6_ADDRSTRLEN] = {0}; printf("%s%s:%d, addr family=%u\n", msg_prefix, inet_ntop(AF_INET6, &sa6.sin6_addr, (char *) &addr_text, INET6_ADDRSTRLEN), sa6.sin6_port, sa6.sin6_family); } // creates a datagram socket int create_dgram_socket() { const int fd = socket(AF_INET6, SOCK_DGRAM, 0); if (fd < 0) { perror("Socket creation failed"); return -1; } return fd; } int main() { printf("current process id:%ld parent process id: %ld\n", (long) getpid(), (long) getppid()); // // hardcode a link-local IPv6 address of a interface which is down // ifconfig: // ,,, // awdl0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500 // options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> // ... // inet6 fe80::34be:50ff:fe14:ecd7%awdl0 prefixlen 64 scopeid 0x10 // nd6 options=201<PERFORMNUD,DAD> // media: autoselect (<unknown type>) // status: inactive // const char *ip6_addr_str = "fe80::34be:50ff:fe14:ecd7"; // link-local ipv6 address from above ifconfig output // parse the string literal to in6_addr struct in6_addr ip6_addr; int rv = inet_pton(AF_INET6, ip6_addr_str, &ip6_addr); if (rv != 1) { fprintf(stderr, "failed to parse ipv6 addr %s\n", ip6_addr_str); exit(EXIT_FAILURE); } // create a AF_INET6 SOCK_DGRAM socket const int sock_fd = create_dgram_socket(); if (sock_fd < 0) { exit(EXIT_FAILURE); } printf("created a socket, descriptor=%d\n", sock_fd); // create a destination sockaddr which points to the above // ipv6 link-local address and an arbitrary port const int dest_port = 12345; struct sockaddr_in6 dest_sock_addr; memset((char *) &dest_sock_addr, 0, sizeof(struct sockaddr_in6)); dest_sock_addr.sin6_addr = ip6_addr; dest_sock_addr.sin6_port = htons(dest_port); dest_sock_addr.sin6_family = AF_INET6; dest_sock_addr.sin6_scope_id = 0x10; // scopeid from the above ifconfig output // now sendto() to that address, whose network interface is down. // we expect sendto() to return an error print_addr("sendto() to ", dest_sock_addr); const char *msg = "hello"; const size_t msg_len = strlen(msg) + 1; rv = sendto(sock_fd, msg, msg_len, 0, (struct sockaddr *) &dest_sock_addr, sizeof(dest_sock_addr)); if (rv == -1) { perror("sendto() expectedly failed"); close(sock_fd); exit(EXIT_FAILURE); } printf("sendto() unexpectedly succeeded\n"); // should not reach here, we expect sendto() to return an error return 0; } It creates a SOCK_DGRAM socket and attempts to sendto() to a link-local IPv6 address of a local network interface which is not UP. The sendto() is expected to fail with a "network is down" (or at least fail with some error). Let's see how it behaves. Copy that code to a file called netdown.c and compile it as follows: clang netdown.c Now run the program: ./a.out That results in the following output: current process id:29290 parent process id: 21614 created a socket, descriptor=3 sendto() to fe80::34be:50ff:fe14:ecd7:14640, addr family=30 sendto() unexpectedly succeeded (To reproduce this locally, replace the IPv6 address in that code with a link-local IPv6 address of an interface that is not UP on your system) Notice how the sendto() returned successfully without any error giving an impression to the application code that the message has been sent. In reality, the message isn't really sent. Here's the system logs from that run: PID Type Date & Time Process Message debug 2025-03-13 23:36:36.830147 +0530 kernel Process (a.out) allowed via dev tool environment (/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal) debug 2025-03-13 23:36:36.833054 +0530 kernel [SPI][HIDSPI] TX: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RX: 20 02 00 00 00 00 38 00 10 02 00 17 00 00 2E 00 26700 error 2025-03-13 23:36:36.838607 +0530 nehelper Failed to get the signing identifier for 29290: No such process 26700 error 2025-03-13 23:36:36.838608 +0530 nehelper Failed to get the code directory hash for 29290: No such process default 2025-03-13 23:36:36.840070 +0530 kernel cfil_dispatch_attach_event:3507 CFIL: Failed to get effective audit token for <sockID 22289651233205710 <4f3051d7ec2dce>> 26700 error 2025-03-13 23:36:36.840678 +0530 nehelper Failed to get the signing identifier for 29290: No such process 26700 error 2025-03-13 23:36:36.840679 +0530 nehelper Failed to get the code directory hash for 29290: No such process default 2025-03-13 23:36:36.841742 +0530 kernel cfil_hash_entry_log:6082 <CFIL: Error: sosend_reinject() failed>: [29290 ] <UDP(17) out so 891be95f39bd0385 22289651233205710 22289651233205710 age 0> lport 60244 fport 12345 laddr fe80::34be:50ff:fe14:ecd7 faddr fe80::34be:50ff:fe14:ecd7 hash D7EC2DCE default 2025-03-13 23:36:36.841756 +0530 kernel cfil_service_inject_queue:4466 CFIL: sosend() failed 50 Notice the last line where it states the sosend() (and internal impl detail of macos) failed with error code 50, which corresponds to ENETDOWN ("Network is down"). However, like I noted, this error was never propagated back to the application from the sendto() system call. The documentation of sendto() system call states: man sendto ... Locally detected errors are indicated by a return value of -1. ... RETURN VALUES Upon successful completion, the number of bytes which were sent is returned. Otherwise, -1 is returned and the global variable errno is set to indicate the error. So I would expect sendto() to return -1, which it isn't. The 15.3.1 source of xnu hasn't yet been published but there is the 15.3 version here https://github.com/apple-oss-distributions/xnu/tree/xnu-11215.81.4 and looking at the corresponding function cfil_service_inject_queue, line 4466 (the one which is reported in the logs) https://github.com/apple-oss-distributions/xnu/blob/xnu-11215.81.4/bsd/net/content_filter.c#L4466, the code there logs this error and the cfil_service_inject_queue function then returns back the error. However, looking at the call sites of the call to cfil_service_inject_queue(...), there are several places within that file which don't track the return value (representing an error value) and just ignore it. Is that intentional and does that explain this issue? Does this deserve to be reported as a bug through feedback assistant?

I created a self signed CA and use it to generate/sign a client cert using openssl. Then I use the self signed client cert to do TLS client authentication with my server (which also uses the self signed CA). The issue I have is when I validate the self signed CA, by calling SecTrustEvaluateAsyncWithError, it always complains this error “'DigiCert Global Root G3' certificate is not trusted". However that CA (DigiCert Global Root G3) is not my self signed CA (my CA is 'MQTTSampleCA' and I attached a dump of the my CA cert in the PR in the end of this post), so I'm confused why the API keeps complaining that CA. After some researching, I see that is a well known CA so I download its cert from https://www.digicert.com/kb/digicert-root-certificates.htm, install and trust it on my iOS device, but that doesn't help and I still get the same error. I provide all the repro steps in this PR: https://github.com/liumiaojq/EmCuTeeTee/pull/1, including how I generate the certs and the source codes of a test app that I used to do cert validation. I appreciate if anyone can share insights how to resolve this error.

In TN3179 under "macOS considerations" there are a set of instances where local network privacy does not apply: macOS automatically allows local network access by: Any daemon started by launchd Any program running as root Command-line tools run from Terminal or over SSH, including any child processes they spawn I am running some tests in my app that use the local network, attempting to run them from both the terminal app and from a VScode terminal and I am getting permissions prompts. After allowing these pop ups, some of the tests still fail as if networking was blocked.

Hey! We are investigating a problem pf rules being ignored by some processes. Despite blocking all traffic, some outgoing unicast packets can be seen in tcpdump. Issue is present in MacOS 15.0.0 - 15.3.1 (Newest at the time of writing). I tested MacOS 14.7.4 and pf rules there behaved as expected. Steps to reproduce the issue: $ cat pf.conf block all $ sudo pfctl -e -F all -f ./pf.conf Password: pfctl: Use of -f option, could result in flushing of rules present in the main ruleset added by the system at startup. See /etc/pf.conf for further details. No ALTQ support in kernel ALTQ related functions disabled rules cleared nat cleared dummynet cleared 0 tables deleted. 196 states cleared source tracking entries cleared pf: statistics cleared pf: interface flags reset pfctl: pf already enabled After executing these commands MacOS 14 will block all outgoing unicast traffic, and on MacOS 15 data can be sent to arbitrary addresses: $ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> ether b6:5e:a5:c5:1e:db inet6 fe80::1090:9c8:4325:329a%en0 prefixlen 64 secured scopeid 0xe inet 192.168.50.144 netmask 0xffffff00 broadcast 192.168.50.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active $ sudo tcpdump -k A -i any -n src 192.168.50.144 tcpdump: data link type PKTAP tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes 12:05:12.673472 (en0, proc com.apple.geod:1286:, svc BE, out, ch, flowid 0x0, ttag 0x0, dlt 0x1, cmpgc 0x0) IP 192.168.50.144.52012 > 17.253.15.196.443: Flags [P.], seq 1888882378:1888882402, ack 3554898220, win 2048, options [nop,nop,TS val 2752050055 ecr 1291585385], length 24 12:05:13.793937 (en0, proc com.apple.WebKit:974:, eproc Safari:804:, svc BE, out, ch, flowid 0x0, ttag 0x0, dlt 0x1, cmpgc 0x0) IP 192.168.50.144.52024 > 3.65.102.105.443: Flags [P.], seq 2011312019:2011312073, ack 673002582, win 2048, options [nop,nop,TS val 777228223 ecr 484269939], length 54 Was there any change in the way pfctl is used or is this a bug? This issue affects negatively privacy features of our product.

Hi, We have an issue (https://github.com/actions/runner-images/issues/10924) raised by a user requesting to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners. Apple introduced a new LNP policy with macOS Sequoia that is not controlled by TCC or MDM. Could you please guide us on how to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners? Thanks.

When I used the iPhone 11 to scan the wifi connection, the system reported an error,   ‘’’ let config = NEHotspotConfiguration(ssid: name, passphrase: passwd, isWEP: false) let manager = NEHotspotConfigurationManager() manager.apply(config) { error in      } ’’’ NEHotspotConfigurationErrorDomain Code=8 “internal error.” , the only thins that fixes this issue it restarting the iPhone. What is the reason for this and how to solve it? Reference link: https://developer.apple.com/forums/thread/111638 https://cloud.tencent.com/developer/ask/sof/114654981