Dear Developers, I would like to suggest an optimization for the logic governing the download and installation queue for app updates. Currently, when multiple applications are awaiting updates, the prioritization does not appear to consider the update payload size. My proposal is to implement a logic that prioritizes the download and installation of updates with a smaller delta size (fewer MB) before those with a larger delta. Practical Example: A 1MB update would be processed before a 500MB update, even if their arrival order in the queue was inverted. Potential Benefits: Perceived Speed Optimization (UX): Users would gain access to functional applications more quickly, especially in scenarios with multiple pending updates. Network Efficiency: In limited or intermittent bandwidth scenarios, completing smaller downloads first can reduce the chance of download failures and optimize network resource utilization. Device Resource Management: Frees up temporary storage and processing resources more rapidly for smaller updates. I believe this optimization would bring significant gains in terms of User Experience (UX) and the operational efficiency of the platform. Thank you for your attention and consideration. Sincerely,

Hello everyone, I'm developing a macOS application with an integrated Content Filter System Extension. Both the main app and the extension are signed with a Developer ID Application provisioning profile. When building in Xcode, I'm encountering an entitlement mismatch error. I've inspected the provisioning profile using the command: security cms -D -i FilterContentExtension-prod-profile.provisionprofile | grep -A 10 com.apple.developer.networking.networkextension And found that the com.apple.developer.networking.networkextension section only contains values with the -systemextension suffix, for example: content-filter-provider-systemextension. However, when I enable Network Extension → Content Filter in Xcode, the .entitlements file is generated with: content-filter-provider. This leads to the error: "Provisioning profile 'FilterContentExtension-prod-profile' doesn't match the entitlements file’s value for the com.apple.developer.networking.networkextension entitlement." My specific questions are: Why does this error occur? How can I use the content-filter-provider entitlement? If I want to use the content-filter-provider entitlement inside com.apple.developer.networking.networkextension for my Content Filter System Extension, what should I do?

We are currently working on a zero-configuration networking compliant device thru avahi-daemon. Our Device want to have multiple Instance name for different services. Example InstanceA._ipps._tcp.local. InstanceA._ipp._tcp.local. InstanceB._ipps._tcp.local. InstanceB._ipp._tcp.local. Will BCT confuse this as multiple device connected in the network and cause it to fail? Does Bonjour only allows only a Single Instance name with multiple services?

I'm currently testing URLFilter for use in a macOS product. After calling loadFromPreferences, I set the following configuration parameters: pirServerURL = URL(string: "http://localhost:8080")! pirAuthenticationToken = "AAAA" controlProviderBundleIdentifier = "{extension app bundle identifier}" However, when I call saveToPreferences, I get an Invalid Configuration error. Is there a way to determine which parameter is invalid or incorrectly set? Also, I would appreciate any macOS-specific examples of using NEURLFilterManager, as most of the documentation I’ve found seems to focus on iOS. Thank you.

