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" On Host Names I commonly see questions like How do I get the device’s host name? This question doesn’t make sense without more context. Apple systems have a variety of things that you might consider to be the host name: The user-assigned device name — This is a user-visible value, for example, Guy Smiley. People set this in Settings > General > About > Name. The local host name — This is a DNS name used by Bonjour, for example, guy-smiley.local. By default this is algorithmically derived from the user-assigned device name. On macOS, people can override this in Settings > General > Sharing > Local hostname. The reverse DNS name associated with the various IP addresses assigned to the device’s various network interfaces That last one is pretty much useless. You can’t get a single host name because there isn’t a single IP address. For more on that, see Don’t Try to Get the Device’s IP Address. The other two have well-defined answers, although those answers vary by platform. I’ll talk more about that below. Before getting to that, however, let’s look at the big picture. Big Picture The use cases for the user-assigned device name are pretty clear. I rarely see folks confused about that. Another use case for this stuff is that you’ve started a server and you want to tell the user how to connect to it. I discuss this in detail in Showing Connection Information in an iOS Server. However, most folks who run into problems like this do so because they’re suffering from one of the following misconceptions: The device has a DNS name. Its DNS name is unique. Its DNS name doesn’t change. Its DNS name is in some way useful for networking. Some of these may be true in some specific circumstances, but none of them are true in all circumstances. These issues are not unique to Apple platforms — if you look at the Posix spec for gethostname, it says nothing about DNS! — but folks tend to notice these problems more on Apple platforms because Apple devices are often deployed to highly dynamic network environments. So, before you start using the APIs discussed in this post, think carefully about your assumptions. And if you actually do want to work with DNS, there are two cases to consider: If you’re looking for the local host name, use the APIs discussed above. In other cases, it’s likely that the APIs in this post will not be helpful and you’d be better off focusing on DNS APIs [1]. [1] The API I recommend for this is DNS-SD. See the DNS section in TN3151 Choosing the right networking API. macOS To get the user-assigned device name, call the SCDynamicStoreCopyComputerName(_:_:) function. For example: let userAssignedDeviceName = SCDynamicStoreCopyComputerName(nil, nil) as String? To get the local host name, call the SCDynamicStoreCopyLocalHostName(_:) function. For example: let localHostName = SCDynamicStoreCopyLocalHostName(nil) as String? IMPORTANT This returns just the name label. To form a local host name, append .local.. Both routines return an optional result; code defensively! If you’re displaying these values to the user, use the System Configuration framework dynamic store notification mechanism to keep your UI up to date. iOS and Friends On iOS, iPadOS, tvOS, and visionOS, get the user-assigned device name from the name property on UIDevice. IMPORTANT Access to this is now restricted. For more on that, see the documentation for the com.apple.developer.device-information.user-assigned-device-name entitlement. There is no direct mechanism to get the local host name. Other APIs There are a wide variety of other APIs that purport to return the host name. These include: gethostname The name property on NSHost [1] The hostName property on NSProcessInfo (ProcessInfo in Swift) These are problematic for a number of reasons: They have a complex implementation that makes it hard to predict what value you’ll get back. They might end up trying to infer the host name from the network environment. The existing behaviour is hard to change due to compatibility concerns. Some of them are marked as to-be-deprecated. IMPORTANT The second issue is particularly problematic, because it involves synchronous DNS requests [2]. That’s slow in general. Worse yet, if the network environment is restricted in some way, these calls can be very slow, taking about 30 seconds to time out. Given these problems, it’s generally best to avoid calling these routines at all. [1] It also has a names property, which is a little closer to reality but still not particularly useful. [2] Actually, that’s not true for gethostname. Rather, that call just returns whatever was last set by sethostname. This is always fast. The System Configuration framework infrastructure calls sethostname to update the host name as the system state changes.

What is the best way to detect if the Wifi is being used for Wireless Carplay or is just a normal network interface?

The Wi‑Fi Alliance’s Wi‑Fi Aware data communication uses IPv6. However, in Chapter 53 “Wi‑Fi Aware” of the Accessory Design Guidelines for Apple Devices, Release R26, it is stated that “The Neighbor Discovery Protocol (NDP) for IPv6 address resolution is not supported.” This has caused confusion among developers: Does Apple’s Wi‑Fi Aware data communication actually use IPv6? What is the impact of “The Neighbor Discovery Protocol (NDP) for IPv6 address resolution is not supported” in Apple’s implementation?

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

