Hi, I’m using Network Framework to implement a UDP client via NWConnection, and I’m looking for clarification about the correct and fully safe shutdown procedure, especially regarding resource release. I have initiated some pending receive calls on the NWConnection (using receive). After calling connection.cancel(), do we need to wait for the cancellation of these pending receives? As mentioned in this thread, NWConnection retains references to the receive closures and releases them once they are called. If a receive closure holds a reference to the NWConnection itself, do we need to wait for these closures to be called to avoid memory leaks? Or, if there are no such retained references, we don't need to wait for the cancellation of the pending I/O and cancelled state for NWConnection?

Hello, We are developing a content filter solution which includes both a content filter and a packet filter (NEFilterControlProvider and NEFilterPacketProvider). We've observed that if the packet filter is enabled (both by itself or in conjunction with the content filter) we are having issues with bridged thunderbolt connections - traffic on that interface stops in both directions. We've tested on bridges to other MacOS devices or Windows devices, but both exhibit the same behavior. Even if the packet provider is reduces to "allow all" in the callback the issue remains. Our handler is not called at all anyway so we can't allow or deny packets. We've tested this on Macos 15 and 26 but it behaves the same. If we only enable the NEFilterControlProvider everything works fine. All other types of network interfaces work fine as well. Is this a known issue? Is there an workaround? Thanks.

I’m using an NETransparentProxyProvider where I add UDP-53 rules to intercept DNS queries from a private application. These queries are resolved locally on the endpoint by returning a custom DNS response. Example Rules look like this: NENetworkRule(destinationHost: NWHostEndpoint(hostname: "mypaapp.com", port: 53),protocol:.UDP) This works as expected through browser and ping. handleNewUDPFlow/handleNewFlow with NEAppProxyUDPFlow gets called where custom dns response get written. Using nslookup mypaapp.com doesn't works. Why does this behaves differently for nslookup?

Hi, We are trying to use Apple Security API for KeyChain Services. Using the common App Group : Specifying the common app group in the "kSecAttrAccessGroup" field of the KeyChain query, allowed us to have a shared keychains for different apps (targets) in the app group, but this did not work for extensions. Enabling the KeyChain Sharing capability : We enabled the KeyChain Sharing Ability in the extensions and the app target as well, giving a common KeyChain Access group. Specifying this in the kSecAttrAccessGroup field also did not work. This was done in XCode as we were unable to locate it in the Developer portal in Indentifiers. We tried specifying "$AppIdentifier.KeyChainSharingGroup" in the kSecAttrAccessGroup field , but this did not work as well The error code which we get in all these 3 cases when trying to access the Keychain from the extension is error code 25291 (errSecNotAvailable). The Documentation says this error comes when "No Trust Results are available" and printing the error in xcode using the status says "No keychain is available. The online Documentation says that it is possible to share keychain with extensions, but by far we are unable to do it with the methods suggested. Do we need any special entitlement for this or is there something we are missing while using these APIs? We really appreciate any and all help in solving this issue! Thank you

System Information in macOS from 26.0 to 26.2 RC no longer provides Wi-Fi SSIDs; instead, it displays "< redacted> " for every SSID on my two MacBooks. This issue has been fixed in macOS 26.1 beta and macOS 26.2 beta, but it returns in the RC and the Final Release versions. Is it an expected behaviour or a bug in the Release Candidate? MacBook Air 2025: MacBook Pro 2021:

