I’m building a macOS app with a DNS Proxy system extension for Developer ID + notarization, deployed via MDM, and Xcode fails the Developer ID Release build with a provisioning profile mismatch for com.apple.developer.networking.networkextension. Environment macOS: Sequoia (15.7.2) Xcode: 26.2 Distribution: Developer ID + notarization, deployed via MDM Host bundle ID: com.mydns.agent.MyDNSMacProxy DNS Proxy system extension bundle ID: com.mydns.agent.MyDNSMacProxy.dnsProxy Host entitlements (Release): File: MyDNSMacProxy/MyDNSMacProxyRelease.entitlements: "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.application-identifier</key> <string>B234657989.com.mydns.agent.MyDNSMacProxy</string> <key>com.apple.developer.networking.networkextension</key> <array> <string>dns-proxy</string> </array> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.team-identifier</key> <string>B234657989</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.mydns.MyDNSmac</string> </array> <key>keychain-access-groups</key> <array> <string>B234657989.*</string> </array> </dict> </plist> xcodebuild -showBuildSettings -scheme MyDNSMacProxy -configuration Release : PROVISIONING_PROFILE_SPECIFIER = main MyDNSMacProxy5 CODE_SIGN_IDENTITY = Developer ID Application Host Developer ID profile main_MyDNSMacProxy5.provisionprofile (via security cms -D): "Entitlements" => { "com.apple.application-identifier" => "B234657989.com.mydns.agent.MyDNSMacProxy" "com.apple.developer.team-identifier" => "B234657989" "com.apple.security.application-groups" => [ "group.com.mydns.MyDNSmac", ..., "B234657989.*" ] "keychain-access-groups" => [ "B234657989.*" ] "com.apple.developer.system-extension.install" => 1 "com.apple.developer.networking.networkextension" => [ "packet-tunnel-provider-systemextension", "app-proxy-provider-systemextension", "content-filter-provider-systemextension", "dns-proxy-systemextension", "dns-settings", "relay", "url-filter-provider", "hotspot-provider" ] } So: App ID, team ID, keychain and system‑extension.install match. The profile’s com.apple.developer.networking.networkextension is a superset of what I request in the host entitlements (dns-proxy only). System extension (for context) DNS Proxy system extension target: NSExtensionPointIdentifier = com.apple.dns-proxy NetworkExtension → NEProviderClasses → com.apple.networkextension.dns-proxy → my provider class Entitlements: com.apple.developer.networking.networkextension = ["dns-proxy-systemextension"] This target uses a separate Developer ID profile and builds successfully. Xcode error Release build of the host fails with: …MyDNSMacProxy.xcodeproj: error: Provisioning profile "main MyDNSMacProxy5" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. (in target 'MyDNSMacProxy' from project 'MyDNSMacProxy') Xcode UI also says: Entitlements: 6 Included, 1 Missing Includes com.apple.developer.team-identifier, com.apple.application-identifier, keychain-access-groups, com.apple.developer.system-extension.install, and com.apple.security.application-groups. Doesn’t match entitlements file value for com.apple.developer.networking.networkextension. Because of this, the app bundle isn’t produced and I can’t inspect the final signed entitlements. Questions: For com.apple.developer.networking.networkextension, should Xcode accept a subset of values in the entitlements (here just dns-proxy) as long as that value is allowed by the Developer ID profile, or does it currently require a stricter match? Is the following configuration valid for Developer ID + MDM with a DNS Proxy system extension: Host entitlements: ["dns-proxy"] System extension entitlements: ["dns-proxy-systemextension"] Host profile’s NE array includes the DNS Proxy system extension types. If this is a known limitation or bug in how Xcode validates NE entitlements for Developer ID, is there a recommended workaround? Thanks for any guidance.