Hi everyone, I’m developing an app called FindMyNet that allows users to find the best internet provider based on their postal code (CAP). The app is built with Xcode and the macOS simulator. I’ve set up a FastAPI backend that communicates with an Excel database containing internet provider data for each postal code. Unfortunately, when I try to run the app, I encounter an error that prevents me from retrieving data from the database and displaying the correct provider. Task <6B5C86B6-181A-4235-AE68-23AAF6645683>.<1> finished with error [1] Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <6B5C86B6-181A-4235-AE68-23AAF6645683>.<1>, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <6B5C86B6-181A-4235-AE68-23AAF6645683>.<1>" ), _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi} Problem description: • The FastAPI backend is running on a Raspberry Pi and communicates with the app via an HTTP request. • When I enter a postal code, the app should return the best provider for that region, but I only get a 500 error. • I’ve verified that the FastAPI server is running, but it seems there’s an issue with communication between the app and the server. Steps taken so far: • I’ve checked the logs on the FastAPI server, but there are no obvious errors. • I’ve manually tested the API using Postman, and it works fine, so the issue seems to be app-side. Support request: I’d like to understand better what could be causing this error and if anyone has had similar experiences. Any advice on diagnosing the problem or solutions for resolving it would be greatly appreciated. Thanks in advance for your help!

If I was to build an app that opened a web server at local host on a random port that resolved subdomains for local host at that port, but there was no certificate authority, signed certificate available to provide HTTPS security, would this be in violation of apples ATS policy

Hello, I have encountered an issue with an iPhone 15PM with iOS 18.5. The NSHTTPCookieStorage failed to clear cookies, after clearing them, I was still able to retrieve them. However, on the same system NSHTTPCookie *cookie; NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage]; for (cookie in [storage cookies]) { [storage deleteCookie:cookie]; } NSArray *cookies = [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookiesForURL:[[self url] absoluteURL]]; // still able to get cookies,why???

