I'm implementing a NETransparentProxyProvider and trying to preserve the original TCP connection semantics as transparently as possible. The current API of NEAppProxyTCPFlow appears not to provide a way to distinguish between the following situations: The client has performed a half-close by calling shutdown(SHUT_WR) (i.e. closed only its write side). The client has fully closed the socket/connection. When readData(completionHandler:) returns empty data, indicating EOF, I cannot determine which of the two cases above has occurred. This creates a problem when forwarding the connection to the upstream server. Upon receiving empty data from the flow, should the corresponding server-side connection: Perform a half-close (close only the write side / send FIN)? Be fully closed? Currently, I always perform a half-close on the server-side connection. While this almost preserves the original flow semantics, it can lead to leaked connections, since the upstream connection may remain in FIN_WAIT_2 indefinitely. Is there any supported way to determine whether the originating connection was half-closed or fully closed? If not, what is the recommended approach for implementing a transparent TCP proxy that needs to accurately preserve TCP shutdown semantics? Any guidance would be appreciated.

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

I'd imagine that RCS messaging is part of the package of excluded services when excludeCellularServices is set to true. Is that accurate? Documentation

A performance bottleneck we often hit is that we seem to be constrained by issuing a single sys call per packet. On platforms where vectored IO is supported, we can unlock 5x performance gains. Whilst we can read arrays of packets via the network extension API, the memory and concurrency model of that API seems to not be well documented, and I am not aware of any way to do vectored I/O on a UDP socket. Will we see an FFI friendly API for vectorised networking anytime soon? As an addendum - we are aware of sendmsg_x and recvmsg_x but we dare not ship an iOS app using those functions directly.

Hey everyone, I’m developing an app for visionOS where I need to display the Apple Vision Pro’s current IP address. For this I’m using the following code, which works for iOS, macOS, and visionOS in the simulator. Only on a real Apple Vision Pro it’s unable to extract an IP. Could it be that visionOS currently doesn’t allow this? Have any of you had the same experience and found a workaround? var address: String = "no ip" var ifaddr: UnsafeMutablePointer<ifaddrs>? = nil if getifaddrs(&ifaddr) == 0 { var ptr = ifaddr while ptr != nil { defer { ptr = ptr?.pointee.ifa_next } let interface = ptr?.pointee let addrFamily = interface?.ifa_addr.pointee.sa_family if addrFamily == UInt8(AF_INET) { if let name: Optional<String> = String(cString: (interface?.ifa_name)!), name == "en0" { var hostname = [CChar](repeating: 0, count: Int(NI_MAXHOST)) getnameinfo(interface?.ifa_addr, socklen_t((interface?.ifa_addr.pointee.sa_len)!), &hostname, socklen_t(hostname.count), nil, socklen_t(0), NI_NUMERICHOST) address = String(cString: hostname) } } } freeifaddrs(ifaddr) } return address } Thanks in advance for any insights or tips! Best Regards, David

We use as content filter in our app to monitor flows, we gather data about the flow and block flows deemed suspicious. Our content filter is activated/deactivated by a UI app but the flows are reported via XPC to a separate daemon process for analysis. As of macOS 15, we are seeing cases where flows are missing or flows are not received at all by the content filter. The behaviour is not consistent, some devices seem to receive flows normally but others don't. It appears Intel devices are much less prone to showing the problem, whereas Arm devices routinely exhibit missing flows. On macOS 14 or earlier, there is no sign of missing flows. Testing on earlier beta versions of macOS 15 did not appear to show the problem, however I can't rule out if issue was present but it wasn't spotted. Experimenting with simple examples of using a content filter (e.g. QNE2FilterMac) does not appear to reproduce the issue. Questions, What has changed between macOS 14 and 15 that could be the cause of the lack of flows? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported?

Is the system default for this still false as of the OS 27 releases? When would you recommend setting it to true?

Hello, it seems Multipeer Connectivity is deprecated. We are looking to connect multiple Vision Pros together that are in the same physical space but in unknown network setups (That might block P2P communication and Multicasting). We are building an app with unity and already have networking solution that we are looking to extend to work with something like multipeer connectivty? Am I reading the docs right that "Apple peer-to-wifi" is the replacement. And that by using the "includePeerToPeer" property this will work. Would it be possible in this way that the Vision Pros discover and communicate with each other even if not connected to an AP?

