Apple's Wi-Fi Aware demo shows that pairing is required before establishing a connection. Is this pairing mandatory? Can Android devices pair with Apple devices? My Android device strictly supports Wi-Fi Aware 4.0 and I want to achieve interoperability with Apple devices.

{"bug_type":"210","timestamp":"2025-07-04 14:19:35.00 +0800","os_version":"macOS 15.5 (24F74)","roots_installed":0,"incident_id":"5457889A-1002-4389-BAE6-A447733EFD78"} { "build" : "macOS 15.5 (24F74)", "product" : "MacBookPro18,4", "socId" : "6001", "socRevision" : "11", "incident" : "5457889A-1002-4389-BAE6-A447733EFD78", "crashReporterKey" : "4ABE0CA2-C60B-8B0E-557A-C0BDEB1E9144", "kernel" : "Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:49 PDT 2025; root:xnu-11417.121.62/RELEASE_ARM64_T6000", "date" : "2025-07-04 14:19:35.95 +0800", "panicString" : "panic(cpu 1 caller 0xfffffe00215f28e8): Kernel data abort. at pc 0xfffffe0021310d9c, lr 0x37a67e002116f050 (saved state: 0xfffffe60706d3240)\n\t x0: 0xfffffe2eaac676f8 x1: 0x0000000000000000 x2: 0xfffffe002116f050 x3: 0x0000000000000002\n\t x4: 0x0000000000002021 x5: 0xffffffffffffffff x6: 0x0000000000000000 x7: 0x0000006ddf79e068\n\t x8: 0xf9555cb919b50093 x9: 0x0000000000000000 x10: 0x0000000000000054 x11: 0x0000000000000000\n\t x12: 0xfffffe002477dfc8 x13: 0x0000000000000001 x14: 0x0000000000000052 x15: 0x0000000000000000\n\t x16: 0x0000020061052ad4 x17: 0x0000000000000001 x18: 0x0000000000000000 x19: 0xfffffe2eaa38d000\n\t x20: 0x0000000000000000 x21: 0xfffffe2eaac676f8 x22: 0x0000000000000020 x23: 0xfffffe2eab90f000\n\t x24: 0x000000001e22b50a x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0xfffffe2eab90efb4\n\t x28: 0x0000000000003500 fp: 0xfffffe60706d35b0 lr: 0x37a67e002116f050 sp: 0xfffffe60706d3590\n\t pc: 0xfffffe0021310d9c cpsr: 0x60401208 esr: 0xfffffe6096000006 far: 0x0000000000000068\n\nDebugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 24F74\nKernel version: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:49 PDT 2025; root:xnu-11417.121.62/RELEASE_ARM64_T6000\nFileset Kernelcache UUID: AF6531DB60D1EB2338126CF77682B8DE\nKernel UUID: CBC2F718-53E4-3C8D-BEC7-FB6DDC3318E1\nBoot session UUID: 5457889A-1002-4389-BAE6-A447733EFD78\niBoot version: iBoot-11881.121.1\niBoot Stage 2 version: iBoot-11881.121.1\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x0000000018540000\nKernelCache base: 0xfffffe001f544000\nKernel slide: 0x0000000018548000\nKernel text base: 0xfffffe001f54c000\nKernel text exec slide: 0x0000000019ce0000\nKernel text exec base: 0xfffffe0020ce4000\nmach_absolute_time: 0x6ddf85c206\nEpoch Time: sec usec\n Boot : 0x686680ed 0x000c5ab2\n Sleep : 0x68676ff9 0x0005fdc0\n Wake : 0x68677007 0x000d2cfa\n Calendar: 0x68677252 0x00021537\n\nZone info:\n Zone map: 0xfffffe1016000000 - 0xfffffe3616000000\n . VM : 0xfffffe1016000000 - 0xfffffe15e2000000\n . RO : 0xfffffe15e2000000 - 0xfffffe187c000000\n . GEN0 : 0xfffffe187c000000 - 0xfffffe1e48000000\n . GEN1 : 0xfffffe1e48000000 - 0xfffffe2414000000\n . GEN2 : 0xfffffe2414000000 - 0xfffffe29e0000000\n . GEN3 : 0xfffffe29e0000000 - 0xfffffe2fac000000\n . DATA : 0xfffffe2fac000000 - 0xfffffe3616000000\n Metadata: 0xfffffe5e3a010000 - 0xfffffe5e43810000\n Bitmaps : 0xfffffe5e43810000 - 0xfffffe5e4f500000\n Extra : 0 - 0\n\nTPIDRx_ELy = {1: 0xfffffe28ded6aff0 0: 0x0000000000000001 0ro: 0x000000016fd330e0 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 3 PVH locks held: None\nCORE 4 PVH locks held: None\nCORE 5 PVH locks held: None\nCORE 6 PVH locks held: None\nCORE 7 PVH locks held: None\nCORE 8 PVH locks held: None\nCORE 9 PVH locks held: None\nCORE 0: PC=0xfffffe0020f2d330, LR=0xfffffe0020f2d368, FP=0xfffffe60717cb460\nCORE 1 is the one that panicked. Check the full backtrace for details.\nCORE 2: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe607167bed0\nCORE 3: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe60725d3ed0\nCORE 4: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe6072bafed0\nCORE 5: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe6072197ed0\nCORE 6: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe60727abed0\nCORE 7: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe6071897ed0\nCORE 8: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe607149bed0\nCORE 9: PC=0xfffffe0020d81094, LR=0xfffffe0020d81094, FP=0xfffffe607214bed0\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe1d4729c7a0: 1925 pages, 14 threads: pid 36674: com.TE.TEDataCloak.ne\nPanicked thread: 0xfffffe28ded6aff0, backtrace: 0xfffffe60706d28f0, tid: 743602\n\t\t lr: 0xfffffe0020d432b4 fp: 0xfffffe60706d2980\n\t\t lr: 0xfffffe0020ea52f8 fp: 0xfffffe60706d29f0\n\t\t lr: 0xfffffe0020ea3554 fp: 0xfffffe60706d2ab0\n\t\t lr: 0xfffffe0020cebb98 fp: 0xfffffe60706d2ac0\n\t\t lr: 0xfffffe0020d42b98 fp: 0xfffffe60706d2e90\n\t\t lr: 0xfffffe00215e7388 fp: 0xfffffe60706d2eb0\n\t\t lr: 0xfffffe00215f28e8 fp: 0xfffffe60706d30c0\n\t\t lr: 0xfffffe0020ea5154 fp: 0xfffffe60706d3160\n\t\t lr: 0xfffffe0020ea36c8 fp: 0xfffffe60706d3220\n\t\t lr: 0xfffffe0020cebb98 fp: 0xfffffe60706d3230\n\t\t lr: 0xfffffe002116f050 fp: 0xfffffe60706d35b0\n\t\t lr: 0xfffffe002116f050 fp: 0xfffffe60706d3730\n\t\t lr: 0xfffffe002116de88 fp: 0xfffffe60706d3780\n\t\t lr: 0xfffffe0021180174 fp: 0xfffffe60706d3810\n\t\t lr: 0xfffffe002117ea94 fp: 0xfffffe60706d38d0\n\t\t lr: 0xfffffe002117d69c fp: 0xfffffe60706d3a30\n\t\t lr: 0xfffffe0021281400 fp: 0xfffffe60706d3a80\n\t\t lr: 0xfffffe00213146dc fp: 0xfffffe60706d3c10\n\t\t lr: 0xfffffe0021324ff8 fp: 0xfffffe60706d3d00\n\t\t lr: 0xfffffe0021325580 fp: 0xfffffe60706d3de0\n\t\t lr: 0xfffffe00213edc24 fp: 0xfffffe60706d3e50\n\t\t lr: 0xfffffe0020ea35dc fp: 0xfffffe60706d3f10\n\t\t lr: 0xfffffe0020cebb98 fp: 0xfffffe60706d3f20\n\t\t lr: 0xfffffe0020cebb60 fp: 0x0000000000000000\n\nlast started kext at 3810289154: com.apple.filesystems.smbfs\t6.0 (addr 0xfffffe00200f68e0, size 111737)\nloaded kexts:\ncom.paragon-

Hi, We're receiving data via centralManager.centralManager.scanForPeripherals, with no options or filtering (for now), and in the func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) callback, we get advertisementData for each bluetooth device found. But, I know one of my BLE devices is sending an Eddystone TLM payload, which generally is received into the kCBAdvDataServiceData part of the advertisementData dictionary, but, it doesn't show up. What is happening however (when comparing to other devices that do show that payload), is I've noticed the "isConnectable" part is false, and others have it true. Technically we're not "connecting" as such as we're simply reading passive advertisement data, but does that have any bearing on how CoreBluetooth decides to build up it's AdvertisementData response? Example (with serviceData; and I know this has Eddystone TLM) ["kCBAdvDataLocalName": FSC-BP105N, "kCBAdvDataRxPrimaryPHY": 1, "kCBAdvDataServiceUUIDs": <__NSArrayM 0x300b71f80>( FEAA, FEF5 ) , "kCBAdvDataTimestamp": 773270526.26279, "kCBAdvDataServiceData": { FFF0 = {length = 11, bytes = 0x36021892dc0d3015aeb164}; FEAA = {length = 14, bytes = 0x20000be680000339ffa229bbce8a}; }, "kCBAdvDataRxSecondaryPHY": 0, "kCBAdvDataIsConnectable": 1] Vs This also has Eddystone TLM configured ["kCBAdvDataLocalName": 100FA9FD-7000-1000, "kCBAdvDataIsConnectable": 0, "kCBAdvDataRxPrimaryPHY": 1, "kCBAdvDataRxSecondaryPHY": 0, "kCBAdvDataTimestamp": 773270918.97273] Any insight would be great to understand if the presence of other flags drive the exposure of ServiceData or not...

On "Accessory Interface Specification CarPlay Addendum R10", it says that it is recommended that the accessory uses a MIMO (2x2) hardware configuration, does this imply that WiFi 5 and SISO (1X1) will be phased out in the near future? When will WiFi 6 MIMO (2x2) become mandatory? On "Accessory Interface Specification CarPlay Addendum R10", it says that Spatial Audio is mandatory. However, for aftermarket in-vehicle infotainment (IVI) system due to the number of speakers are less than 6, is it allowed not to support spatial audio for this type of aftermarket IVI system?

On "Accessory Interface Specification CarPlay Addendum R10", it says that it is recommended that the accessory uses a MIMO (2x2) hardware configuration, does this imply that WiFi 5 and SISO (1X1) will be phased out in the near future? When will WiFi 6 MIMO (2x2) become mandatory? On "Accessory Interface Specification CarPlay Addendum R10", it says that Spatial Audio is mandatory. However, for aftermarket in-vehicle infotainment (IVI) system due to the number of speakers are less than 6, is it allowed not to support spatial audio for this type of aftermarket IVI system?

I have a typical content filter implemented using NEFilterDataProvider and I'm observing that sometimes handleNewFlow will not obey the returned verdict. More specifically, drop verdict is sometimes ignored and an error message is logged. The impact on my app is that my content filter may not drop flows when it was supposed to. I narrowed the issue down to being triggered by using my content filter alongside a VPN (Tailscale VPN, haven't tested others). To reproduce the issue: Open reddit.com on Google Chrome Activate the content filter set to drop traffic (in my case configured for reddit) Run a VPN Refresh the reddit browser tab Observe reddit being loaded just fine, despite traffic being dropped Below you may find a sample log that may be related to when the issue is triggered. Near the end of the log below, I found this particular line interesting: "No current verdict available, cannot report flow closed". I wonder if it means that something else raced in front of my extension and gave an allow verdict. My extension only takes 621us to make a decision. com.apple.networkextension debug 17:19:41.714581-0300 Handling new flow: identifier = D89B5B5D-793C-4940-777A-6BB703E80900 sourceAppIdentifier = EQHXZ8M8AV.com.google.Chrome.helper sourceAppVersion = 138.0.7204.50 sourceAppUniqueIdentifier = {length = 20, bytes = 0x57df24110a3dd3fbd954082915f8f19f6d365053} procPID = 15492 eprocPID = 15492 rprocPID = 15481 direction = outbound inBytes = 0 outBytes = 0 signature = {length = 32, bytes = 0x2e387b1f a214703d 62f17624 4aec86f4 ... 91d91bbd d97b6c90 } socketID = 9e803b76b7a77 localEndpoint = 0.0.0.0:0 remoteEndpoint = 52.6.64.124:443 remoteHostname = gql-realtime.reddit.com protocol = 6 family = 2 type = 1 procUUID = 4C4C44ED-5555-3144-A13B-2281E1056F00 eprocUUID = 4C4C44ED-5555-3144-A13B-2281E1056F00 rprocUUID = 4C4C4485-5555-3144-A122-165F9195A675 myContentFilter.ContentFilterNetworkExtension debug 17:19:41.714638-0300 Flow D89B5B5D-793C-4940-777A-6BB703E80900: handling new flow myContentFilter.ContentFilterNetworkExtension debug 17:19:41.715446-0300 Flow D89B5B5D-793C-4940-777A-6BB703E80900: drop (1 gql-realtime.reddit.com) ( 621.0803985595703 µs) com.apple.networkextension debug 17:19:41.715606-0300 New flow verdict for D89B5B5D-793C-4940-777A-6BB703E80900: drop = YES remediate = NO needRules = NO shouldReport = NO pause = NO urlAppendString = NO filterInbound = NO peekInboundBytes = 0 filterOutbound = NO peekOutboundBytes = 0 statisticsReportFrequency = none com.apple.networkextension debug 17:19:41.715775-0300 Dropping new flow 9e803b76b7a77 com.apple.networkextension error 17:19:41.715883-0300 No current verdict available, cannot report flow closed com.apple.networkextension debug 17:19:41.715976-0300 Outbound disconnect message rejected, no flow found for sockid 2788377450216055 com.apple.networkextension debug 17:19:41.716727-0300 Inbound disconnect message rejected, no flow found for sockid 2788377450216055 Also good to note that this can only be reliably reproduced if there was a browser tab recently opened and kept open in that website. Here I'm also guessing that the browser is caching connections. I was able to reproduce on macOS 15.6 Beta (24G5065c), Google Chrome 138 (apparently doesn't happen on Firefox), and the user has seen the issue on macOS 15.5. My alternative theory is that this log doesn't have anything to do with the behavior and instead it's just Chrome caching the connection, and further traffic in that connection simply flows through because it was previously allowed. Could that be the case? Thanks!