I'm trying to use NEHotspotNetwork to configure an IoT. I've read all the issues that have plagued other developers when using this framework, and I was under the impression that bugs were filed and fixed. Here are my issues in hopes that someone can catch my bug, or has finally figured this out and it's not a bug in the framework with no immediate fix on the horizon. If I use the following code: let config = NEHotspotConfiguration(ssid: ssid) config.joinOnce = true KiniStatusBanner.shared.show(text: "Connecting to Kini", in: presentingVC.view) NEHotspotConfigurationManager.shared.apply(config) { error in DispatchQueue.main.async { if let nsError = error as NSError?, nsError.domain == NEHotspotConfigurationErrorDomain, nsError.code == NEHotspotConfigurationError.alreadyAssociated.rawValue { print("Already connected to \(self.ssid)") KiniStatusBanner.shared.dismiss() self.presentCaptivePortal(from: presentingVC, activationCode: activationCode) } else if let error = error { // This doesn't happen print("❌ Failed to connect: \(error.localizedDescription)") KiniStatusBanner.shared.update(text: "Failed to Connect to Kini. Try again later.") KiniStatusBanner.shared.dismiss(after: 2.5) } else { // !!!! Most often, this is the path the code takes NEHotspotNetwork.fetchCurrent { current in if let ssid = current?.ssid, ssid == self.ssid { log("✅✅ 1st attempt: connected to \(self.ssid)") KiniStatusBanner.shared.dismiss() self.presentCaptivePortal(from: presentingVC, activationCode: activationCode) } else { // Dev forums talked about giving things a bit of time to settle and then try again DispatchQueue.main.asyncAfter(deadline: .now() + 2) { NEHotspotNetwork.fetchCurrent { current in if let ssid = current?.ssid, ssid == self.ssid { log("✅✅✅ 2nd attempt: connected to \(self.ssid)") KiniStatusBanner.shared.dismiss() self.presentCaptivePortal(from: presentingVC, activationCode: activationCode) } else { log("❌❌❌ 2nd attempt: Failed to connect: \(self.ssid)") KiniStatusBanner.shared.update(text: "Could not join Kini network. Try again.") KiniStatusBanner.shared.dismiss(after: 2.5) self.cleanupHotspot() DispatchQueue.main.asyncAfter(deadline: .now() + 2) { print("cleanup again") self.cleanupHotspot() } } } } log("❌❌ 1st attempt: Failed to connect: \(self.ssid)") KiniStatusBanner.shared.update(text: "Could not join Kini network. Try again.") KiniStatusBanner.shared.dismiss(after: 2.5) self.cleanupHotspot() } As you can see, one can't just use NEHotspotConfigurationManager.shared.apply and has to double-check to make sure that it actually succeeds, by checking to see if the SSID desired, matches the one that the device is using. Ok, but about 50% of the time, the call to NEHotspotNetwork.fetchCurrent gives me this error: NEHotspotNetwork nehelper sent invalid result code [1] for Wi-Fi information request Well, there is a workaround for that randomness too. At some point before calling this code, one can: let locationManager = CLLocationManager() locationManager.requestWhenInUseAuthorization() That eliminates the NEHotspotNetwork nehelper sent invalid result code [1] for Wi-Fi information request BUT... three issues. The user is presented with an authorization alert: Allow "Kini" to use your location? This app needs access to you Wi-Fi name to connect to your Kini device. Along with a map with a location pin on it. This gives my users a completely wrong impression, especially for a device/app where we promise users not to track their location. They actually see a map with their location pinned on it, implying something that would freak out anyone who was expecting no tracking. I understand why an authorization is normally required, but since all we are getting is our own IoT's SSID, there should be no need for an authorization for this, and no map associated with the request. Again, they are accessing my IoT's network, NOT their home/location Wi-Fi SSID. My app already knows and specifies that network, and all I am trying to do is to work around a bug that makes it look like I have a successful return from NEHotspotConfigurationManager.shared.apply() when in fact the network I was looking for wasn't even on. Not only do I get instances where the network doesn't connect, and result codes show no errors, but I also get instances where I get an alert that says that the network is unreachable, yet my IoT shows that the app is connected to its Wi-Fi. On the iOS device, I go to the Wi-Fi settings, and see that I am on the IoT's network. So basically, sometimes I connect, but the frameworks says that there is no connection, and sometimes it reports a connection when there is none. As you can see in the code, I call cleanupHotspot() to make the iOS device get off of my temp Wi-Fi SSID. This is the code: func cleanupHotspot() { NEHotspotConfigurationManager.shared.removeConfiguration(forSSID: ssid) } That code gets called by the above code when things aren't as I expect and need to cleanup. And I also call it when the user dismisses the viewcontroller that is attempting to make the connection. It doesn't always work. I get stuck on the tempo SSID, unless I go through this whole thing again: try to make the connection again, this time it succeeds quickly, and then I can disconnect. Any ideas? I'm on iOS18.5, and have tried this on multiple iPhones including 11, 13 and 16.

I had noticed that my slaac address changed between one beta and the other, but wasn't sure. Now with the RC 15.4 RC (24E247) I made point of preserving the info before updating from the previous beta. What I noticed is that not only the slaac address changes, but also the my ether address, even though I have it on Fixed in the settings. Is it expected that the ether, and the slaac, not be rotated after a OS update?

Hi everyone, I'm currently experimenting with building a simple DNS filter using Apple's Packet Tunnel framework. Here's the flow I'm trying to implement: Create a TUN interface Set up a UDP socket Read packets via packetFlow.readPackets Parse the raw IP packet Forward the UDP payload through the socket Receive the response from the server Reconstruct the IP packet with the response Write it back to the TUN interface using packetFlow.writePackets Here’s an example of an intercepted IP packet (DNS request): 45 00 00 3c 15 c4 00 00 40 11 93 d1 c0 a8 00 64 08 08 08 08 ed 6e 00 35 00 28 e5 c9 7f da 01 00 00 01 00 00 00 00 00 00 04 74 69 6d 65 05 61 70 70 6c 65 03 63 6f 6d 00 00 01 00 01 And here’s the IP packet I tried writing back into the TUN interface (DNS response): 45 00 00 89 5e 37 40 00 40 11 0b 11 08 08 08 08 c0 a8 00 64 00 35 ed 6e 00 75 91 e8 7f da 81 80 00 01 00 04 00 00 00 00 04 74 69 6d 65 05 61 70 70 6c 65 03 63 6f 6d 00 00 01 00 01 c0 0c 00 05 00 01 00 00 0c fb 00 11 04 74 69 6d 65 01 67 07 61 61 70 6c 69 6d 67 c0 17 c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 74 fd c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 74 7d c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 54 fb Unfortunately, it seems the packet is not being written back correctly to the TUN interface. I'm not seeing any expected DNS response behavior on the device. Also, I noticed that after creating the TUN, the interface address shows up as 0.0.0.0:0 in Xcode. The system log includes this message when connecting the VPN: NWPath does not have valid interface: satisfied (Path is satisfied), interface: utun20[endc_sub6], ipv4, dns, expensive, uses cellular Does anyone know how to properly initialize the TUN so that the system recognizes it with a valid IP configuration? Or why my written-back packet might be getting ignored? Any help would be appreciated!

1、已经检查过手机的存储空间，还有一百多G的空间。app端进行网络接口情况的时候报错了，报错信息如下： Error : Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <7DB1CBFD-B9BE-422D-9C9A-78D8FC04DC1B>.<76>, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=28, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <7DB1CBFD-B9BE-422D-9C9A-78D8FC04DC1B>.<76>" ), _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[lte], ipv4, ipv6, dns, expensive, estimated upload: 65536Bps, uses cell} 2、手机型号是iPhone 15 Plus，iOS 17.6.1

I need to know the https address of a certain page within my app. This is going to be used as a redirect URL. I don't think it is a good idea to use deep links because it has to be an https address. I don't think Universal Links will work because it is not my website that I will be communicating with.

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. Revision History 2025-12-10 Added info about SIOCGIFDIRECTLINK. 2023-07-19 First posted.

Hi! I'm working on a solution (iOS 18) that uses Network Extensions PacketTunnelProvider and Content Filter. Currently I'm trying to integrate it with another extension – DNSProxyProvider. My goal is to process dns queries and use resolved ips and names for additional routing inside of the packet tunnel. I'm running into a major issue: whenever both VPN and DNS proxy are active simultaneously, the device completely loses internet connectivity — no traffic goes through, and DNS resolution seems to stop working entirely. I know about the mdm supervision requirement to use DNSProxyProvider and that's covered as I work with a managed device and install a DNS proxy profile, here's how its .mobileconfig file looks like: The DNS proxy itself works fine when working by itself (without VPN being turned on), as I implemented it that it successfully processes DNS packets flows while collecting information about domains etc, and everything works perfectly. Problems begin when using VPN at the same time. I'm aware that tunnel settings include dns related options that can affect this, but I haven't had much luck with tweaking them. Here's how they look right now for reference: let settings: NEPacketTunnelNetworkSettings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "240.0.0.1") // let dnsSettings = NEDNSSettings(servers: "8.8.8.8,8.8.4.4".components(separatedBy: ",")) // dnsSettings.matchDomains = [""] // settings.dnsSettings = dnsSettings settings.proxySettings = nil /* ipv4 settings */ let ipv4Settings = NEIPv4Settings(addresses: ["240.0.0.2"], subnetMasks: ["255.255.255.0"]) ipv4Settings.includedRoutes = [NEIPv4Route.default()] settings.ipv4Settings = ipv4Settings /* MTU */ settings.mtu = 1500 return settings I've tried excluding some dns related ip routes and dns settings shenanigans but nothing. I haven't found any information that might suggest that using both of these extensions at the same time doesn't work, on the contrary, this page in the official documentation about the expected use of packet tunnel provider the expected use of packet tunnel provider, as it talks about the fact that you should not use it for interception of all of DNS traffic, as the use of DNSPRoxyProvider (or dns settings) are built for that, which in my mind, suggests that there should be no problem with using them both and just splitting the dns traffic handling to the proxy. Will be thankful for any help!