I am trying to setup a system-wide DNS-over-TLS for iOS that can be turned off and on from within the app, and I'm struggling with the implementation details. I've searched online, searched forums here, used ChatGPT, and I'm getting conflicting information or code that is simply wrong. I can't find example code that is valid and gets me moving forward. I think I need to use NEDNSProxyProvider via the NetworkExtension. Does that sound correct? I have NetworkExtension -> DNS Proxy Capability set in both the main app and the DNSProxy extension. Also, I want to make sure this is even possible without an MDM. I see conflicting information, some saying this is opened up, but things like https://developer.apple.com/documentation/Technotes/tn3134-network-extension-provider-deployment saying a device needs to be managed. How do private DNS apps do this without MDM? From some responses in the forums it sounds like we need to parse the DNS requests that come in to the handleNewFlow function. Is there good sample code for this parsing? I saw some helpful information from Eskimo (for instance https://developer.apple.com/forums/thread/723831 ) and Matt Eaton ( https://developer.apple.com/forums/thread/665480 )but I'm still confused. So, if I have a DoT URL, is there good sample code somewhere for what startProxy, stopProxy, and handleNewFlow might look like? And valid code to call it from the main app?

We are currently investigating a serious issue related to Wi-Fi Aware and AccessorySetupKit. We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. After this happens, calling the following API fails: ASAccessorySession.showPicker(for:completionHandler:) API documentation: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession/showpicker(for:completionhandler:) The error returned is: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable.” Related logs: error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." 21:27:33.116061+0800 deviceaccessd Activating DASession: CID 0x7FC70001, BundleID xxxx, PID 542, WiFiAwareSupported: no 2026-05-26 21:27:33.118<103>21:27:33.118[E][WiFiAware::WA]@"":[ASK] showPicker callback error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." UserInfo={ NSDebugDescription=Current device is not Wi-Fi Aware capable., cuErrorMsg=Current device is not Wi-Fi Aware capable., NSLocalizedFailureReason=Current device is not Wi-Fi Aware capable. } Device information: Device: iPhone 16 Pro OS Version: 26.5 The device was previously able to use Wi-Fi Aware successfully. However, after the issue occurs, the system reports: WiFiAwareSupported: no The only known way to recover so far is to erase all content and settings / factory reset the device. This is not an acceptable workaround for end users and may cause a severe user experience issue. We would like to ask for your help with the following questions: Under what conditions would an iPhone that supports Wi-Fi Aware suddenly be reported as not Wi-Fi Aware capable? Is WiFiAwareSupported: no determined by hardware capability, system configuration, region setting, privacy/security policy, entitlement state, or some cached system state? Is there any known issue in AccessorySetupKit or Wi-Fi Aware on iOS 26.5 that could cause this behavior? Is there a way to recover the Wi-Fi Aware capability without requiring a factory reset? Are there any additional logs, sysdiagnose profiles, or diagnostic commands you recommend us to collect when this issue occurs? This issue is critical for us because users who encounter it will no longer be able to proceed with accessory setup, even though their device should support Wi-Fi Aware. Please let us know if you need a sysdiagnose, sample project, full device logs, or additional reproduction information. We would appreciate any guidance on the root cause and possible workaround.

Why is the WiFiAware framework not importable in Mac Catalyst? Are there any plans to support Wi-Fi Aware technology on Mac Catalyst in the future?

iPhone 12 pro with iOS 26.0 (23A5276f) App: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps We aim to use Wi-Fi Aware to establish file transfer between Android and Apple devices. Apple will act as the Publisher, and Android will act as the Subscriber. According to the pairing process outlined in the Wi-Fi Aware protocol (Figure 49 in the Wi-Fi Aware 4.0 specification), the three PASN Authentication frames have been successfully exchanged. Subsequently, Android sends the encrypted Follow-up PMF to Apple, but the Apple log shows: Failed to parse event. Please refer to the attached complete log. We request Apple to provide a solution. apple Log-20250808a.txt