I am trying to create an application extension which provides vpn functionality over network extension with packet-tunnel. But when I enable vpn it doesn't call related callbacks. Currently, i didn't find any example in qt documentation. So I read the documents of ios and qt and trying to find the right path. Here is the CMakeLists.txt add_executable(overlay-service MACOSX_BUNDLE main.cpp tunnel_provider.h tunnel_provider.mm) set_target_properties(overlay-service PROPERTIES MACOSX_BUNDLE_IDENTIFIER org.zenarmor.zenoverlay.network-extension BUNDLE YES XCODE_PRODUCT_TYPE com.apple.product-type.app-extension # XCODE_EMBED_FRAMEWORKS /System/Library/Frameworks/NetworkExtension.framework ) target_link_libraries( overlay-service PUBLIC Qt6::CorePrivate overlay-lib ) tunnel_provider.h #ifndef _TUNNEL_PROVIDER_H #define _TUNNEL_PROVIDER_H #import <Foundation/Foundation.h> #import <NetworkExtension/NetworkExtension.h> @interface ZenTunnelProvider : NEPacketTunnelProvider { int fd; } - (void) startTunnelWithOptions:(NSDictionary<NSString *,NSObject *> *) options completionHandler:(void (^)(NSError * error)) completionHandler; - (void) stopTunnelWithReason:(NEProviderStopReason) reason completionHandler:(void (^)()) completionHandler; @end #endif tunnel_provider.mm #import <Foundation/Foundation.h> #import <os/log.h> @implementation ZenTunnelProvider - (void) startTunnelWithOptions:(NSDictionary<NSString *,NSObject *> *) options completionHandler:(void (^)(NSError * error)) completionHandler { NSLog(@"===================== Tunnel Started, x=%i, %@", 5, self.protocolConfiguration); completionHandler(nil); } - (void) stopTunnelWithReason:(NEProviderStopReason) reason completionHandler:(void (^)()) completionHandler{ NSLog(@"===================== Tunnel Stopped");; completionHandler(); } @end How I create configuration is: provider_protocol.providerBundleIdentifier = @"org.zenarmor.zenoverlay.packet-tunnel"; provider_protocol.serverAddress = @"0.0.0.0"; provider_protocol.providerConfiguration = @{ @"helloString" : @"Hello, World!", @"magicNumber" : @42 }; NSLog(@"===================== Vpn configuration is written, x=%i", 5); vpn_manager.protocolConfiguration = provider_protocol; vpn_manager.localizedDescription = @"ZenOverlayTunnel"; vpn_manager.enabled = true; [vpn_manager saveToPreferencesWithCompletionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"err: %@", error); } else { NSLog(@"Successfully saved"); } }]; main.cpp #include <QCoreApplication> #include <iostream> int main(int argc, char **argv) { QCoreApplication app(argc, argv); std::cout << "Hello world" << std::endl; return app.exec(); } startTunnelWithOptions is not triggered when I enable vpn from settings on IOS. Could anyone. help to identify the issue?

Greetings I'm trying to get on iPad the SSID from the wifi I'm connected to. For that, I added the wifi entitlement and I'm requesting permission to the user for Location. Once I have it, I'm using the function CNCopySupportedInterfaces to get the interfaces, but I can only receive the en0, which using the method CNCopyCurrentNetworkInfo returns nil. I also tried using the NEHotspotNetwork.fetchCurrent and the SSID keeps being nil. So right now I'm drawing a blank. Is there any way to make it work? Thanks.

I have few API's written with URLSession. Will they work in Carrier-constrained network / satellite mode ?

Our app supports live streaming (RTSP, RTMP, WebRTC) functionality. After updating to the 18.5 Developer Beta version, we’ve encountered an issue where streaming over LTE is not working for customers using SKT (SK Telecom) as their carrier. Upon investigation, it seems that a similar issue might be occurring with a streaming service app called "SOOP." I would appreciate it if you could share any information regarding this bug. Thank you.

Network.framework: Happy Eyeballs cancels also-ran only after WebSocket handshake (duplicate WS sessions) Hi everyone 👋 When using NWConnection with NWProtocolWebSocket, I’ve noticed that Happy Eyeballs cancels the losing connection only after the WebSocket handshake completes on the winning path. As a result, both IPv4 and IPv6 attempts can send the GET / Upgrade request in parallel, which may cause duplicate WebSocket sessions on the server. Standards context RFC 8305 §6 (Happy Eyeballs v2) states: Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. This “SHOULD” is intentionally non-mandatory — implementations may reasonably delay cancellation to account for additional factors (e.g. TLS success or ALPN negotiation). So Network.framework’s current behavior — canceling after the WebSocket handshake — is technically valid, but it can have practical side effects at the application layer. Why this matters WebSocket upgrades are semantically HTTP GET requests (RFC 6455 §4.1). Per RFC 9110 §9.2, GET requests are expected to be safe and idempotent — they should not have side effects on the server. In practice, though, WebSocket upgrades often: include Authorization headers or cookies create authenticated or persistent sessions So if both IPv4 and IPv6 paths reach the upgrade stage, the server may create duplicate sessions before one connection is canceled. Questions / Request Is there a way to make Happy Eyeballs cancel the losing path earlier — for example, right after TCP or TLS handshake — when using NWProtocolWebSocket? If not, could Apple consider adding an option (e.g. in NWProtocolWebSocket.Options) to control the cancellation threshold, such as: after TCP handshake after TLS handshake after protocol handshake (current behavior) That would align the implementation more closely with RFC 8305 and help prevent duplicate, non-idempotent upgrade requests. Context I’m aware of Quinn’s post Understanding Also-Ran Connections. This report focuses specifically on the cancellation timing for NWProtocolWebSocket and the impact of duplicate upgrade requests. Although RFC 6455 and RFC 9110 define WebSocket upgrades as safe and idempotent HTTP GETs, in practice they often establish authenticated or stateful sessions. Thus, delaying cancellation until after the upgrade can create duplicate sessions — even though the behavior is technically RFC-compliant. Happy to share a sysdiagnose and sample project via Feedback if helpful. Thanks! 🙏 Example log output With Network Link Conditioner (Edge): log stream --info --predicate 'subsystem == "com.apple.network" && process == "WS happy eyeballs"' 2025-11-03 17:02:48.875258 [C3] create connection to wss://echo.websocket.org:443 2025-11-03 17:02:48.878949 [C3.1] starting child endpoint 2a09:8280:1::37:b5c3:443 # IPv6 2025-11-03 17:02:48.990206 [C3.1] starting child endpoint 66.241.124.119:443 # IPv4 2025-11-03 17:03:00.251928 [C3.1.1] Socket received CONNECTED event # IPv6 TCP up 2025-11-03 17:03:00.515837 [C3.1.2] Socket received CONNECTED event # IPv4 TCP up 2025-11-03 17:03:04.543651 [C3.1.1] Output protocol connected (WebSocket) # WS ready on IPv6 2025-11-03 17:03:04.544390 [C3.1.2] nw_endpoint_handler_cancel # cancel IPv4 path 2025-11-03 17:03:04.544913 [C3.1.2] TLS warning: close_notify # graceful close IPv4

We have a content filter system extension as part of our macOS app. The filter normally works correctly, activation and deactivation works as expected but occasionally we see an issue when the content filter is activated. When this issues occurs, the filter activation appears to behave correctly, no errors are reported. Using "systemextensionsctl list" we see the filter is labelled as "[activated enabled]". However, the installed content filter executable does not run. We have seen this issue on macOS 15.3 and later and on the beta macOS 26.1 RC. It happens only occasionally but when it does there is no indication as to why the executable is not running. There are no crash logs or errors in launchd logs. Both rebooting and deactivating/activating the filter do not resolve the issue. The only fix appears to be completely uninstalling the app (including content filter) and reinstalling. I have raised a FB ticket, FB20866080. Does anyone have any idea what could cause this?

I am developing an App based on Network Extension that lets all network requests on device access the Internet through a private Relay. I created an empty iOS App and only the entitlements file and ViewController.swift(Main.storyboard) file have been modified. The code was copied from the official video https://developer.apple.com/videos/play/wwdc2023/10002/ But, running the App on iPhone, the saveToPreferences API reported Error Domain=NERelayErrorDomain Code=3 "(null)" and the App doesn't look like it's changed at all (it doesn't jump to the Settings - VPN&Relay). Does anyone know why？Any reply would be greatly appreciated. The contents of the entitlements file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>relay</string> </array> </dict> </plist> ViewController.swift: import UIKit import NetworkExtension class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. } @IBAction func tap(_ sender: Any) { let newRelay = NERelay() let relayURL = URL(string: "https://relay.example.com:443/") newRelay.http3RelayURL = relayURL newRelay.http2RelayURL = relayURL newRelay.additionalHTTPHeaderFields = ["Authorization" : "PrivateToken=123"] let manager = NERelayManager.shared() manager.relays = [newRelay] manager.matchDomains = ["internal.example.com"] manager.isEnabled = false manager.saveToPreferences { err in print(err) } } }

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

We are developing an app that includes functionality to install an eSIM. While the eSIM installation process works fine, we're unable to get the ICCID from the installed eSIM card. When querying the associatedIccid from the CTCellularPlanProperties, it returns nil. Can you advise how we can get the ICCID from an eSIM that was installed via our app?

My personal project is a bit further along however after not being able to get this to work in my app I fell back to a much simpler/proven implementation out there. There is this project on GitHub with a guide that implements a barebones app extension with packet tunneling. I figure this can give us common ground. After changing the bundle and group identifiers to all end with -Caleb and or match up I tried running the app. The app extension does not work whatsoever and seemingly for reasons that are similar to my personal project. If I pull up the console and filter for the subsystem (com.github.kean.vpn-client-caleb.vpn-tunnel) I see the following. First you see installd installing it 0x16ba5f000 -[MIUninstaller _uninstallBundleWithIdentity:linkedToChildren:waitForDeletion:uninstallReason:temporaryReference:deleteDataContainers:wasLastReference:error:]: Destroying container com.github.kean.vpn-client-caleb.vpn-tunnel with persona 54D15361-A614-4E0D-931A-0953CDB50CE8 at /private/var/mobile/Containers/Data/PluginKitPlugin/2D0AE485-BB56-4E3E-B59E-48424CD4FD65 And then installd says this (No idea what it means) 0x16b9d3000 -[MIInstallationJournalEntry _refreshUUIDForContainer:withError:]: Data container for com.github.kean.vpn-client-caleb.vpn-tunnel is now at /private/var/mobile/Containers/Data/PluginKitPlugin/2D0AE485-BB56-4E3E-B59E-48424CD4FD65 Concerningly runningboardd seems to immediately try and stop it? Executing termination request for: <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {( "com.github.kean.vpn-client-caleb", "com.github.kean.vpn-client-caleb.vpn-tunnel" )}>> [app<com.github.kean.vpn-client-caleb(54D15361-A614-4E0D-931A-0953CDB50CE8)>:1054] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.github.kean.vpn-client-caleb/54D15361-A614-4E0D-931A-0953CDB50CE8] uuid:963149FA-F712-460B-9B5C-5CE1C309B2FC isPlaceholder:Y reportType:None maxTerminationResistance:Absolute attrs:[ <RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {( "com.github.kean.vpn-client-caleb", "com.github.kean.vpn-client-caleb.vpn-tunnel" )}>> allow:(null)> ]> Then runningboardd leaves a cryptic message Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd>:244] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.github.kean.vpn-client-caleb/54D15361-A614-4E0D-931A-0953CDB50CE8] uuid:963149FA-F712-460B-9B5C-5CE1C309B2FC isPlaceholder:Y" ID:33-244-5222 target:system attributes:[ <RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {( "com.github.kean.vpn-client-caleb", "com.github.kean.vpn-client-caleb.vpn-tunnel" )}>> allow:(null)> ]> And that seems to be all I have to go off of.... If I widen my search a bit I can see backboardd saying things like Connection removed: IOHIDEventSystemConnection uuid:57E97E5D-8CDE-467B-81CA-36A93C7684AD pid:1054 process:vpn-client type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{ HighFrequency = 1; bundleID = "com.github.kean.vpn-client-caleb"; pid = 1054; } state:0x1 events:119 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE Or Removing client connection <BKHIDClientConnection: 0xbf9828cd0; IOHIDEventSystemConnectionRef: 0xbf96d9600; vpid: 1054(vAF7); taskPort: 0x5D777; bundleID: com.github.kean.vpn-client-caleb> for client: IOHIDEventSystemConnection uuid:57E97E5D-8CDE-467B-81CA-36A93C7684AD pid:1054 process:vpn-client type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{ HighFrequency = 1; bundleID = "com.github.kean.vpn-client-caleb"; pid = 1054; } state:0x1 events:119 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE source:HID There's really nothing in the sysdiagnose either. No crash no nothing. I am stumped. Any idea what might be going wrong for me here? Has something about the way app extensions or sandbox rules work changed in later OSes?

