General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk TCP and UDP ports used by Apple software products support article Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. WWDC 2025 Session 250 Use structured concurrency with Network framework — This is a great introduction to the new Network framework API introduced in appleOS 2026. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Wi-Fi (general): How to modernize your captive network developer news post Wi-Fi Fundamentals forums post Filing a Wi-Fi Bug Report forums post Working with a Wi-Fi Accessory forums post — This is part of the Extra-ordinary Networking series. Wi-Fi (iOS): TN3111 iOS Wi-Fi API overview technote Wi-Fi Aware framework documentation Building peer-to-peer apps sample code WirelessInsights framework documentation iOS Network Signal Strength forums post Network Extension Resources Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. WWDC 2025 Session 314 Get ahead with quantum-secure cryptography Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Prepare your network environment for stricter security requirements support article — This is primarily of interest to folks developing management software, for example, an MDM server. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

My name Mackenzy Paul NY Brooklyn I’ve been cyber attacked and bullied THIS IS A SOS WHISTLE BLOWER SITUATION IMEI2 phantom key multiple states and countries VPN My accounts compromised this is my third apple account that I use They use my own temper with all my apps maps website ai chats I need help PLEASE This is some on my unresolved cases Case ID: 102965382189 102981488804 102963333057 102973402555 102956650340 102951801746 241452559 102965171387 and plenty more please

