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...

Starting in iOS 26, two notable changes have been made to CallKit, LiveCommunicationKit, and the PushToTalk framework: As a diagnostic aid, we're introducing new dialogs to warn apps of voip push related issue, for example when they fail to report a call or when when voip push delivery stops. The specific details of that behavior are still being determined and are likely to change over time, however, the critical point here is that these alerts are only intended to help developers debug and improve their app. Because of that, they're specifically tied to development and TestFlight signed builds, so the alert dialogs will not appear for customers running app store builds. The existing termination/crashes will still occur, but the new warning alerts will not appear. As PushToTalk developers have previously been warned, the last unrestricted PushKit entitlement ("com.apple.developer.pushkit.unrestricted-voip.ptt") has been disabled in the iOS 26 SDK. ALL apps that link against the iOS 26 SDK which receive a voip push through PushKit and which fail to report a call to CallKit will be now be terminated by the system, as the API contract has long specified. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

We are using the [NEHotspotHelper supportedNetworkInterfaces] to get the Wi-Fi interface in our app, but it occasionally crashes on some devices with the following stack trace: 0 CaptiveNetwork 0x0000000221d87a4c ServerConnectionGetHandlerQueue + 0 (ServerConnection.c:509) 1 CaptiveNetwork 0x0000000221d8577c CNPluginCopySupportedInterfaces + 180 (CNPlugin.c:457) 2 NetworkExtension 0x00000001b0446618 +[NEHotspotHelper supportedNetworkInterfaces] + 32 (NEHotspotHelper.m:563) It seems like the crash is happening on apple's api of supportedNetworkInterfaces. We would like to understand the cause of the crash.

I'm using NERelayManager to set Relay configuration which all works perfectly fine. I then do a curl with the included domain and while I see QUIC connection succeeds with relay server and H3 request goes to the server, the connection gets abruptly closed by the client with "Software caused connection abort". Console has this information: default 09:43:04.459517-0700 curl nw_flow_connected [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] Transport protocol connected (quic) default 09:43:04.459901-0700 curl [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] event: flow:finish_transport @0.131s default 09:43:04.460745-0700 curl nw_flow_connected [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] Joined protocol connected (http3) default 09:43:04.461049-0700 curl [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] event: flow:finish_transport @0.133s default 09:43:04.465115-0700 curl [C2 E47A3A0C-7275-4F6B-AEDF-59077ABAE34B 192.168.4.197:4433 quic, multipath service: 1, tls, definite, attribution: developer] cancel default 09:43:04.465238-0700 curl [C2 E47A3A0C-7275-4F6B-AEDF-59077ABAE34B 192.168.4.197:4433 quic, multipath service: 1, tls, definite, attribution: developer] cancelled [C2 FCB1CFD1-4BF9-4E37-810E-81265D141087 192.168.4.139:53898<->192.168.4.197:4433] Connected Path: satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi Duration: 0.121s, QUIC @0.000s took 0.000s, TLS 1.3 took 0.111s bytes in/out: 2880/4322, packets in/out: 4/8, rtt: 0.074s, retransmitted bytes: 0, out-of-order bytes: 0 ecn packets sent/acked/marked/lost: 3/1/0/0 default 09:43:04.465975-0700 curl nw_flow_disconnected [C2 192.168.4.197:4433 cancelled multipath-socket-flow ((null))] Output protocol disconnected default 09:43:04.469189-0700 curl nw_endpoint_proxy_receive_report [C1.1 IPv4#124bdc4d:80 in_progress proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, proxy, uses wifi)] Privacy proxy failed with error 53 ([C1.1.1] masque Proxy: http://192.168.4.197:4433) default 09:43:04.469289-0700 curl [C1.1.1 192.168.4.197:4433 failed socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] event: flow:failed_connect @0.141s, error Software caused connection abort Relay server otherwise works fine with our QUIC MASQUE clients but not with built-in macOS MASQUE client. Anything I'm missing?

For our outdoor power supply company that builds public WiFi networks at camping sites, we want to implement the following features in our app: Scan surrounding WiFi networks When detecting specific public WiFi SSIDs, provide users with corresponding passwords Automatically connect to those WiFi networks Regarding the NEHotspotHelper API permission application, when I clicked on https://developer.apple.com/contact/request/network-extension, it redirected me to https://developer.apple.com/unauthorized/. I'm not sure where to properly apply for this permission now.