I'm developing an iOS application in Swift that performs API calls using URLSession.shared. The requests work correctly when the app is in the foreground. However, when the app transitions to the background (for example, when the user switches to another app), the ongoing API calls are either paused or do not complete as expected. What I’ve tried: Using URLSession.shared.dataTask(with:) to initiate the API requests Observing application lifecycle events like applicationDidEnterBackground, but haven't found a reliable solution to allow requests to complete when backgrounded Goal: I want certain API requests to continue running or be allowed to complete even if the app enters the background. Question: What is the correct approach to allow API calls to continue running or complete when the app moves to the background? Should I be using a background URLSessionConfiguration instead of URLSession.shared? If so, how should it be properly configured and used in this scenario?

I'm running a Node.js server on my MacBook with Apple M4 Pro chip, macOS Sequoia 15.4, and Node.js v23.10.0. The server starts normally on port 5000 and logs show that it's listening correctly. However, when I try to access it via browser or Postman (http://localhost:5000/api/...), I get a 403 Forbidden error. After checking with lsof -i :5000, I noticed that the ControlCenter process is listening on port 5000 under the name commplex-main. Interestingly, this doesn't happen on M3 Pro machines. On those devices, Node.js runs fine on port 5000 and can be accessed from Postman and browsers. Is port 5000 now internally reserved by macOS or used by some system-level service in Sequoia or Apple Silicon (M4 Pro)? Should I avoid using this port going forward? Any official clarification would be appreciated.

Configure the App ID in the Apple Developer Portal. In the Network Extensions section, the Packet Tunnel section is not displayed, as shown in the figure below How to proceed with the configuration of App ID. In the Network Extensions section: Display the Packet Tunnel section Our account is a China region account

When filtering traffic to localhost (127.0.0.1), it causes Maven repository synchronization to fail in IntelliJ IDEA. However, Maven works correctly when local traffic is not filtered. I will provide a minimal code reproduction below. - (void)startFilterWithCompletionHandler:(void (^)(NSError *error))completionHandler { // Add code to initialize the filter NSMutableArray *rules = [NSMutableArray array]; NENetworkRule * rule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolTCP direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:rule action:NEFilterActionFilterData]]; rule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolUDP direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:rule action:NEFilterActionFilterData]]; NWHostEndpoint *hostEndpointIpv4 = [NWHostEndpoint endpointWithHostname:@"127.0.0.1" port:@"0"]; NENetworkRule *localHostRuleIpv4 = [[NENetworkRule alloc] initWithRemoteNetwork:hostEndpointIpv4 remotePrefix:32 localNetwork:hostEndpointIpv4 localPrefix:32 protocol:NENetworkRuleProtocolAny direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:localHostRuleIpv4 action:NEFilterActionFilterData]]; NEFilterSettings *filterSetting = [[NEFilterSettings alloc] initWithRules:rules defaultAction:NEFilterActionAllow]; [self applySettings:filterSetting completionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"Failed to apply filter settring: %@", error.localizedDescription); } completionHandler(error); }]; } Maven Sync error: System Log: 默认 17:35:13.184509+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 3bb6402f58a82e37 - flags 0x800840 0x80> lport 63166 fport 29735 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.184510+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so d6dde374c8cb613b - flags 0x800840 0x80> lport 63165 fport 29735 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.529546+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so cc915e74ba29f8cb - flags 0x800840 0x80> lport 63169 fport 39066 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.529546+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 2e15c3e54ebcc45 - flags 0x800840 0x80> lport 63168 fport 39066 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:14.046094+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 71f6d3a53472131f - flags 0x800840 0x80> lport 63172 fport 53241 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:14.046145+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so c88a367c9717185b - flags 0x800840 0x80> lport 63171 fport 53241 laddr 127.0.0.1 faddr 127.0.0.1 Environment Details: Operating System: macOS 15.5 (Sequoia) IDE: IntelliJ IDEA 2025.1 Relevant Technology: NEFilterDataProvider (Network Extension) I have found reports of similar problems online： https://discussionschinese.apple.com/thread/255270330?sortBy=rank https://blog.csdn.net/weixin_42339552/article/details/137402307 They all seem to be caused by network extension。

Hi~ I implemented network filtering on iOS using NEFilterControlProvider and NEFilterDataProvider. However, I found that their usage is restricted when distributing through the App Store. Does ADEP-based distribution allow the use of NEFilterControlProvider and NEFilterDataProvider? In TN3134, it states that NEPacketTunnelProvider requires MDM. Should I assume that NEFilterControlProvider and NEFilterDataProvider also require MDM in the same way? Thanks

Hi Everyone, I have a query regarding capturing an NWConnection instance inside the receive closure, which gets invoked whenever some raw bytes are received. I want to know whether this will create a strong retain cycle or not. My understanding is that NWConnection holds a reference to the closure, and if I capture the NWConnection instance inside the closure, the closure will have a reference back to the connection, which, according to my understanding, creates a strong reference cycle. Is my understanding correct? If so, how can we break the strong reference cycle — using a capture list, or is there any other way as well? Thanks