I was excited about the new APIs added to Network.framework in iOS 26 that offer structure concurrency support out of the box and a more modern API design in general. However I have been unable to use them to create a device-to-device QUIC connection. The blocker I ran into is that NetworkListener's run method requires the network protocol to conform to OneToOneProtocol, whereas QUIC conforms to MultiplexProtocol. And there doesn't seem to be any way to accept an incoming MultiplexProtocol connection? Nor does it seem possible to turn a UDP connection into a QUIC connection using NetworkConnection.prependProtocols() as that also only works for network protocols conforming to OneToOneProtocol. I suspect this is an accidental omission in the API design (?), and already filed a Feedback (FB18620438). But maybe I am missing something and there is a workaround or a different way to listen for incoming QUIC connections using the new NetworkListener? QUIC.TLS has methods peerAuthenticationRequired(Bool) and peerAuthenticationOptional(Bool), which makes me think that peer to peer QUIC connections are intended to be supported? I would also love to see documentation for those methods. For example I wonder what exact effect peerAuthenticationRequired(false) and peerAuthenticationOptional(false) would have and how they differ.

The app is an official Apple app: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps. I have two phones, an iPhone 12 and an iPhone 13, both with Bluetooth turned on and connected to the same WiFi. The devices paired successfully the first time, but after I reset the Wi-Fi identifier in Settings - Privacy & Security - Paired Devices, the devices could no longer pair. Specifically, one device displays a PIN input pop-up, but the other device does not show the PIN. What could be the reason for this?