Hello, We are facing an issue with performing a DTLS handshake when our iOS application is in the background. Our app (Vocera Collaboration Suite – VCS) uses secure DTLS-encrypted communication for incoming VoIP calls. Problem Summary: When the app is in the background and a VoIP PushKit notification arrives, we attempt to establish a DTLS handshake over our existing socket. However, the handshake consistently fails unless the app is already in the foreground. Once the app is foregrounded, the same DTLS handshake logic succeeds immediately. Key Questions: Is performing a DTLS handshake while the app is in the background technically supported by iOS? Or is this an OS-level limitation by design? If not supported, what is the Apple-recommended alternative to establish secure DTLS communication for VoIP flows without bringing the app to the foreground? Any guidance or clarification from Apple engineers or anyone who has solved a similar problem would be greatly appreciated. Thank you.

We are investigating bridged Wi-Fi DHCP behavior on recent macOS releases and would appreciate some clarification regarding the net.link.bridge.use_dhcp_xid sysctl. We observed that with the default setting, DHCP packets transmitted from a virtual machine through a bridged Wi-Fi interface may have their DHCP client identity modified (chaddr). In our testing, setting: net.link.bridge.use_dhcp_xid=0 prevents this behavior and restores the DHCP packet format observed on older macOS versions. We would like to better understand the intended purpose of this sysctl: What functionality does net.link.bridge.use_dhcp_xid control internally? Besides DHCP chaddr rewriting, what other bridge or DHCP processing behavior is affected by this setting? Is this sysctl related to DHCP snooping, anti-spoofing protection, Wi-Fi bridging compatibility, or another mechanism? Is the current default behavior (use_dhcp_xid=1) a recent change introduced in macOS 26.4.x? Is the modified DHCP behavior considered expected and supported, or is it intended as an implementation detail? For additional context, we previously submitted feedback regarding DHCP handling for virtual machines using Virtualization Framework. Since packet modification is restricted from user space, we are wondering whether this sysctl is related to DHCP processing implemented by the bridge subsystem to address DHCP spoofing, client identification, or Wi-Fi bridging limitations. One concern we have is that net.link.bridge.use_dhcp_xid appears to be a system-wide setting. In our use case, DHCP handling requirements may differ between virtual machines, networks, and environments. As a result, changing a global bridge behavior for the entire host system is not always desirable. If this sysctl is intended to control DHCP processing for bridged virtual machines, would it be possible to expose similar functionality on a per-interface, per-bridge, or per-VM basis rather than as a host-wide setting? This would allow virtualization products to adapt DHCP behavior to specific network environments without affecting all bridged networking on the host. One additional question: Apple suggested making this setting persistent via /etc/sysctl.conf. However, this file does not exist by default on our macOS 26.4.x systems. Is /etc/sysctl.conf still a supported mechanism for persistent sysctl configuration, or is there a preferred modern alternative? Any documentation or implementation details that can be shared would be greatly appreciated.

Hi We are building a VPN app (PacketTunnelProvider) and allowing users to install the app through test flight and app upgrade works seamlessly without VPN, but immediately after enabling the VPN, we are not able to get app upgraded with the progress bar in test flight stuck at 90 percent and now app is not usable after that but VPN is still working. We are not noticing the issue on ios 12.4.1 version but facing the issue on iOS 13 versions. On looking through console app during upgradation process we are noticing a below recurring log message. Error acquiring hold on plugins for &lt;bundle_identifier&gt;: Error Domain=PlugInKit Code=14 "plugins are busy" UserInfo={busyPlugInUUIDs=({         XPCExtensionBundleIdentifier = "&lt;bundle_identifier&gt;.tunnel";     } ), NSLocalizedDescription=plugins are busy} Could someone please help us in resolving the issue.