I filed FB25058707 and wanted to make sure it reaches the right people, because it causes silent datagram loss that's hard to trace. On macOS, when a dual-stack UDP socket (AF_INET6 with IPV6_V6ONLY=0) binds [::]:0, the kernel sometimes gives it a port that an AF_INET socket already has bound to 127.0.0.1. Datagrams sent to 127.0.0.1 on that port then go to the AF_INET socket, so the dual-stack socket never receives them. An explicit bind of the same socket to that port fails with EADDRINUSE; only port-0 assignment hands it out. This program binds 1000 AF_INET sockets to 127.0.0.1:0, then binds dual-stack sockets to [::]:0 and checks where a datagram to 127.0.0.1:port lands whenever the port is already held. It's loopback only and runs in a few seconds: /* * A dual-stack UDP socket (AF_INET6, IPV6_V6ONLY=0) bound to [::]:0 can be * assigned a port already bound by an AF_INET socket on 127.0.0.1. Datagrams * to 127.0.0.1:port then reach the AF_INET socket, not the dual-stack one. * Loopback only. Build: cc -O2 -o dualstack_port0 dualstack_port0.c */ #include <arpa/inet.h> #include <errno.h> #include <netinet/in.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/resource.h> #include <sys/socket.h> #include <sys/time.h> #include <unistd.h> #define HELD 1000 #define TRIALS 2000 static int held[65536]; static void die(const char *what) { perror(what); exit(1); } static int port_of(int s) { struct sockaddr_storage ss; socklen_t len = sizeof(ss); if (getsockname(s, (struct sockaddr *)&ss, &len) != 0) die("getsockname"); if (ss.ss_family == AF_INET) return ntohs(((struct sockaddr_in *)&ss)->sin_port); return ntohs(((struct sockaddr_in6 *)&ss)->sin6_port); } static int bind_v4(in_addr_t addr) { int s = socket(AF_INET, SOCK_DGRAM, 0); if (s < 0) die("socket AF_INET"); struct sockaddr_in sin = { .sin_len = sizeof(sin), .sin_family = AF_INET, .sin_addr.s_addr = addr }; if (bind(s, (struct sockaddr *)&sin, sizeof(sin)) != 0) die("bind AF_INET"); return s; } static int bind_dual(void) { int s = socket(AF_INET6, SOCK_DGRAM, 0), off = 0; if (s < 0) die("socket AF_INET6"); if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &off, sizeof(off)) != 0) die("IPV6_V6ONLY"); struct sockaddr_in6 sin6 = { .sin6_len = sizeof(sin6), .sin6_family = AF_INET6, .sin6_addr = in6addr_any }; if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) != 0) die("bind AF_INET6"); return s; } /* Returns 1 if s receives token within 100ms, skipping other datagrams. */ static int got(int s, const char *token) { struct timeval tv = { .tv_sec = 0, .tv_usec = 100000 }; if (setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) != 0) die("SO_RCVTIMEO"); char buf[64]; for (;;) { ssize_t n = recv(s, buf, sizeof(buf) - 1, 0); if (n < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) return 0; die("recv"); } buf[n] = 0; if (strcmp(buf, token) == 0) return 1; } } int main(void) { struct rlimit rl; if (getrlimit(RLIMIT_NOFILE, &rl) != 0) die("getrlimit"); rl.rlim_cur = rl.rlim_max < 4096 ? rl.rlim_max : 4096; if (setrlimit(RLIMIT_NOFILE, &rl) != 0) die("setrlimit"); memset(held, -1, sizeof(held)); for (int i = 0; i < HELD;) { int s = bind_v4(htonl(INADDR_LOOPBACK)), p = port_of(s); if (held[p] >= 0) { close(s); continue; } held[p] = s; i++; } int sender = bind_v4(htonl(INADDR_LOOPBACK)); for (int dual = 1; dual >= 0; dual--) { int collisions = 0, to_held = 0, to_wild = 0; for (int i = 0; i < TRIALS; i++) { int w = dual ? bind_dual() : bind_v4(htonl(INADDR_ANY)), p = port_of(w); if (held[p] >= 0) { collisions++; char token[32]; snprintf(token, sizeof(token), "%d-%d", dual, i); struct sockaddr_in to = { .sin_len = sizeof(to), .sin_family = AF_INET, .sin_port = htons(p), .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; if (sendto(sender, token, strlen(token), 0, (struct sockaddr *)&to, sizeof(to)) < 0) die("sendto"); to_held += got(held[p], token); to_wild += got(w, token); } close(w); } printf("%s: %d/%d wildcard binds got a port held by a 127.0.0.1 socket; the probe reached that socket %d times, the wildcard socket %d times\n", dual ? "AF_INET6 V6ONLY=0 [::]:0" : "AF_INET 0.0.0.0:0 ", collisions, TRIALS, to_held, to_wild); } return 0; } On macOS 27.0 (26A428): AF_INET6 V6ONLY=0 [::]:0: 122/2000 wildcard binds got a port held by a 127.0.0.1 socket; the probe reached that socket 122 times, the wildcard socket 0 times AF_INET 0.0.0.0:0 : 0/2000 wildcard binds got a port held by a 127.0.0.1 socket; the probe reached that socket 0 times, the wildcard socket 0 times macOS 15.8.1 x86_64 gives the same pattern, and a Go version of the test reproduces on 15.7.9 and 26.6.2 as well. FreeBSD 15.1 gives 0/2000 with a dual-stack socket. From the public XNU source (xnu-12377.121.6), in6_pcbsetport checks candidate ports with in6_pcblookup_local, which skips PCBs without INP_IPV6, while in6_pcbbind does an IPv4 PCB lookup for dual-stack wildcard binds. That would explain why an explicit bind is refused but port 0 isn't. This is the cause of the long-standing Go issue golang/go#67226, since Go's net.ListenUDP("udp", 0.0.0.0:0) creates exactly this socket, and of intermittent failures in QUIC client tests. Using an AF_INET socket for IPv4-only traffic avoids it, but there's no workaround for a socket that needs both families on one port.