From time to time the subject of NECP grows up, both here on DevForums and in DTS cases. I’ve posted about this before but I wanted to collect those tidbits into single coherent post. If you have questions or comments, start a new thread in the App & System Services > Networking subtopic and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" A Peek Behind the NECP Curtain NECP stands for Network Extension Control Protocol. It’s a subsystem within the Apple networking stack that controls which programs have access to which network interfaces. It’s vitally important to the Network Extension subsystem, hence the name, but it’s used in many different places. Indeed, a very familiar example of its use is the Settings > Mobile Data [1] user interface on iOS. NECP has no explicit API, although there are APIs that are offer some insight into its state. Continuing the Settings > Mobile Data example above, there is a little-known API, CTCellularData in the Core Telephony framework, that returns whether your app has access to WWAN. Despite having no API, NECP is still relevant to developers. The Settings > Mobile Data example is one place where it affects app developers but it’s most important for Network Extension (NE) developers. A key use case for NECP is to prevent VPN loops. When starting an NE provider, the system configures the NECP policy for the NE provider’s process to prevent it from using a VPN interface. This means that you can safely open a network connection inside your VPN provider without having to worry about its traffic being accidentally routed back to you. This is why, for example, an NE packet tunnel provider can use any networking API it wants, including BSD Sockets, to run its connection without fear of creating a VPN loop [1]. One place that NECP shows up regularly is the system log. Next time you see a system log entry like this: type: debug time: 15:02:54.817903+0000 process: Mail subsystem: com.apple.network category: connection message: nw_protocol_socket_set_necp_attributes [C723.1.1:1] setsockopt 39 SO_NECP_ATTRIBUTES … you’ll at least know what the necp means (-: Finally, a lot of NECP infrastructure is in the Darwin open source. As with all things in Darwin, it’s fine to poke around and see how your favourite feature works, but do not incorporate any information you find into your product. Stuff you uncover by looking in Darwin is not considered API. [1] Settings > Cellular Data if you speak American (-: [2] Network Extension providers can call the createTCPConnection(to:enableTLS:tlsParameters:delegate:) method to create an NWTCPConnection [3] that doesn’t run through the tunnel. You can use that if it’s convenient but you don’t need to use it. [3] NWTCPConnection is now deprecated, but there are non-deprecated equivalents. For the full story, see NWEndpoint History and Advice. Revision History 2025-12-12 Replaced “macOS networking stack” with “Apple networking stack” to avoid giving the impression that this is all about macOS. Added a link to NWEndpoint History and Advice. Made other minor editorial changes. 2023-02-27 First posted.

Dear Apple Developer Technical Support, I am currently developing a macOS network filtering solution using NetworkExtension with NEFilterDataProvider. During implementation of the handleOutboundData logic, we are using the following verdict: NEFilterNewFlowVerdict.filterDataVerdict( withFilterInbound: true, peekInboundBytes: InboundPeekBytes, filterOutbound: true, peekOutboundBytes: OutboundPeekBytes ) However, we have encountered an issue when SMB traffic is involved. When SMB protocol communication occurs, the network connection occasionally becomes unresponsive or appears to stall when peekOutboundBytes is set to a large value. Through testing, we observed the following behavior: On some systems, reducing the peekOutboundBytes value allows SMB communication to proceed normally. On other systems, even relatively small values can still cause the SMB connection to stall. This behavior appears inconsistent across different macOS environments. Because of this, we would like to clarify the following: Is there a documented or recommended maximum value for peekOutboundBytes when using NEFilterNewFlowVerdict.filterDataVerdict? Are there any internal limits or constraints within NetworkExtension that could cause SMB traffic to stall when the peek buffer size is too large? Are there best practices for selecting appropriate peekInboundBytes / peekOutboundBytes values when filtering high-throughput protocols such as SMB? If necessary, we can provide additional information such as macOS version, test environment details, and logs. Thank you for your assistance. Best regards, sangho

I am trying to activate an application which sends my serial number to a server. The send is being blocked. The app is signed but not sandboxed. I am running Sequoia on a recent iMac. My network firewall is off and I do not have any third party virus software. I have selected Allow Applications from App Store & Known Developers. My local network is wifi using the eero product. There is no firewall or virus scanning installed with this product. Under what circumstances will Mac OS block outgoing internet connections from a non-sandboxed app? How else could the outgoing connection be blocked?

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

I need to run multiple, slightly different copies of a modeling tool, which all need access to a model repository on a different machine. Security Settings -> Network tends to pick one modeling tool (and unfortunately the wrong one) for permission, but the dialog offers no way to add the other copies manually. Where can I configure the permission on low level. [macOS Sequoia 15.6.1]

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