Hi team, I’m having an issue with my iOS app related to local network communication and connecting to a Wi-Fi speaker. My app works similar to the “4Stream” application. The speaker and the mobile device must be on the same Wi-Fi network so the app can discover and connect to the speaker. What’s happening: When I run the app directly from Xcode in debug mode, everything works perfectly. The speaker gets discovered. The speaker gets connected successfully. The connection flow completes without any problem. But when I upload the same build to TestFlight, the behaviour changes completely. The app gets stuck on the “Connecting…” screen. The speaker is not discovered. But the same code is working fine on Android It never moves forward from that state. So basically: Debug Mode: Speaker is detected and connected properly TestFlight: Stuck at “Connecting…”, speaker does NOT get connected This makes me believe something related to local network access, multicast, Wi-Fi info permissions, or Bonjour discovery is not being applied correctly in the release/TestFlight environment. Below is my current Info.plist and Entitlements file, which already include Local Network Usage, Bonjour services, Location usage for SSID, multicast entitlements, wifi-info, etc. My Info.plist <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>Wanwun</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>$(MARKETING_VERSION)</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>$(CURRENT_PROJECT_VERSION)</string> <key>LSRequiresIPhoneOS</key> <true/> <!-- Allow HTTP to devices on LAN --> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <key>NSExceptionDomains</key> <dict> <key>local</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> <key>localhost</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> <!-- Local Network Usage --> <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover and control your sound system device over Wi-Fi.</string> <!-- Bonjour services for discovery --> <key>NSBonjourServices</key> <array> <string>_http._tcp.</string> <string>_wrtn._tcp.</string> <string>_services._dns-sd._udp.</string> </array> <!-- Location for SSID Permission --> <key>NSLocationWhenInUseUsageDescription</key> <string>This app requires location access to read the connected Wi-Fi information.</string> <!-- Camera / Photos --> <key>NSCameraUsageDescription</key> <string>This app needs camera access to capture attendance photos.</string> <key>NSPhotoLibraryAddUsageDescription</key> <string>This app saves captured photos to your gallery.</string> <key>NSPhotoLibraryUsageDescription</key> <string>This app needs access to your gallery to upload existing images.</string> <!-- Bluetooth --> <key>NSBluetoothAlwaysUsageDescription</key> <string>This app uses Bluetooth to discover nearby sound system devices.</string> <key>NSBluetoothPeripheralUsageDescription</key> <string>This app uses Bluetooth to connect with your sound system.</string> <!-- Launch screen --> <key>UILaunchStoryboardName</key> <string>LaunchScreen</string> <!-- Device Capabilities --> <key>UIRequiredDeviceCapabilities</key> <array> <string>arm64</string> </array> <!-- Orientation --> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UIViewControllerBasedStatusBarAppearance</key> <false/> My Entitlements What I need help with: I want to understand why the app behaves correctly in debug mode (where the speaker connects without issues), but the same functionality fails in TestFlight. Is there something additional required for: Local network discovery on TestFlight? Multicast networking? Reading the Wi-Fi SSID? Bonjour, service scanning? Release build / TestFlight network permissions? If any extra entitlement approval, configuration, or specific service type is needed for TestFlight builds, please guide me. Thank you for your help.

Device: iPhone 17 Series System: iOS 26.0.0 Wi-Fi: TKIP encryption protocol Question: Unable to join the network We have several products that are used by connecting to iPhone via Wi-Fi. Recently, many customers who have purchased the iPhone 17 series have reported that they are unable to connect to Wi-Fi. For Wi-Fi with TKIP encryption, after entering the password correctly to connect to the Wi-Fi, a pop-up appears stating "Unable to join the network.". Only Wi-Fi with WPA2-AES can be used normally. Before that, during the iPhone 11 era or even earlier, the TKIP encryption method was in normal use. However, the new iPhone models were incompatible with it, which obviously caused great inconvenience. I hope the engineers can fix this issue to support Wi-Fi with older encryption protocols.

Hello to all I have coded in swift a headless app, that launches 3 go microservices and itself. The app listens via unix domain sockets for commands from the microservices and executes different VPN related operations, using the NEVPNManager extension. Because there are certificates and VPN operations, the headless app and two Go microservices must run as root. The app and microservices run perfectly when I run in Xcode launching the swift app as root. However, I have been trying for some weeks already to modify the application so at startup it requests the password and runs as root or something similar, so all forked apps also run as root. I have not succeeded. I have tried many things, the last one was using SMApp but as the swift app is a headless app and not a CLI command app it can not be embedded. And CLI apps can not get the VPN entitlements. Can anybody please give me some pointers how can I launch the app so it requests the password and runs as root in background or what is the ideal framework here? thank you again.

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.