Hello, I am planning to build content filter application for iOS platform and based on the documentation I have read, it's not clear if I can just inspect/monitor network traffic and not filter or block URLs in the NEFilterDataProvider. Is this a valid use case ? With this approach, will the App get rejected during the App review.?

At WWDC 25, Dr. Swetank mentioned, “DeviceDiscoveryUI is for making connections between apps and from an app to another device. It supports pairing with both Apple and third-party devices.” I find the pairing process in DeviceDiscoveryUI via Wi-Fi Aware intriguing. I have two questions: Can we pair devices via Bluetooth first and then establish a Wi-Fi Aware connection? If I use DeviceDiscoveryUI, how should I write an Android program to correspond with it and achieve iPhone-Android pairing? The app is an official Apple app: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps.

Do we have clear document around multiple content filter applications running on single device.? While the documentation says 8 content filters and Only one filter available for system-wide use, there is no clear mention about below scenarios - Which content filter will get precedence? System-wide or App managed? Can there be mulitple Content filters configured for same managed application? Will all control provider running on the device get notified about network traffic ? I searched the forums to get a clear answer but seems older threads where nothing was conclusive. Thanks in advance for the help !!

I was having a look through the documentation for NEPacketTunnelProvider, and wanted to know if it's possible for startTunnel(..) and stopTunnel(..) to run simultaneously, and thus require synchronization between resources they deal with? For example, if the VPN is toggled rapidly from system settings, could the setup that occurs in my startTunnel() definition (class instantiation and setTunnelNetworkSettings(value)) potentially occur after the tear-down logic (resource cleanup, setTunnelNetworkSettings(nil)), leaving the system in a state where the VPN is deactivated, but the configuration is in place?

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings &gt; Privacy &amp; Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file