I have been polishing an app that connects and communicates between a tvOS app I created and a iPadOS app that I also created. Connection works fantastic! However, for some reason when the user selects the button to open the DevicePicker provided by this API and then selects a iPad device the notification that comes across the the iPad reads, "Connect your Apple TV to "AppName" on this iPhone. Is this a bug or am I missing some configuration in maybe Info.plist or a modifier I need to add the DevicePicker for it to communicate the proper device identification? I have everything setup in both app Info.plist files to connect and work fine, but the notification saying iPhone on an iPad is sadly a small detail I would love to change. So...not sure if I found a bug or if I am missing something.

Hello, Our app uses Network Extension / Packet Tunnel Provider to establish VPN connections on macOS and iOS. We have observed that after creating a utun device and adding any IPv4 routes (NEPacketTunnelNetworkSettings.IPv4Settings), the OS automatically adds several host routes via utun to services such as Akamai, Apple Push, etc. These routes appear to correspond to TCP flows that were active at the moment the VPN connection was established. When a particular TCP flow ends, the corresponding host route is deleted. We understand this is likely intended to avoid breaking existing TCP connections. However, we find the behavior of migrating existing TCP flows to the new utun interface simply because any IPv4 route is added somewhat questionable. This approach would make sense in a "full-tunnel" scenario — for example, when all IPv4 traffic (e.g., 0.0.0.0/0) is routed through the tunnel — but not necessarily in a "split-tunnel" configuration where only specific IPv4 routes are added. Is there any way to control or influence this behavior? Would it be possible for FlowDivert to differentiate between full-tunnel and split-tunnel cases, and only preserve existing TCP flows via utun in the full-tunnel scenario? Thank you.