Hi, I’m using Network Framework to implement a UDP listener via NWListener. I am looking for clarification about the correct and fully safe shutdown procedure, especially regarding resource release. After calling listener.cancel(), do we need to wait for the .cancelled state before exiting the application? Or can we just exit once the cancellation is initiated, assuming the OS will close the NWListener and there will be no resource leak? Is it recommended (or required) to set newConnectionHandler = nil when shutting down a UDP listener? My understanding is that if there is no NWListener attached, then whenever a connection is accepted by the OS, it will not be delivered to the application and the OS will simply drop it.

We are developing an enterprise app that connects to a local server. It uses simple URLSessions. There is a view in the app where you enter the server url (IP address) and a connection check is made. iOS asks for permission to access the local network. Everything works. If the server is reachable, the connection info is saved. Recently we encountered a very strange issue: We also have a beta version of this app. If we first install the normal version on a device, enter the server IP, save, and then install the beta version and do the same there: It does not get a connection (it waits for the timeout). The strange part is: If I try to configure the connection in the normal version again, it also does not work, it just waits for the timeout. The really strange part: When I delete the beta version, while the normal version is waiting for its connection, the connection succeeds immediately. Both versions have a different display name, bundle id. I also tried using a device that is not in our MDM: same problem. Even the iOS version seems to have no impact: I tried on iOS 15, 18 and 26. Is there an explanation and hopefully also a solution to this problem?

Description: We are investigating an issue where running a specific e-commerce iOS app inside the Xcode Simulator intermittently disrupts the Mac’s network connectivity. When the app is launched in the Simulator, our NETransparentProxyProvider and NEFilterDataProvider extensions occasionally stop receiving traffic correctly, and shortly afterward the entire macOS DNS resolution fails. Once this happens, all apps on the Mac lose internet access until mac is restarted. Disabling extensions also fixing the issue. This issue only appears when the app runs in the Xcode Simulator. I would like to confirm: Is it possible for traffic patterns or network behavior inside the Simulator to interfere with system-level Network Extension providers on macOS? Are there known limitations or conflicts between the Simulator’s virtual networking interfaces and Network Extensions? Any recommended debugging steps or best practices to isolate this behavior? Any guidance, known issues, or suggestions would be appreciated.