Problem : Connection error occurs in iOS26 beta while connecting to the device's softap via commercial app (Socket exception errSSLfeerBadCert CFSreamErrorDomainSSL code -9825). iOS 18 release version does not occur. Why does it cause problems? Does the iOS 26 version not cause problems? Is there a way to set it up in the app so that the iOS 26 beta doesn't cause problems? error : "alias":"SOCKET_LOG", "additional":{"currentNetworkStatus":"socket e=errSSLPeerBadCert ns WifiStatus: Connected Error Domain kCFStreamErrorDomainSSL Code-9825 "(null)" UserInfo={NSLocalizedRecoverySuggestion=Error code definition can be found in Apple's SecureTransport.h} Description : It's an issue that happens when you connect our already mass-produced apps to our home appliances (using SoftAP), and it's currently only happening in iOS 26 beta. This particular issue didn't appear until iOS 18 version. Let me know to make sure that this issue will persist with the official release of iOS 26? If the issue continues to occur with the official version, would you share any suggestions on how to mitigate or avoid it. Also, it would be helpful to find out if there are known solutions or processes such as exemptions to fix this issue.

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file Removing the following plist in Recovery Mode seems to resolve the issue rm "/Volumes/Macintosh HD/Library/Preferences/com.apple.networkextension.plist" Is this safe to do?

Question: What is the standard, most reliable way to manage temporary files associated with a URLSessionDownloadTask that has been terminated abnormally due to a network error or other issues? Details Hello, I'm currently developing a feature to download multiple files concurrently on iOS using URLSessionDownloadTask, and I have a question regarding the lifecycle of the temporary files created during this process. As I understand it, URLSessionDownloadTask stores incoming data in a temporary file within the tmp directory, typically with a name like CFNetworkDownload_*.tmp. In my testing, temporary files are managed correctly in the normal scenario. For instance, when I call the cancel() method on an active downloadTask and then release all references to it, the corresponding temporary file is automatically cleaned up from the tmp directory shortly after. However, the problem occurs when a download is interrupted abnormally due to external factors, such as a lost network connection. In this situation, the urlSession(_:task:didCompleteWithError:) delegate method is called, but the associated temporary file is not deleted and remains in the tmp directory. I've observed a particularly interesting behavior related to this. Immediately after the error occurs, if I check my app's storage usage in the iOS Settings app, the data size appears to have decreased momentarily. However, the tmp file has not actually been deleted, and after a short while, the storage usage is recalculated to include the size of this orphaned temporary file. Since my app does not support resuming interrupted downloads, these leftover files become orphaned and unnecessarily consume storage. Therefore, I want to ensure they are all reliably deleted. With this context, I'd like to ask the community: What is the standard, most reliable way to manage temporary files associated with a URLSessionDownloadTask that has been terminated abnormally due to a network error or other issues? I am wondering if there is an official guide or a framework-level API to handle these orphaned files. I would appreciate any advice from those with experience in this area. Thank you.

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file Removing the following plist in Recovery Mode seems to resolve the issue rm "/Volumes/Macintosh HD/Library/Preferences/com.apple.networkextension.plist" Is this safe to do?

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file

This happens when trying to connect to my development web server. The app works fine when connecting to my production server. The production server has a certificate purchased from a CA. My development web server has a locally generated certificate (from mkcert). I have dragged and dropped the rootCA.pem onto the Simulator, although it doesn't indicate it has been loaded the certificate does appear in the Settings app and is checked to be trusted. I have enabled "App Sandbox" and "Outgoing connections (Client)". I have tested the URL from my local browser which is working fine. What am I missing?

Hi, Our project is a MacOS SwiftUI GUI application that bundles a (Sandboxed) System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider (NEPacketTunnelProvider), as our project requires the creation of a TUN device. In order for our System VPN to function, it must reach out to a (self-hosted) server (i.e. to discover a list of peers). Being self-hosted, this server is typically not accessible via the public web, and may only be accessible from within a VPN (such as those also implemented using NEPacketTunnelProvider, e.g. Tailscale, Cloudflare WARP). What we've discovered is that the networking code of the System Network Extension process does not attempt to use the other VPN network interfaces (utunX) on the system. In practice, this means requests to IPs and hostnames that should be routed to those interfaces time out. Identical requests made outside of the Network System Extension process use those interfaces and succeed. The simplest example is where we create a URLSession.downloadTask for a resource on the server. A more complicated example is where we execute a Go .dylib that continues to communicate with that server. Both types of requests time out. Two noteworthy logs appear when packets fail to send, both from the kernel 'process': cfil_hash_entry_log:6088 <CFIL: Error: sosend_reinject() failed>: [30685 com.coder.Coder-Desktop.VPN] <UDP(17) out so b795d11aca7c26bf 57728068503033955 57728068503033955 age 0> lport 3001 fport 3001 laddr 100.108.7.40 faddr 100.112.177.88 hash 58B15863 cfil_service_inject_queue:4472 CFIL: sosend() failed 49 I also wrote some test code that probes using a UDP NWConnection and NWPath availableInterfaces. When run from the GUI App, multiple interfaces are returned, including the one that routes the address, utun5. When ran from within the sysex, only en0 is returned. I understand routing a VPN through another is unconventional, but we unfortunately do need this functionality one way or another. Is there any way to modify which interfaces are exposed to the sysex? Additionally, are these limitations of networking within a Network System Extension documented anywhere? Do you have any ideas why this specific limitation might exist?