Hi, Since iOS 26 (and any other apple system with a 26 version) there is a very weird behavior in the whole apple ecosystem (iOS, iPadOS, macOS and visionOS). I'm self-hosting a web project called mempool (https://github.com/Retropex/mempool). This project is entirely self-hosted on my own infrastructure, so I have advanced control to be sure it's just not an anti-DDoS feature that makes the bug happen. So the bug is once I visit my website, for example this page (https://mempool.guide/tx/d86192252a6631831e55f814aea901e65407b6dbda77e1abdea8ec27861e9682) the OS will lose the ability to connect to the underlying IP of the domain (mempool.guide) but the issue seems to affect only the HTTPS/HTTP port (443/80). The issue is system wide, not only is Safari. For exemple I have another domain that resolve to the same IP (haf.ovh) and if this link above trigger the bug then I will also lose the ability to connect to https://haf.ovh A temporary fix that I have is that if I turn off wifi/cellular then I turn it on again I can connect again to my server again until the bug is triggered again. I have done test with tcpdump on my server and the connection isn't making it to my server that's why I think it's an OS issue, especially given the fix above. This issue can be reproduced on any apple device out of the box with a system with >v26. All device (Mac, iPad, iPhone, vision) with version pre-26 are completely unaffected by the bug and can freely explore the website without loosing the connection macOS is less affected by this bug, it can be random with it. With iOS/iPadOS it's systematic. Another thing to note is that the same URL on firefox/chrome for iOS doesn't trigger the bug. Let me know if anyone has an idea on what's going on. Thanks, Léo.

Hi, I've encountered a strange behavior in the DNS Proxy Provider extension. Our app implements both DNS Proxy Provider and Content Filter Providers extensions, configured via MDM. When the app is uninstalled, the behavior of the providers differs: For Content Filter Providers (both Filter Control and Filter Data Providers), the providers stop as expected with the stop reason: /** @const NEProviderStopReasonProviderDisabled The provider was disabled. */ case providerDisabled = 5 However, for the DNS Proxy Provider, the provider remains in the "Running" state, even though there is no app available to match the provider's bundle ID in the uploaded configuration profile. When the app is reinstalled: The Content Filter Providers start as expected. The DNS Proxy Provider stops with the stop reason: /** @const NEProviderStopReasonAppUpdate The NEProvider is being updated */ @available(iOS 13.0, *) case appUpdate = 16 At this point, the DNS Proxy Provider remains in an 'Invalid' state. Reinstalling the app a second time seems to resolve the issue, with both the DNS Proxy Provider and Content Filter Providers starting as expected. This issue seems to occur only if some time has passed after the DNS Proxy Provider entered the 'Running' state. It appears as though the system retains a stale configuration for the DNS Proxy Provider, even after the app has been removed. Steps to reproduce: Install the app and configure both DNS Proxy Provider and Content Filter Providers using MDM. Uninstall the app. Content Filter Providers are stopped as expected (NEProviderStopReason.providerDisabled = 5). DNS Proxy Provider remains in the 'Running' state. Reinstall the app. Content Filter Providers start as expected. DNS Proxy Provider stops with NEProviderStopReason.appUpdate (16) and remains 'Invalid'. Reinstall the app again. DNS Proxy Provider now starts as expected. This behavior raises concerns about how the system manages the lifecycle of DNS Proxy Provider, because DNS Proxy Provider is matched with provider bundle id in .mobileconfig file. Has anyone else experienced this issue? Any suggestions on how to address or debug this behavior would be highly appreciated. Thank you!

We use TeamCity as our Continuous Integration (CI) solution to build and run automated tests. These are integration tests executed through our 4D application, which is properly code‑signed and notarized. These CI machines are heavily used and build multiple versions per day, making them critical to our development workflow. However, we are experiencing an issue on some machines: after a certain period of time, network communication through our application stops working, while network communication remains fully functional when using third‑party tools (for example, LDAP clients). Based on our investigation, this issue appears to be related to Local Network Privacy management. We have followed the procedure described in Apple’s Technical Note: TN3179: Understanding local network privacy | Apple Developer Documentation to reset network authorizations, but this has not been sufficient to resolve the issue. In addition, our CI environment requires acknowledging a large number of Local Network access permission prompts. Given that these machines build multiple versions per day and are intended to run unattended, this is not practical in an automated CI context. We have around ten Macs dedicated to running these tests, and manually approving these pop‑ups is not a viable solution.

I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?

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