Hi Team, I have a Network Extension application and UI frontend for it. The UI frontend talks to the Network Extension using XPC, as provided by NEMachServiceName. On M2 machine, The application and XPC connection works fine on clean installation. But, when the application is upgraded, the XPC connection keeps failing. Upgrade steps: PreInstall script kills the running processes, both UI and Network Extension Let installation continue PostInstall script to launch the application after installation complete. Following code is successful to the point of resume from UI application NSXPCInterface *exportedInterface = [NSXPCInterface interfaceWithProtocol:@protocol(IPCUIObject)]; newConnection.exportedInterface = exportedInterface; newConnection.exportedObject = delegate; NSXPCInterface *remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(IPCExtObject)]; newConnection.remoteObjectInterface = remoteObjectInterface; self.currentConnection = newConnection; [newConnection resume]; But it fails to get the object id<IPCExtObject> providerProxy = [self.currentConnection remoteObjectProxyWithErrorHandler:^(NSError *registerError) { }]; Please note, this only fails for M2. For M1, this exact code is running fine. Additionally, if I uninstall the application by dropping it in Trash and then installing the newer version, then too, the application works fine.

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

IMPORTANT The resume rate limiter is now covered by the official documentation. See Use background sessions efficiently within Downloading files in the background. So, the following is here purely for historical perspective. NSURLSession’s background session support on iOS includes a resume rate limiter. This limiter exists to prevent apps from abusing the background session support in order to run continuously in the background. It works as follows: nsurlsessiond (the daemon that does all the background session work) maintains a delay value for your app. It doubles that delay every time it resumes (or relaunches) your app. It resets that delay to 0 when the user brings your app to the front. It also resets the delay to 0 if the delay period elapses without it having resumed your app. When your app creates a new task while it is in the background, the task does not start until that delay has expired. To understand the impact of this, consider what happens when you download 10 resources. If you pass them to the background session all at once, you see something like this: Your app creates tasks 1 through 10 in the background session. nsurlsessiond starts working on the first few tasks. As tasks complete, nsurlsessiond starts working on subsequent ones. Eventually all the tasks complete and nsurlsessiond resumes your app. Now consider what happens if you only schedule one task at a time: Your app creates task 1. nsurlsessiond starts working on it. When it completes, nsurlsessiond resumes your app. Your app creates task 2. nsurlsessiond delays the start of task 2 a little bit. nsurlsessiond starts working on task 2. When it completes, nsurlsessiond resumes your app. Your app creates task 3. nsurlsessiond delays the start of task 3 by double the previous amount. nsurlsessiond starts working on task 3. When it completes, nsurlsessiond resumes your app. Steps 8 through 11 repeat, and each time the delay doubles. Eventually the delay gets so large that it looks like your app has stopped making progress. If you have a lot of tasks to run then you can mitigate this problem by starting tasks in batches. That is, rather than start just one task in step 1, you would start 100. This only helps up to a point. If you have thousands of tasks to run, you will eventually start seeing serious delays. In that case it’s much better to change your design to use fewer, larger transfers. Note All of the above applies to iOS 8 and later. Things worked differently in iOS 7. There’s a post on DevForums that explains the older approach. Finally, keep in mind that there may be other reasons for your task not starting. Specifically, if the task is flagged as discretionary (because you set the discretionary flag when creating the task’s session or because the task was started while your app was in the background), the task may be delayed for other reasons (low power, lack of Wi-Fi, and so on). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" (r. 22323366)

Based on threads from past years, it is mentioned that a NEFilterDataProvider supports IPPROTO_TCP, IPPROTO_UDP, IPPROTO_ICMP and IPPROTO_IGMP. [Q] What about IPPROTO_RAW? Is this something that would have been added recently?