Hi, We’re seeing our build system (Gradle) get stuck in sendto system calls while trying to communicate with other processes via the local interface over UDP. To the end user it appears that the build is stuck or they will receive an error “Timeout waiting to lock XXX. It is currently in use by another Gradle instance”. But when the process is sampled/profiled, we can see one of the threads is stuck in a sendto system call. The only way to resolve the issue is to kill -s KILL <pid> the stuck Gradle process. A part of the JVM level stack trace: "jar transforms Thread 12" #90 prio=5 os_prio=31 cpu=0.85ms elapsed=1257.67s tid=0x000000012e6cd400 nid=0x10f03 runnable [0x0000000332f0d000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.DatagramChannelImpl.send0(java.base@17.0.10/Native Method) at sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(java.base@17.0.10/DatagramChannelImpl.java:901) at sun.nio.ch.DatagramChannelImpl.send(java.base@17.0.10/DatagramChannelImpl.java:863) at sun.nio.ch.DatagramChannelImpl.send(java.base@17.0.10/DatagramChannelImpl.java:821) at sun.nio.ch.DatagramChannelImpl.blockingSend(java.base@17.0.10/DatagramChannelImpl.java:853) at sun.nio.ch.DatagramSocketAdaptor.send(java.base@17.0.10/DatagramSocketAdaptor.java:218) at java.net.DatagramSocket.send(java.base@17.0.10/DatagramSocket.java:664) at org.gradle.cache.internal.locklistener.FileLockCommunicator.pingOwner(FileLockCommunicator.java:61) at org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler.maybePingOwner(DefaultFileLockContentionHandler.java:203) at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock$1.run(DefaultFileLockManager.java:380) at org.gradle.internal.io.ExponentialBackoff.retryUntil(ExponentialBackoff.java:72) at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.lockStateRegion(DefaultFileLockManager.java:362) at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.lock(DefaultFileLockManager.java:293) at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.<init>(DefaultFileLockManager.java:164) at org.gradle.cache.internal.DefaultFileLockManager.lock(DefaultFileLockManager.java:110) at org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess.incrementLockCount(LockOnDemandCrossProcessCacheAccess.java:106) at org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess.acquireFileLock(LockOnDemandCrossProcessCacheAccess.java:168) at org.gradle.cache.internal.CrossProcessSynchronizingCache.put(CrossProcessSynchronizingCache.java:57) at org.gradle.api.internal.changedetection.state.DefaultFileAccessTimeJournal.setLastAccessTime(DefaultFileAccessTimeJournal.java:85) at org.gradle.internal.file.impl.SingleDepthFileAccessTracker.markAccessed(SingleDepthFileAccessTracker.java:51) at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.markAccessed(DefaultCachedClasspathTransformer.java:209) at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.transformFile(DefaultCachedClasspathTransformer.java:194) at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.lambda$cachedFile$6(DefaultCachedClasspathTransformer.java:186) at org.gradle.internal.classpath.DefaultCachedClasspathTransformer$$Lambda$368/0x0000007001393a78.call(Unknown Source) at org.gradle.internal.UncheckedException.unchecked(UncheckedException.java:74) at org.gradle.internal.classpath.DefaultCachedClasspathTransformer.lambda$transformAll$8(DefaultCachedClasspathTransformer.java:233) at org.gradle.internal.classpath.DefaultCachedClasspathTransformer$$Lambda$372/0x0000007001398470.call(Unknown Source) at java.util.concurrent.FutureTask.run(java.base@17.0.10/FutureTask.java:264) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.10/ThreadPoolExecutor.java:1136) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.10/ThreadPoolExecutor.java:635) at java.lang.Thread.run(java.base@17.0.10/Thread.java:840) A part of the process sample: 2097 Thread_3879661: Java: jar transforms Thread 12 + 2097 thread_start (in libsystem_pthread.dylib) + 8 [0x18c42eb80] ...removed for brevity... + 2097 Java_sun_nio_ch_DatagramChannelImpl_send0 (in libnio.dylib) + 84 [0x102ef371c] + 2097 __sendto (in libsystem_kernel.dylib) + 8 [0x18c3f612c] We have observed the following system logs around the time the issue manifests: 2025-08-26 22:03:23.280255+0100 0x3b2c00 Default 0x0 0 0 kernel: cfil_hash_entry_log:6088 <CFIL: Error: sosend_reinject() failed>: [4628 java] <UDP(17) in so 9e934ceda1c13379 50826943645358435 50826943645358435 ag> 2025-08-26 22:03:23.280267+0100 0x3b2c00 Default 0x0 0 0 kernel: cfil_service_inject_queue:4472 CFIL: sosend() failed 22 The issue seems to be rooted in the built-in Application Firewall, as disabling it “fixes” the issue. It doesn’t seem to matter that the process is on the “allow” list. We’re using Gradle 7.6.4, 8.0.2 and 8.14.1 in various repositories, so the version doesn’t seem to matter, neither does which repo we use. The most reliable way to reproduce is to run two Gradle builds at the same time or very quickly after each other. We would really appreciate a fix for this as it really negatively affects the developer experience. I've raised FB19916240 for this. Many thanks,