On macos 27, there appears to be a change in the setsockopt() implementation for the SO_LINGER option. It looks like the implementation now imposes a different maximum limit on the value that is accepted for linger. Consider the trivial attached C program. Rename it from main.c.txt to main.c. Compiling it (using clang main.c) and running it (using ./a.out), on older versions of macos (like 26.x), it returns: ----------------------- MacOS version: 26.7.1 Kernel version: Darwin Kernel Version 25.6.0: Tue Aug 18 17:49:13 PDT 2026; root:xnu-12377.161.15.700.19~2/RELEASE_ARM64_T6000 ----------------------- SUCCESS - set SO_LINGER to value 10 SUCCESS - set SO_LINGER to value 42 SUCCESS - set SO_LINGER to value 1024 SUCCESS - set SO_LINGER to value 32767 SUCCESS - set SO_LINGER to value 32768 SUCCESS - set SO_LINGER to value 65535 SUCCESS - set SO_LINGER to value 65536 SUCCESS - set SO_LINGER to value 65578 However, on macos 27, this now fails with EDOM error ("Numerical argument out of domain") for values greater than 32767: ----------------------- MacOS version: 27.0.1 Kernel version: Darwin Kernel Version 27.0.0: Tue Aug 11 21:02:16 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T8112 ----------------------- SUCCESS - set SO_LINGER to value 10 SUCCESS - set SO_LINGER to value 42 SUCCESS - set SO_LINGER to value 1024 SUCCESS - set SO_LINGER to value 32767 FAILURE - failed to set SO_LINGER to value 32768, reason: Numerical argument out of domain FAILURE - failed to set SO_LINGER to value 65535, reason: Numerical argument out of domain FAILURE - failed to set SO_LINGER to value 65536, reason: Numerical argument out of domain FAILURE - failed to set SO_LINGER to value 65578, reason: Numerical argument out of domain I'm guessing this is an intentional change, but I wanted to confirm nonetheless. Should the documentation of SO_LINGER and SO_LINGER_SEC socket options, in man setsockopt, mention the acceptable value range for them? main.c.txt

Please consider the trivial C program attached to this thread. The code creates a socket() and listen()s for connections, but (intentionally) doesn't accept() the connections. The listen() is done using a small backlog (of 1). This test then does several connect() attempts and expects that the connect() attempts will accumulate in the pending queue and once the queue exceeds the backlog limit, then as specified in man listen: The backlog parameter defines the maximum length for the queue of pending connections. If a connection request arrives with the queue full, the client may receive an error with an indication of ECONNREFUSED. then the connect() attempt will receive a ECONNREFUSED. However, in macos 27, such a connect() attempt leads to ECONNRESET (Connection reset by peer) instead of ECONNREFUSED. Is this expected? Experiments show that prior versions of macos were returning a ETIMEDOUT for such connect() attempts. If this new error is expected from connect() when the backlog limit has exceeded, should it be specified in the man listen documentation? Rename the attached main.c.txt to main.c. Compiling the attached program on macos 27, using clang main.c and then running ./a.out results in: ----------------------- MacOS version: 27.0.1 Kernel version: Darwin Kernel Version 27.0.0: Tue Aug 11 21:02:16 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T8112 ----------------------- started server at at 127.0.0.1:52753 with a backlog of 1 connect() attempt 1 - connected connect() attempt 2 - connected connect() attempt 3 - connected connect() attempt 4 - connected connect() attempt 5 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 connect() attempt 6 - connected connect() attempt 7 - connected connect() attempt 8 - connected connect() attempt 9 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 connect() attempt 10 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 connect() attempt 11 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 On a related note, it's unclear why several of the connect() attempts succeeded instead of just 1 of them succeeding. On prior versions of macos, the output of the same program is: ----------------------- MacOS version: 26.7.1 Kernel version: Darwin Kernel Version 25.6.0: Tue Aug 18 17:49:13 PDT 2026; root:xnu-12377.161.15.700.19~2/RELEASE_ARM64_T6000 ----------------------- started server at at 127.0.0.1:52451 with a backlog of 1 connect() attempt 1 - connected connect() attempt 2 - failed to connect() - Operation timed out connect() attempt 3 - failed to connect() - Operation timed out connect() attempt 4 - failed to connect() - Operation timed out connect() attempt 5 - failed to connect() - Operation timed out connect() attempt 6 - failed to connect() - Operation timed out connect() attempt 7 - failed to connect() - Operation timed out connect() attempt 8 - failed to connect() - Operation timed out connect() attempt 9 - failed to connect() - Operation timed out connect() attempt 10 - failed to connect() - Operation timed out connect() attempt 11 - failed to connect() - Operation timed out and this output is much more understandable and deterministic. main.c.txt