I have a network extension that hosts a NEFilterDataProvider & NETransparentProxyProvider. One of the use case that this caters to is : Proxy some flows (depending on originating app) while Content filter is also filtering flows based on business logic. The issue I am running into happens when FilterDataProvider sees a flow & responds with filterDataVerdict(withFilterInbound: false, peekInboundBytes: 0, filterOutbound: true, peekOutboundBytes:1024 to handleNewFlow(_ flow: NEFilterFlow) [wants to peek more bytes on outbound connection before making a decision] TransparentProxyProvider sees the flow & responds with NO to handleNewFlow(_ flow: NEAppProxyFlow) as it is not interested in in proxying that flow. When this occurs, we see connection being dropped by kernel. I wanted to know if this is expected behavior. Logs when this occurs: 2026-02-06 14:57:09.725854-0600 0x17c918f Default 0x0 569 0 com.test.networkextension: (NetworkExtension) [com.apple.networkextension:] [Extension com.test.network]: provider rejected new flow TCP headless_shell[{length = 20, bytes = 0xe69023e655b6065e1a2f94fa508807fa43f6ac8a}] remote: 100.72.0.3:443 interface utun9 2026-02-06 14:57:09.725874-0600 0x17ca166 Debug 0x0 569 0 com.test.networkextension: (NetworkExtension) [com.apple.networkextension:] New flow verdict for D89B5B5D-793C-4940-D955-37BE33F18005: drop = NO remediate = NO needRules = NO shouldReport = YES pause = NO urlAppendString = NO filterInbound = NO peekInboundBytes = 0 filterOutbound = YES peekOutboundBytes = 1024 statisticsReportFrequency = low 2026-02-06 14:57:09.726009-0600 0x17ca24a Default 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Closing reads (sending SHUT_WR), closed by plugin (flow error: 0) 2026-02-06 14:57:09.726028-0600 0x17ca24a Default 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Closing writes, sending SHUT_RD 2026-02-06 14:57:09.726040-0600 0x17ca24a Debug 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Dropping the director 2026-02-06 14:57:09.726047-0600 0x17ca24a Default 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Destroying, client tx 0, client rx 0, kernel rx 0, kernel tx 0 I wanted to know how neagent is handling this when for a flow, filterDataProvider wants to look at the traffic while transparentProxy is not interested in handling that flow

I have several macOS systems (Apple Silicon) running various flavours of macOS 26 (26.2 and 26.3 RC). I also have a couple of Centos 10 Linux (ARM64) systems. All are connected to my 10 GbE switch, so not routers or anything else in the path that could mess with ECN flags. The network is dual stack. The CentOS systems are configured to offer / accept ECN for both outgoing and incoming connections (net.ipv4.tcp_ecn = 1). The macOS systems have their default settings which also supposedly behave the same way: $ sysctl -a | grep ecn net.inet.tcp.ecn_timeout: 5 net.inet.tcp.ecn_setup_percentage: 100 net.inet.tcp.accurate_ecn: 0 net.inet.tcp.ecn_initiate_out: 1 net.inet.tcp.ecn: 1 net.inet.ipsec.ecn: 0 net.inet.mptcp.probecnt: 5 net.inet6.ipsec6.ecn: 0 net.classq.fq_codel.enable_ecn: 0 I have a simple throughput test program (written in C and using the standard socket API) that runs as both a client and a server which I have ported to both OS. When I run it between the two Linux systems using either IPv4 or IPv6 a tcpdump / Wireshark trace shows that ENC is active in both directions. Internet Protocol / Differentiated Services shows Explicit Congestion Notification: ECN-Capable Transport code point '10' for both flows. When I run the same test between one of the macOS systems and one of the Linux systems what I observe is that when using IPv4 the Linux -> macOS flow has Not ECN_capable Transport (0) while the macOS -> Linux flow has ECN-Capable Transport code point '10'. This seems wrong. I even tried enabling LS4 (defaults write -g network_enable_l4s -bool true) but unsurprisingly this made no difference. If I run the same test over IPv6 then both flows have ECN-Capable Transport code point '10'. How can I ensure that macOS tries to negotiate ECN for outgoing IPv4 connections? Or is this a macOS bug?

Hi, I tried to follow this guide: https://aninterestingwebsite.com/documentation/networkextension/filtering-traffic-by-url And this: https://github.com/apple/pir-service-example I already deploy the pir service on my server. And set the configuration on the app like this: { name = SimpleURLFilter identifier = xxxxx applicationName = SimpleURLFilter application = com.xxxx.SimpleURLFilter grade = 2 urlFilter = { Enabled = YES FailClosed = NO AppBundleIdentifier = com.mastersystem.SimpleURLFilter ControlProviderBundleIdentifier = com.xxxx.SimpleURLFilter.SimpleURLFilterExtension PrefilterFetchFrequency = 2700 pirServerURL = https://xxxxx/pir pirPrivacyPassIssuerURL = https://xxxxx/pir AuthenticationToken = AAAA pirPrivacyProxyFailOpen = NO pirSkipRegistration = NO } } But I got this error when I tried to enable the service on the app: Received filter status change: <FilterStatus: 'stopped' errorMessage: 'The operation couldn’t be completed. (NetworkExtension.NEURLFilterManager.Error error 9.)'> What does that error mean? And how to fix it?

Hi everyone, I’m working with UDP Multicasting on iOS (iOS 15+) using Network.framework and facing a confusing issue. Setup: Multicast IP: 239.255.0.1 Port: 45454 Using NWConnectionGroup / NWMulticastGroup NSLocalNetworkUsageDescription is present in Info.plist Devices are on the same Wi-Fi network Problem: Receiving multicast packets works perfectly Sending multicast packets does NOT work No errors are thrown send() completion handler reports success stateUpdateHandler sometimes doesn’t transition to .ready No packets are actually transmitted on the network Observations: The app can receive data from other multicast senders Sending appears to be silently blocked Reinstalling the app fixes the issue This points to a Local Network permission problem If permission was denied once, iOS does not re-prompt Inbound multicast works, outbound multicast is blocked Questions: Is it expected on iOS that receiving multicast works even when sending is blocked? Is reinstalling the app the only way to recover if Local Network permission was denied? Is there any reliable runtime way to detect that outbound multicast is blocked? Is NWConnectionGroup the correct and only supported way to send multicast on iOS? Any clarification or official guidance would really help. Thanks in advance!

Description I am seeing a consistent crash in a NEDNSProxyProvider on iOS when migrating from completion handlers to the new Swift Concurrency async/await variants of readDatagrams() and writeDatagrams() on NEAppProxyUDPFlow. The crash occurs inside the Swift Concurrency runtime during task resumption. Specifically, it seems the Task attempts to return to the flow’s internal serial executor (NEFlow queue) after a suspension point, but fails if the flow was invalidated or deallocated by the kernel while the task was suspended. Error Signature Thread 4: EXC_BAD_ACCESS (code=1, address=0x28) Thread 4 Queue : NEFlow queue (serial) #0 0x000000018fe919cc in swift::AsyncTask::flagAsAndEnqueueOnExecutor () #9 0x00000001ee25c3b8 in _pthread_wqthread () Steps The crash is highly timing-dependent. To reproduce it reliably: Use an iOS device with Developer Settings enabled. Go to Developer > Network Link Conditioner -> High Latency DNS. Intercept a DNS query and perform a DoH (DNS-over-HTTPS) request using URLSession. The first few network requests should trigger the crash Minimum Working Example (MWE) class DNSProxyProvider: NEDNSProxyProvider { override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { guard let udpFlow = flow as? NEAppProxyUDPFlow else { return false } Task(priority: .userInitiated) { await handleUDPFlow(udpFlow) } return true } func handleUDPFlow(_ flow: NEAppProxyUDPFlow) async { do { try await flow.open(withLocalFlowEndpoint: nil) while !Task.isCancelled { // Suspension point 1: Waiting for datagrams let (flowData, error) = await flow.readDatagrams() if let error { throw error } guard let flowData, !flowData.isEmpty else { return } var responses: [(Data, Network.NWEndpoint)] = [] for (data, endpoint) in flowData { // Suspension point 2: External DoH resolution let response = try await resolveViaDoH(data) responses.append((response, endpoint)) } // Suspension point 3: Writing back to the flow // Extension will crash here on task resumption try await flow.writeDatagrams(responses) } } catch { flow.closeReadWithError(error) flow.closeWriteWithError(error) } } private func handleFlowData(_ packet: Data, endpoint: Network.NWEndpoint, using parameters: NWParameters) async throws -> Data { let url = URL(string: "https://dns.google/dns-query")! var request = URLRequest(url: url) request.httpMethod = "POST" request.httpBody = packet request.setValue("application/dns-message", forHTTPHeaderField: "Content-Type") let (data, _) = try await URLSession.shared.data(for: request) return data } } Crash Details & Analysis The disassembly at the crash point indicates a null dereference of an internal executor pointer (Voucher context): ldr x20, [TPIDRRO_EL0 + 0x340] ldr x0, [x20, #0x28] // x20 is NULL/0x0 here, resulting in address 0x28 It appears that NEAppProxyUDPFlow’s async methods bind the Task to a specific internal executor. When the kernel reclaims the flow memory, the pointer in x20 becomes invalid. Because the Swift runtime is unaware that the NEFlow queue executor has vanished, it attempts to resume on non-existing flow and then crashes. Checking !Task.isCancelled does not prevent this, as the crash happens during the transition into the task body before the cancellation check can even run. Questions Is this a known issue of the NetworkExtension async bridge? Why does Task.isCancelled not reflect the deallocation of the underlying NEAppProxyFlow? Is the only safe workaround? Please feel free to correct me if I misunderstood anything here. I'll be happy to hear any insights or suggestions :) Thank you!

I've created an application, applied for the multicast permissioning, it was granted to my bundleID and therefore my application. I've since come out with new versions of the same app, but now multicast entitlement is no longer provisioned. What must I check to identify where the problem exists? I can provide any details needed to troubleshoot.

Is this even possible? Instead of any pairing dialog appearing, my central code get the "Authentication is insufficient" error when reading the characteristic. My peripheral (in the macOS app) code uses the .notifyEncryptionRequired property and uses .readEncryptionRequired and .writeEncryptionRequired permissions. No descriptors are set, but I think they get added automatically since this characteristic notifies. 2900 and 2902 descriptors are set by the peripheral/CoreBluetooth. If the Mac and iPhone are using the same Apple ID does that affect pairing?

Have you ever encountered the issue where the Wi-Fi MAC address information can no longer be retrieved after I updated to iOS 26?

My iOS application needs to connect a device by wifi and exchange data between them. The way of transmission is using the UDP protocol, most of all, it works well. But some part of iOS devices will loss the package always. Even if re-open the application or reboot wifi devices, or reboot iOS devices, it can not be solved. Only reset the network settings on iOS devices could fix it. But this can not make sure that be well always, if occurs in the future. User need to reset network setting again. Are there any brothers know or meet this phenomenon? Thanks for your time to research this.

Hello Apple Support Team, We are seeing a production crash on iOS 26 devices that appears to originate from Apple system frameworks rather than application code. Crash Summary Crash signature: _xzm_xzone_malloc_freelist_outlined Crashed thread: com.apple.network.connections Frameworks involved: CFNetwork, Security, libdispatch, libsystem_malloc Affected OS: iOS 26.x App built with: Xcode 16 Devices: Multiple models (not device-specific) Reproducibility: Intermittent, higher frequency during app launch / background networking Observed Stack Trace (top frames) _xzm_xzone_malloc_freelist_outlined dispatch_data_create_alloc xpc_data_deserialize SecTrustEvaluateIfNecessary CFNetwork HTTPProtocol / HTTP3Connection com.apple.network.connections App Context The app uses URLSession for networking. Multiple third-party SDKs are integrated (Firebase Analytics, Dynatrace, Appsflyer, and similar analytics/monitoring SDKs). These SDKs perform concurrent background network requests, especially during app launch and foreground transitions. No unsafe memory operations (manual malloc/free, unsafe pointers, or custom networking stacks) are used in the app code. Key Observations The crash is predominantly observed on iOS 26 and not on earlier iOS versions. Stack traces do not include application symbols. Disabling or delaying analytics SDK initialization significantly reduces the crash rate. Reducing concurrent network requests and limiting HTTP/3 usage also mitigates the issue. This suggests a potential regression in CFNetwork / Network.framework / HTTP/3 handling combined with the new memory allocator (xzone) on iOS 26. Impact Random app termination during background networking. Occurs without a clear deterministic repro path, making it difficult to fully mitigate at the app level. Request Could you please help investigate whether this is a known iOS 26 issue related to: HTTP/3 / QUIC networking XPC deserialization Memory allocation in the new xzone allocator High-concurrency network requests We would appreciate guidance on: Recommended mitigations Whether this issue is already tracked internally Any best practices for apps integrating multiple analytics SDKs on iOS 26 Crash logs and additional diagnostics can be provided if needed. Thank you for your support. Best regards, Dhananjay

I have been toying around with the URL filter API, and now a few installed configurations have piled up. I can't seem to remove them. I swear a few betas ago I could tap on one and then delete it. But now no tap, swipe, or long press does anything. Is this a bug?

Based on https://aninterestingwebsite.com/documentation/networkextension/nednssettings/searchdomains , we expect the values mentioned in searchDomains to be appended to a single label DNS query. However, we are not seeing this behavior. We have a packetTunnelProvider VPN, where we set searchDomains to a dns suffix (for ex: test.com) and we set matchDomains to applications and suffix (for ex: abc.com and test.com) . When a user tries to access https://myapp , we expect to see a DNS query packet for myapp.test.com . However, this is not happening when matchDomainsNoSearch is set to true. https://aninterestingwebsite.com/documentation/networkextension/nednssettings/matchdomainsnosearch When matchDomainsNoSearch is set to false, we see dns queries for myapp.test.com and myapp.abc.com. What is the expected behavior of searchDomains?

Greetings, According to Apple's Wi-Fi Aware documentation (https://aninterestingwebsite.com/documentation/wifiaware) the Wi-Fi Aware APIs can be used only with peer devices that have been paired. Pairing can be performed using AccessorySetupKit or DeviceDiscoveryUI. Unfortunately, the sample code for Wi-Fi Aware doesn't include either of these APIs. (https://aninterestingwebsite.com/documentation/wifiaware/building-peer-to-peer-apps) Looking at the sample code for AccessorySetupKit (https://aninterestingwebsite.com/documentation/accessorysetupkit/setting-up-and-authorizing-a-bluetooth-accessory) there is only an example using Bluetooth. And the AccessorySetupKit APIs don't yet document how Wi-Fi Aware is used or how one sets up the Info.plist with the appropriate keys. Can Apple update its example code to fill in these gaps or point me to documentation that can fill in these gaps? It is hard to develop an understanding of the capabilities of these APIs when they are so poorly documented. Thanks for any help, Smith

I have to continuously disable Limit IP Tracking on my local Wi-Fi network. When it's enable I am not able to access some services on the same subnet that falls under rfc1918. Accessing remote network, over site to site vpn, is not affected, just my local network. I opened FB21483619 for this. I would expect to see rfc1918 subnets not included. Also would expect all DNS queries to be sent to the servers provided in DHCP.

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) We are using JamF MDM profile with VPN payload for deployment. With this MDM profile, we are observing an issue, ie TransparentProxy extension is not enabled when user performs logout and login and only in Sonoma. By analyzing it further we are noticing that in Sonoma some times, the system invokes NETransparentProxyProvider's stopProxy delegate once or twice with NEProviderStopReason as 12 ie userLogout. Due to this after login the system extension is not activated.

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

Hello, I have a .app NSApplication which is ran as a LaunchDaemon, in it's lifecycle I never call any AppKit functions (I start it with CFRunLoopRun). (mentioned on this post as well). I intercept a couple of signals using signal(s) in order to trigger CFRunLoopStop(CFRunLoopGetCurrent()) to do some cleanup. This LaunchDaemon has the purpose of providing VPN connectivity, as such I call connect functions that trigger the "Add VPN configuration" dialog (I can't provide extra details about this, as I integrate another SDK so I'm not sure what happens under the hood) and I noticed that whenever it is displayed, after allowing it, during the lifecycle of the application when it's time to send the signal, the signal isn't received. I tried re-adding the NSApp callbacks in order to investigate, but it looks like those aren't called as well. I'm interested in knowing more about this scenario and what happens... I couldn't really find information about this dialog... Thanks!

As part of iOS 26, we get X25519MLKEM768 key exchange group support, but SecP256r1MLKEM768 and SecP384r1MLKEM1024 are not supported. Is there any way to enable these key exchange groups on iOS 26? We need them for WKWebView and NSURLSession. STEPS TO REPRODUCE On iOS 26, connect to the PQC server using Safari. The key exchange group is limited to X25519MLKEM768.

I've implemented func urlSession(_ session: URLSession, task: URLSessionTask, willPerformHTTPRedirection response: HTTPURLResponse, newRequest request: URLRequest, completionHandler: @escaping (URLRequest?) -> Void) and func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) I've put a breakpoint in each but the BP in willPerformHTTPRedirection never fires. When the didWriteData fires and I inspect downloadTask.originalRequest I see my original request URL When I inspect downloadTask.currentRequest the returned request contains a different URL. I'm the farthest thing from an HTTP wizard, but I had thought when originalRequest differs from currentRequest there had been some sort of server-side 'redirection'. Is there a way for my code to receive a callback when something like this happens? NOTE: my download code works fine, I'm just hoping to detect the case when currentRequest changes. any/all guidance greatly appreciated on the off chance it helps, are are my original and current request values: (lldb) po downloadTask.originalRequest ▿ Optional<URLRequest> ▿ some : https://audio.listennotes.com/e/p/c524803c1a90412f922948274ecc3625/ (lldb) po downloadTask.currentRequest ▿ Optional<URLRequest> ▿ some : https://26973.mc.tritondigital.com:443/OMNY_HAPPIERWITHGRETCHENRUBIN_PODCAST_P/media-session/76cfceb2-1801-4570-b830-ded57611a9cf/d/clips/796469f9-ea34-46a2-8776-ad0f015d6beb/e1b22d0b-6974-4bb8-81ba-b2480119983c/2f35a8ca-b982-44e9-8122-b3dc000ae0e1/audio/direct/t1769587393/Ep_571_Want_to_Join_Us_for_a_No-Spend_February_Plus_a_Better_Word_for_Squats.mp3?t=1769587393&in_playlist=751ada7f-ded3-44b9-bfb8-b2480119985b&utm_source=Podcast