Hi, I played around the last days with the new NetworkConnection API from Network framework that supports structured concurrency. I discovered a behavior, which is unexpected from my understanding. Let's say you have a dead endpoint or something that does not exist. Something where you receive a noSuchRecord error. When I then try to send data, I would expect that the send function throws an error but this does not happen. The function now suspends indefinitely which is well not a great behavior. Example simplified: func send() async { let connection = NetworkConnection(to: .hostPort(host: "apple.co.com", port: 8080)) { TCP() } do { try await connection.send("Hello World!".raw) } catch { print(error) } } I'm not sure if this is the intended behavior or how this should be handled. Thanks and best regards, Vinz

I've noticed that if a call to startVPNTunnel() is made while no network interface is active on the system, the call "succeeds" (i.e., doesn't throw), but the VPN connection state goes straight from NEVPNStatus.disconnecting to NEVPNStatus.disconnected. The docs for startVPNTunnel() state: In Swift, this method returns Void and is marked with the throws keyword to indicate that it throws an error in cases of failure. Additionally, there is an NEVPNConnectionError enum that contains a noNetworkAvailable case. However, this isn't thrown in this case, when startVPNTunnel() is called. I just wanted to ask under what circumstances startVPNTunnel() does throw, and should this be one of them? Additionally, to catch such errors, would it be better to call fetchLastDisconnectError() in the .NEVPNStatusDidChange handler?

I am working on a game app that uses multicast to advertise and locate a hosted game. It therefore requires local network permission. Entitlements are set up correctly in the app for using multicast. I have two iPhones I use for testing my app, one was using iOS 18.1.x (not exactly sure about the value of x) and the other was using a later version of 18. I install the app on these devices via TestFlight. On the device using iOS 18.1.x the networking worked perfectly, and I could host or join a game (connecting to the same app running on my mac). The device using the later version would fail to see advertised games as well as failing to advertise games itself. Updating this device to the latest iOS (18.7.2) did not fix the problem. To test that it is likely related to the later version of iOS, I updated the 18.1.x device that was working to 18.7.2, and now it does not work either. I could see the app listed under "Privacy and Security/Local Network" in settings on the device that used to work with 18.1.x, but not the device with the later version of iOS . Now it does not show up on either device. Nor does either device ask for permission when I activate a network game on the app, even after repeatedly deleting and reinstalling the app as well as resetting the devices. Why does the device not ask for permission when I try to set up a network game, and how can I get this working again?

Currently in our app, to identify a network switch in device we are doing NEHotspotHelper.register and then NEHotspotHelperHandler block. When the command type is evaluate and if the network.didJustJoin, we are identifying it as a network switch. As a part of moving our code base to iOS 26, if is found that NEHotspotHelper is deprecated. What is the proper replacement for this?

Hello, I am studying the Building peer-to-peer apps codebase https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps and am wondering why no connection is ever started? I searched the codebase and didn't find .start() be called once. Start function I'm referencing https://developer.apple.com/documentation/network/networkconnection/start() Are NetworkConnections started automatically? Note that I am using QUIC NetworkConnections (NetworkConnection) in what I'm trying to do.

Hi, I'm new to swift programming and right now writing an app for esp8266-controlled lamp device. My lamp is broadcasting it's own IP through bonjour. So all I want is to discover any lamps in my network (http.tcp) and to read name and value. Is there any example of such implementation? All I found so far is old or a lit bit complicated for such simple question. Thanks in advance!

After dropping an A-record TTL to 60 secs (it was previously no higher than 600 secs for several weeks) and making an IP change for a small business website on Monday, I took down the old web service just over 24 hours later on Tuesday evening. We then had reports of some customers not being able to access the website on Wednesday morning. On investigation using my iPhone it would appear that Apple Private Relay is still directing clients to the old IP address. It's just as well I have iCloud+ as I would never have seen this issue otherwise and would have been none the wiser as to why some customers were having problems. Has anyone else seen this and/or have a fix other than waiting longer? Do you know how long it takes for Apple Private Relay to update? This isn't expected behaviour of DNS? I spoke to someone at Apple yesterday and there wasn't much they can do. I hope they're escalating internally as almost 3 days later it's still pointing users to the old IP address despite having ample time for proper DNS propagation.