I've been investigating an issue with the SO_OOBINLINE socket option. When that option is disabled, the expectation is that out-of-band data that is sent on the socket will not be available through the use of read() or recv() calls on that socket. What we have been noticing is that when the socket is bound to a non-loopback address (and the communication is happening over that non-loopback address), then even when SO_OOBINLINE is disabled for the socket, the read()/recv() calls both return the out-of-band data. The issue however isn't reproducible with loopback address, and read()/recv() both correctly exclude the out-of-band data. This issue is only noticed on macos. I have been able to reproduce on macos M1, following version, but the original report which prompted me to look into this was reported on macos x64. My M1 OS version is: sw_vers ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 Attached is a reproducer (main.c.txt - rename it to main.c after downloading) that I have been able to develop which reproduces this issue on macos. When you compile and run that: ./a.out it binds to a non-loopback address by default and you should see the failure log, resembling: ... ERROR: expected: 1234512345 but received: 12345U12345 To run the same reproducer against loopback address, run it as: ./a.out loopback and that should succeed (i.e. no out-of-band data) with logs resembling: ... SUCCESS: completed successfully, expected: 1234512345, received: 1234512345 Is this a bug in the OS? I would have reported this directly through feedback assistant, but my past few open issues (since more than a year) have not even seen an acknowledgement or a reply, so I decided to check here first. main.c.txt

We have started seeing some unexplained behavioural differences in the BSD socket APIs on macos 26.6.x and macos 27. On a different front, there also seems to be some changes in the ptrace area for PT_DETACH. Historically, the release notes of macos don't include any mention of such changes. And unfortunately, prior experience of filing feedback assistant issues too hasn't been very motivating due to lack of any response on those tickets. These forums have been very helpful in trying to understand some of these changes, and I plan to raise separate topics for the issues shortly. In the past, the other useful option I have used is reading up the kernel sources published at https://opensource.apple.com/releases/. But there hasn't been any updates for macos 26.6 or macos 27. It will be very useful if macos 26.6 and 27 releases are published there. That will help expedite investigating some of these failures. BSD socket APIs in the recent releases of macos have seen several issues (feedback assistant issues have been filed). The implications of these failures is that we (in OpenJDK) have had to disable several tests on recent versions of macos which has reduced the test coverage and reliability of these very primitive networking APIs on this platform.

We have a group of Macs that mount SMB shares over 10 GbE with jumbo frames (MTU 9000). Since late June, they have been kernel panicking several times a day with the same assertion: panic(cpu N caller ...): assertion failed: m->m_flags & M_PKTHDR, file: .../xnu/bsd/kern/uipc_mbuf.c, line: 4839 @uipc_socket.c:8260 Panicked thread: dlil_input_en0 Last started kext: com.apple.filesystems.smbfs 6.0.1 Environment Clients: Mac Studio (M1 Max and M1 Ultra) and Mac Pro (2019, Intel with T2), using the built-in 10GBASE-T at MTU 9000 macOS 26.5.1 (25F80), 26.6.2 (25G83) and 26.7 (25G229); it panics on all three Servers: Samba-based NAS, SMB 3.1.1, signing on, encryption off Filed as FB24912731 What we've found It still panics with our third-party EDR fully uninstalled. The Mac that panics needs an active SMB session. A Mac left on the network without a share mounted stayed up through several events that took down the others. Panics are often simultaneous across machines: two to six Macs, with different hardware and different macOS builds, within the same minute. It doesn't need sustained heavy throughput. Some panics came within minutes of reconnecting, during light editing. Setting kern.skywalk.flowswitch.rx_agg_tcp_host=0 did not help. The switch and server links stay up, and spanning tree doesn't change during these events. Only the Macs' ports drop. In one server-side capture, the client stopped sending within about 0.2 ms of receiving a READ response made of 8948-byte frames. That fits the panicked thread being dlil_input. Two existing threads look related Kernel panic using Vagrant synced folders via NFS beginning with macOS 15.4 (FB17853906). A DTS reply there said the issue is in kernel mbuf management and that SMB "is very likely to experience a similar panic." Incorrect packet handling in SMBClient MacOS 26, which describes a race in SMBClient under heavy load above about 10 Gbps. Questions Is this the same underlying issue as FB17853906, and is a fix planned for macOS 26? Our 2019 Mac Pros can't move to a later major release. Is there a known workaround, such as a sysctl, an nsmb.conf option, or a change to MTU or offload settings? Is there logging or a diagnostic we can leave enabled to capture more state at panic time? We can't reproduce this on demand, but between several machines we see it multiple times a day. We can provide full panic reports, sysdiagnoses, and packet captures from both client and server sides.