I am trying to intercept localhost connections within NETransparentProxyProvider system extension. As per NENetworkRule documentation If the address is a wildcard address (0.0.0.0 or ::) then the rule will match all destinations except for loopback (127.0.0.1 or ::1). To match loopback traffic set the address to the loopback address. I tried to add NWHostEndpoint *localhostv4 = [NWHostEndpoint endpointWithHostname:@"127.0.0.1" port:@""]; NENetworkRule *localhostv4Rule = [[NENetworkRule alloc] initWithDestinationNetwork:localhostv4 prefix:32 protocol:NENetworkRuleProtocolAny]; in the include network rules. I tried several variations of this rule like port 0, prefix 0 and some others. But the provider disregards the rule and the never receives any traffic going to localhost on any port. Is there any other configuration required to receive localhost traffic in NETransparentProxyProvider?

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'm a long-time developer, but pretty new to Swift. I'm trying to get information from a web service (and found code online that I adjusted to build the function below). (Note: AAA_Result -- referenced towards the end -- is another class in my project) Trouble is, I'm getting the subject error on the call to session.dataTask. Any help/suggestions/doc pointers will be greatly appreciated!!! var result: Bool = false var cancellable: AnyCancellable? self.name = name let params = "json={\"\"}}" // removed json details let base_url = URL(string: "https://aaa.yyy.com?params=\(params)&format=json")! // removed URL specifics do { let task = URLSession.shared.dataTask(with: base_url) { data, response, error in if let error = error { print("Error: \(error)") } guard let response = response as? HTTPURLResponse, (200...299).contains(response.statusCode) else { print("Error \(String(describing: response))") } do { let decoder = JSONDecoder() let ar = try decoder.decode(AAA_Result.self, from: response.value) // removed specific details... result = true } catch { print(error) } } task.resume() } catch { print(error) } return result }

[Q] Has there been a change in macOS 15.3.2 and later that can explain why some UDP traffic is not seen by some Network Extensions when it is in previous macOS minor and major versions?

We have a vpn app which uses PacketTunnelProvider. We also support per-app vpn for iOS, I need help with debugging steps for an issue I am facing recently. In the per app vpn, we have split tunneling: some urls should be tunneled while others should be direct, for tunneled urls/ips everything is working as expected. But for "direct" resources, I am facing an issue where sometimes I don't get an ACK back from the browser. Leading to a series of retransmissions and eventually the direct website not loading. Some more points of data: we do get true for the writePackets call, which seems to mean that the vpn app did write the packets to the TUN interface, but we don't get an ACK from the browser. I want some way of debugging this further so I can check if the browser actually got the packets. I also suspect that there might be a loop with packets (we are reading the packets we just wrote onto TUN), but can't say for sure since the issue is intermittent, in case of a loop, I would expect it to always help. Any help would be greatly appreciated.

I develop a terminal app with c++. Everything was fin until i upgraded to Sequoia. If i debug my program with Xcode, all requests to a local network like MQTT fails. How can i grant XCODE the privilege to access the local network?

Hey, We also opened a feedback assistant request, and also opened a ticket with Apple Developer Technical Support a while ago that notice the unmount problem also but it was before we pin point the problem to the Network Extension. After a further investigation, we've found out that the root cause of this problem is cause by having a network filter from the NetworkExtension provider on (Specifically we have tested with the NEFilterDataProvider) while having a Xsan volume. The NEFilterDataProvider causing problems for the Xsan, and is stalling the shutdown until we get a panic from watchdog timeout, and only then the mac is fully shutdown. The problem from what we investigated and also talked with you, is that the Xsan process can't unmount the volume and stuck. We have also noticed that if we install a network extension and allow the popup of the network filters, i.e enabled the NEFilterDataProvider the computer is stuck, and the finder is in a non responsive state until a reboot (Also probably due to the fact the Xsan is now in a problematic state). This tests was done on latest versions of MacOs 13 & 14. We have taken a sysdiagnose from the computer while we have tested. Do you familiar with the problem (We got no answer on the feedback assistant)? Thank you, Idan

Hi, I built a system that can detect and block Short Form Videos like Instagram Reels and Youtube Shorts. It works by connecting the iphone to a VPN and then do statistics on network packets (no decryption). I was wondering the feasibility of porting this to run on device. Functionality wise I would need: packet interception, packet drop, DNS query interception. I saw that Content filter providers could be something to look into, but then I read an article of how you would have to have a managed device which is not ideal for the end user. New to apple development, the lack of snippets and code examples is confusing.

For our outdoor power supply company that builds public WiFi networks at camping sites, we want to implement the following features in our app: Scan surrounding WiFi networks When detecting specific public WiFi SSIDs, provide users with corresponding passwords Automatically connect to those WiFi networks Regarding the NEHotspotHelper API permission application, when I clicked on https://developer.apple.com/contact/request/network-extension, it redirected me to https://developer.apple.com/unauthorized/. I'm not sure where to properly apply for this permission now.