I’m building a SwiftUI app that fetches public JSON data using URLSession.shared. The request works correctly in the iPhone 17 Pro Max Simulator, but fails on my physical iPhone 16 Pro Max running iOS 27 beta. Endpoint: https://api.jolpi.ca/ergast/f1/2026/driverstandings.json?limit=100 Error: NSURLErrorDomain Code=-1009 “The Internet connection appears to be offline.” NWPath: unsatisfied (Denied over Wi-Fi interface) Resolved 0 endpoints in 1ms The device can access the endpoint through Safari, and the same request works in Simulator. VPN, cellular permissions, Wi-Fi changes, and ATS settings have been checked. Could this be an iOS 27 beta networking regression affecting URLSession on physical devices? Are there recommended workarounds or diagnostics?

I'm trying to write a NWProtocolFramerImplementation class that will be channeled through a Framer wrapper. There are still some parts I need figuring out. For handleOutput(framer: message: messageLength: isComplete), what do the last two parameters do? Does isComplete refer to the end of the current conversation, or the entire connection? Why would we submit a messageLength if the data size should already be implied within message? If I parse by line breaks, is there a way to indicate if the latest line is the last of the current conversation, either input or output?

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" Network Interface APIs Most developers don’t need to interact directly with network interfaces. If you do, read this post for a summary of the APIs available to you. Before you read this, read Network Interface Concepts. Interface List The standard way to get a list of interfaces and their addresses is getifaddrs. To learn more about this API, see its man page. A network interface has four fundamental attributes: A set of flags — These are packed into a CUnsignedInt. The flags bits are declared in <net/if.h>, starting with IFF_UP. An interface type — See Network Interface Type, below. An interface index — Valid indexes are greater than 0. A BSD interface name. For example, an Ethernet interface might be called en0. The interface name is shared between multiple network interfaces running over a given hardware interface. For example, IPv4 and IPv6 running over that Ethernet interface will both have the name en0. WARNING BSD interface names are not considered API. There’s no guarantee, for example, that an iPhone’s Wi-Fi interface is en0. You can map between the last two using if_indextoname and if_nametoindex. See the if_indextoname man page for details. An interface may also have address information. If present, this always includes the interface address (ifa_addr) and the network mask (ifa_netmask). In addition: Broadcast-capable interfaces (IFF_BROADCAST) have a broadcast address (ifa_broadaddr, which is an alias for ifa_dstaddr). Point-to-point interfaces (IFF_POINTOPOINT) have a destination address (ifa_dstaddr). Calling getifaddrs from Swift is a bit tricky. For an example of this, see QSocket: Interfaces. IP Address List Once you have getifaddrs working, it’s relatively easy to manipulate the results to build a list of just IP addresses, a list of IP addresses for each interface, and so on. QSocket: Interfaces has some Swift snippets that show this. Interface List Updates The interface list can change over time. Hardware interfaces can be added and removed, network interfaces come up and go down, and their addresses can change. It’s best to avoid caching information from getifaddrs. If thats unavoidable, use the kNotifySCNetworkChange Darwin notification to update your cache. For information about registering for Darwin notifications, see the notify man page (in section 3). This notification just tells you that something has changed. It’s up to you to fetch the new interface list and adjust your cache accordingly. You’ll find that this notification is sometimes posted numerous times in rapid succession. To avoid unnecessary thrashing, debounce it. While the Darwin notification API is easy to call from Swift, Swift does not import kNotifySCNetworkChange. To fix that, define that value yourself, calling a C function to get the value: var kNotifySCNetworkChange: UnsafePointer<CChar> { networkChangeNotifyKey() } Here’s what that C function looks like: extern const char * networkChangeNotifyKey(void) { return kNotifySCNetworkChange; } Network Interface Type There are two ways to think about a network interface’s type. Historically there were a wide variety of weird and wonderful types of network interfaces. The following code gets this legacy value for a specific BSD interface name: func legacyTypeForInterfaceNamed(_ name: String) -> UInt8? { var addrList: UnsafeMutablePointer<ifaddrs>? = nil let err = getifaddrs(&addrList) // In theory we could check `errno` here but, honestly, what are gonna // do with that info? guard err >= 0, let first = addrList else { return nil } defer { freeifaddrs(addrList) } return sequence(first: first, next: { $0.pointee.ifa_next }) .compactMap { addr in guard let nameC = addr.pointee.ifa_name, name == String(cString: nameC), let sa = addr.pointee.ifa_addr, sa.pointee.sa_family == AF_LINK, let data = addr.pointee.ifa_data else { return nil } return data.assumingMemoryBound(to: if_data.self).pointee.ifi_type } .first } The values are defined in <net/if_types.h>, starting with IFT_OTHER. However, this value is rarely useful because many interfaces ‘look like’ Ethernet and thus have a type of IFT_ETHER. Network framework has the concept of an interface’s functional type. This is an indication of how the interface fits into the system. There are two ways to get an interface’s functional type: If you’re using Network framework and have an NWInterface value, get the type property. If not, call ioctl with a SIOCGIFFUNCTIONALTYPE request. The return values are defined in <net/if.h>, starting with IFRTYPE_FUNCTIONAL_UNKNOWN. Swift does not import SIOCGIFFUNCTIONALTYPE, so it’s best to write this code in a C: extern uint32_t functionalTypeForInterfaceNamed(const char * name) { int fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { return IFRTYPE_FUNCTIONAL_UNKNOWN; } struct ifreq ifr = {}; strlcpy(ifr.ifr_name, name, sizeof(ifr.ifr_name)); bool success = ioctl(fd, SIOCGIFFUNCTIONALTYPE, &ifr) >= 0; int junk = close(fd); assert(junk == 0); if ( ! success ) { return IFRTYPE_FUNCTIONAL_UNKNOWN; } return ifr.ifr_ifru.ifru_functional_type; } Finally, TN3158 Resolving Xcode 15 device connection issues documents the SIOCGIFDIRECTLINK flag as a specific way to identify the network interfaces uses by Xcode for device connection traffic. Routing Sockets macOS supports the traditional BSD routine socket interface. See the route man page for details. Note You can access some routing socket functionality via sysctl, and all of this section applies to that as well. Other Apple platforms don’t support routing sockets [1]. On macOS it’s reasonable to use a routing socket to learn about the current state of the networking stack and be notified of changes to that state. Doing this on macOS 27 and later may require you to sign your code with the com.apple.developer.networking.topology-observation entitlement. In Xcode, add the Network Topology Observation capability [2] to your target. This is a restricted entitlement, which means it must be authorised by a provisioning profile. If you’re building a command-line tool, follow the advice in Signing a daemon with a restricted entitlement. Don’t use a routing socket to change the state of the networking stack. Such activities are not supported because macOS maintains its source of truth outside of the kernel, primarily in the System Configuration infrastructure [3]. If you make changes behind the back of this infrastructure then, in the best case, they’ll simply be overwritten at some point in the future, but in the worst case you could trigger stability problems. [1] You may or may not be able to open one, based on the current sandbox setup. Even if you can, that effort is not supported because the declarations required to use the socket, most obviously rt_msghdr, are only present in the macOS SDK. And no, copying declarations from one SDK to another is not supported (-; [2] There’s no link to the docs for this capability because that hasn’t yet landed (r. 181611259). [3] See System Configuration Programming Guidelines for a general introduction this architecture. Revision History 2026-09-23 Added the Routing Sockets section. 2025-12-10 Added info about SIOCGIFDIRECTLINK. 2023-07-19 First posted.

I am developing a consumer iOS app for App Store distribution and would like to confirm the appropriate public API for the following use case. The app needs to measure the amount of network traffic passing through the device over short time intervals, for example once per second or more frequently. The app does not need to inspect packet contents, block or filter traffic, or provide a remote VPN service. It also should not generate dedicated network traffic solely for speed measurement. The goal is only to observe device-wide network traffic volume and convert that information into a simple real-time indicator for the user. I am currently investigating the Network Extension framework. Would NEPacketTunnelProvider be an appropriate API for this use case? If not, is there another supported Network Extension provider or other public iOS API intended for measuring device-wide network traffic in this manner? I would like to choose an architecture that is technically supported by Apple and appropriate for a consumer app distributed through the App Store before beginning implementation.

Hello, Feedback Assistant report: FB24876147. I develop a Unity-based iOS app. Some customers in mainland China report losing Internet access after an app update, while most installations continue working. We have received similar reports since at least iOS 16, across several years and multiple app releases. Earlier iOS versions are uncertain, and we cannot confirm that all historical occurrences share the same cause. Updates without networking-code changes can be followed by failures. A later update sometimes restores connectivity, but not consistently. Customer-reported recovery attempts: The app's wireless-data permissions appear enabled in Settings. Switching the app's network permission to another setting and back did not help users who reported trying it. Reset Network Settings also did not help users who reported trying it. Some users reported that deleting and reinstalling the app restored connectivity. At least one user reported that deletion and reinstallation did not help. These are customer reports, not controlled tests on our development devices. We would prefer a recovery that preserves local save data. Captured evidence from one affected installation: App version 1.89, build 1; Unity 2022.3.62f3. Device identifier: iPhone18,1; iOS 26.2.1. App in foreground. Capture time: 2026-09-07 13:04:31–13:04:32 UTC. An unfiltered Network.framework default-path monitor reported: status=unsatisfied reason=wifiDenied interface=Wi-Fi UnityWebRequest and a newly created native ephemeral NSURLSession both failed against our public HTTPS origin and Apple's independent test endpoint: https://www.apple.com/library/test/success.html The native requests failed after approximately 1 ms and 3 ms, with NSURLErrorDomain -1009, underlying kCFErrorDomainCFNetwork -1009, and no HTTP response. The native session allowed cellular, expensive and constrained network access, used normal TLS verification, and had waitsForConnectivity=false. It bypassed Unity's reachability precheck. CTCellularData changed from unknown to notRestricted. We understand this does not establish successful cellular connectivity or Wi-Fi permission. Important limitations: The native probes ran inside the same Unity-built process, not a separate standalone native app. The captured measurements demonstrate a Wi-Fi failure. Cellular failures and enabled Settings permissions are customer reports, not independently verified by these measurements. We cannot reliably reproduce the affected state on our development devices and do not have a focused Xcode project that reproduces it. An affected-device sysdiagnose is not yet available. Unity Customer QA reviewed this evidence, assessed it as an iOS network-policy issue rather than a Unity bug, and referred us to Apple. We are seeking Apple's investigation, not presenting that assessment as a confirmed root cause. The Code-Level Support form directed us to these forums because we cannot currently provide a focused reproducer. Questions: Which affected-device diagnostics or logging profiles would help identify why the effective network policy reports wifiDenied? How should we investigate an installation-specific issue when a new minimal app may not reproduce that installation state? Is there a supported, data-preserving recovery or application-side mitigation when permission changes and network resets do not help, and reinstallation is not consistently effective? We have diagnostic screenshots and relevant probe source available. Any customer system logs would be collected with consent and shared privately with Apple, not posted publicly. Thank you.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

The documentation is pretty much blank. The same thing applies to the root NetworkProtocolOptions protocol. What are ContentType, LegacyMessage, BelowProtocol, Metadata, and ProtocolStorage? I can't determine if I should use these or not.

Hello! Users of my app observed behaviour that some apps stopped working after update to 15.7.8 via Beta channel with transparent proxy network extension on. The app receives Protocol not available error, and I see setsockopt SO_FLOW_DIVERT_TOKEN failed [42: Protocol not available] error in Console. To reproduce, create two rules in basic NETransparentProxyProvider: [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolTCP], [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolUDP], You may even return NO in handleNewFlow, it does not matter. After that, Safari won't open some sites, and Weather app will work unreliably. Do anyone knows any workaround for this problem? I've also create a relevant FB23788740.

Hi— App review said: The app uses one or more entitlements which do not have matching functionality within the app. Apps should have only the minimum set of entitlements necessary for the app to function properly. Please remove all entitlements that are not needed by the app and submit an updated binary for review, including the following: • com.apple.security.device.camera • com.apple.security.network.server …but my app has a feature that does use the camera (continuity camera for macOS, and a bonjour feature for finding other local app instances, establishing a link, and sending data to other instances. I’ve tried declaring/justifying talking about it in App testing info and in my reply to the reviewer, about how to access the features that require it. do I really not need these entitlements and only seems like I would? do I simply test app scheme Release > no debug executable with fresh sandbox and see if features break? But no declaring these things seems like the opposite of what Apple would want… it seems like explicitly calling out these features makes a lot more sense? this is my first app— thank you

We have a NEPacketTunnelProvider extension that intercepts and modifies DNS responses for specific hostnames as part of its normal operation. On iOS 27, we are seeing this interception being intermittently bypassed. Our extension still receives the DNS query, builds a response, and returns it promptly, but the client occasionally proceeds using a different address, presumably the actual DNS resolution result. This behavior does not reproduce on iOS 26 or earlier. The timing in our logs appears to correlate with the new Connectivity Assist feature (Settings → Wi-Fi), which Apple describes as using cellular data alongside Wi-Fi to improve reliability. Our suspicion is that Connectivity Assist may be performing DNS resolution over a cellular path in parallel, outside the tunnel, causing that resolution path to bypass our provider entirely. We have ruled out response timing and response format issues on our side. Varying the speed and format of our responses does not affect the outcome, suggesting that the behavior is occurring at a layer above the tunnel provider. We have the following questions: Does Connectivity Assist perform DNS resolution on a network path that can bypass an active NEPacketTunnelProvider? Is there any API, entitlement, or supported mechanism to disable Connectivity Assist for an app, or to ensure that all DNS resolution is routed through the active tunnel, similar to previous Wi-Fi Assist opt-out capabilities? Would a NEDNSProxyProvider-based DNS proxy be affected in the same way, or does it operate at a layer that Connectivity Assist cannot bypass? Any guidance, references to relevant documentation, WWDC session content, or confirmation of the expected behavior would be greatly appreciated.

I am trying to create an app where I have multiple users modifying an entity at runtime similar to collaborative digital sculpting using SharePlay on VisionOS. When creating a collaborative experience using other 3D engines I have utilized an external server that devices send and update their state from serving as a global "source of truth". This doesn't seem to be the intended workflow for SharePlay which seemingly only allows for device to device messaging. While this works for a variety of apps it doesn't provide a smooth experience when multiple users are interacting with and manipulating the same 3D entity. Is there an intended way to do this for SharePlay? Would the best practice be to have one user serve as a host and establish a "source of truth" based on their app state? The closest example in documentation I have found is an example for using SharePlay in a drawing app. When a user is drawing they send the information for their realtime stroke through unreliable SharePlay messages and then, when they've finished, they send a reliable message with the final line. This technique makes sense for the given example since there is no scenario where multiple users would be drawing the same line, but it seemingly falls short for my use case since multiple users can sculpt in the same area of a given mesh. What would the intended approach be to achieve this with SharePlay? Is it simply a limitation of this type of networking? Thanks!

Hello, I am investigating a roaming network selection use case on iPhone and would like to know whether Apple provides any supported API, entitlement, carrier capability, or carrier-specific integration that allows an application or a mobile network operator to access or control PLMN selection while roaming. My specific use case is: Device: iPhone 17 iOS: 26.6.1 Home operator: Orange France Roaming country: Switzerland Automatically selected roaming network: Salt Preferred roaming network: Swisscom At this location, Salt has very poor cellular coverage while Swisscom has excellent coverage. The user can manually select Swisscom through: Settings → Cellular → Network Selection → Swisscom I would like to determine whether there is any supported mechanism for a carrier or a carrier-authorized application to: Read the currently selected roaming PLMN. Obtain the available roaming PLMNs. Programmatically select a specific PLMN. Configure a preferred roaming PLMN. Ask the modem to prefer one roaming partner over another. Access any carrier-only/private entitlement that provides such functionality. For example, could an authorized Orange carrier application or carrier integration request that Swisscom (MCC 228 / MNC 01) be preferred over Salt (MCC 228 / MNC 03) while roaming in Switzerland? I understand that Core Telephony provides access to some carrier information and that certain capabilities require Apple-granted entitlements. If this functionality is not available to third-party applications, is there a carrier integration, carrier configuration, SIM/eSIM profile mechanism, or other Apple-supported mechanism that can influence the preferred roaming PLMN? I am specifically looking for a supported solution and not a jailbreak or other unsupported/private API. Thank you.