We are developing an iOS application that uses the MobileVLCKit framework (version 3.7.3) for RTSP video streaming. We have encountered a critical performance issue that directly affects user experience. Problem Description When the app is granted the Local Network permission (the switch in Apps → OurApp → Local Network), the VLC media player takes 10–15 seconds to start playback after calling play(). If the user manually disables this permission, playback starts immediately (within 1 second). The issue is 100% reproducible on real devices and does not appear on the simulator. What we have tried Adjusting VLC options (network-caching, rtsp-tcp, clock-synchro, etc.) — no effect. Using different RTSP streams (both local and public) — same delay. Checking network logs: the delay occurs before any actual RTSP handshake (DESCRIBE/SETUP), suggesting the system is waiting for something network-related. Why this is critical We cannot instruct our users to turn off Local Network access, because the app also needs this permission for legitimate features (e.g., discovering cameras on the local network). Disabling it permanently is not a viable solution. Request We kindly ask for your guidance: Is there a recommended way to configure the app or the VLC instance to avoid this delay while keeping Local Network permission enabled? Could this be a bug in the permission-handling layer that causes unnecessary timeouts? Are there any entitlements, plist keys, or runtime flags we should use to optimise network access in this scenario? We are happy to provide detailed logs, a sample project, or any other information that could help identify and resolve this issue. Environment iOS: 16.0+ Device: Physical (all) VLCKit: 3.7.3 (integrated via CocoaPods) Xcode: 26.5 Thank you for your time. We look forward to your response.

We are using the NEHotspotConfigurationManager to programmatically connect to a specific Wi-Fi network for a limited period of time. From iOS 26, this now triggers a Passwords prompt asking the user if they want to save the Wi-Fi settings in the Passwords app. There are two problems with this:- We are temporarily connecting for a specific purpose and this network is not intended for the user to connect to again The prompt even appears if the credentials are incorrect and the Wi-Fi network cannot be joined While I can see some benefit to this dialog for a user connecting to a new network, it should not be displayed when programmatically connecting, or at least there should be the ability to disable it. Secondly, it seems like an obvious bug that the dialog is shown before the Wi-Fi connection successfully connects - why offer the user to store invalid credentials?

I have a sandboxed Mac App Store app that uses Apple’s MultipeerConnectivity framework for a local peer-to-peer “mesh” feature. The app advertises itself as a nearby peer and accepts inbound invitations from other nearby devices so users can do local collaboration, chat, shared workspace sync, and multiplayer game sessions. This is local peer-to-peer only; the app is not running a public web server, FTP server, or similar service. When I remove the App Sandbox Incoming Connections entitlement: com.apple.security.network.server nearby peer discovery / inbound connections stop working in the sandboxed Mac build. Is com.apple.security.network.server the correct entitlement for this MultipeerConnectivity use case on macOS, assuming the app clearly exposes this local peer-to-peer feature in the UI?

We would like to verify whether Apple’s Network Framework—which enables the creation of network connections to send and receive data using transport and security protocols—is FIPS 140-3 compliant.

We got a feedback from apple side for our new request PIR server responded, but the canary value is not in the dataset. "www.apple.com/url-filter-test" should be set to 1 So we have validated this using our iOS app pointing to same environment and it is blocking this URL as per expectation as well as we have validated this using below curl docker exec pir-server sh -lc 'grep -n "www.apple.com/url-filter-test" /pir/data/input.txtpb; ls -l /pir/data/input.txtpb /pir/data/url-0.bin /pir/data/url-0.params.txtpb'; curl -sS -i https://ohttp.protectuswebfilter.com/.well-known/private-token-issuer-directory | sed -n '1,40p' Please help us, how they are validating this entry is available or not

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE 2nd Gen on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

Summary We are observing that Wi-Fi Aware data transfer throughput on iPhone is heavily impacted by the device's Wi-Fi association state and by surrounding RF interference. When Wi-Fi is turned off from Control Center, Wi-Fi Aware throughput increases to roughly 2x (or higher) compared to when the device remains associated to a Wi-Fi network. We would like to confirm whether this is expected behavior or a system-level bug. Log Feedback ID: FB23454477 Environment Device: iPhone Feature under test: Wi-Fi Aware (NAN) data path transfer Steps to Reproduce Connect the iPhone to a Wi-Fi network (associate to an AP). Establish a Wi-Fi Aware (NAN) data-path session with a peer device. Start a sustained data transfer and measure the steady-state throughput. Repeat the measurement in two RF conditions: a. Clean RF environment (no other surrounding Wi-Fi/BLE devices nearby). b. Congested / high-interference RF environment. Turn Wi-Fi off from the Control Center pull-down menu (leave the peer/session as before). Repeat the same Wi-Fi Aware transfer and measure throughput again. Observed Behavior Scenario 1 — Wi-Fi connected (associated to an AP) Clean RF environment (Wi-Fi connected, no other surrounding Wi-Fi/BLE devices nearby): Wi-Fi Aware transfer throughput is approximately 20 MB/s. Congested / high-interference RF environment: Wi-Fi Aware transfer throughput drops to approximately 8 MB/s. Reference log: sysdiagnose_2026.06.28_21-05-09+0800_iPhone-OS_iPhone_23F81.tar.gz Scenario 2 — Wi-Fi turned off via Control Center After turning Wi-Fi off from the Control Center pull-down menu, the Wi-Fi Aware transfer throughput increases to 2x or higher compared to Scenario 1. Reference log: sysdiagnose_2026.06.28_21-15-00+0800_iPhone-OS_iPhone_23F81.tar.gz Expected Behavior Wi-Fi Aware throughput should not be significantly constrained by the device's Wi-Fi association state. We expect comparable Wi-Fi Aware performance regardless of whether the device is associated to a Wi-Fi network, since disabling Wi-Fi should not be required to achieve full Wi-Fi Aware data-path throughput. Questions for Apple Is the throughput reduction while associated to a Wi-Fi network expected behavior (e.g., due to time-sharing/channel scheduling between the infrastructure connection and the Wi-Fi Aware data path)? If this is by design, are there recommended APIs, configurations, or best practices to maintain higher Wi-Fi Aware throughput while the device remains connected to Wi-Fi? If this is not expected, we believe this is a system-level bug and would appreciate guidance on a fix or workaround.

'm building a peer-to-peer mesh messaging app using MultipeerConnectivity. The app implements TTL-bounded flooding relay so messages can traverse multiple hops across devices that aren't directly connected to each other. The core limitation I'm hitting: MPC stops browsing and advertising when the app is backgrounded, which means a node can no longer relay messages for the rest of the mesh. For the mesh to be useful in practice, nodes need to stay active as relays even when users switch to other apps. I'm aware of the standard options: . Background task extension (beginBackgroundTask) — only buys ~30 seconds, not a real solution . Push notifications (APNs) — requires a server, defeats the goal of a fully offline/local mesh . CoreBluetooth with state preservation/restoration — genuine background capability, but essentially a full rewrite of the transport layer, and BLE throughput (~100–250 kbps) would hurt larger payloads Before committing to a CoreBluetooth rewrite, I want to make sure I'm not missing anything. specifically questions are: Is there any way to keep an MCNearbyServiceAdvertiser or MCNearbyServiceBrowser running in the background that I'm not aware of? Does MCSession maintain existing connections long enough in the background to be useful for relay (i.e., does it survive past the background task expiry)? Is Network.framework's local network discovery (NWBrowser with Bonjour) any more background-friendly than MPC's browser/advertiser? • Has anyone successfully implemented a hybrid approach — CoreBluetooth for background discovery/signaling + a higher-bandwidth channel (WiFi Direct or Network.framework TCP) negotiated when foregrounded? • Are there any entitlements or capabilities (e.g., AccessorySetupKit, NEAppProxyProvider, or anything in the networking extension family) that could help here that aren't commonly discussed? The relay/routing layer, E2EE, and message dedup all sit above the transport and are transport-agnostic, so the rewrite scope is limited to the discovery and session management layer — but it's still significant. Any experience with this pattern would be very helpful.

(Also submitted as FB23072541) iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode. Users report that oddly, having an active VPN on the device works around this bug.

Hi, Our project is a MacOS SwiftUI GUI application that bundles a 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. The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. We have no issues with XPC or the system network extension during normal usage, nor when the application is installed on a user's device for the first time. The problem only arises when the user upgrades the application. I have experienced this issue myself, as have our users. It's been reported on Apple Silicon macbooks running at least macOS 15.3.2. Much like the SimpleFirewall example (which we used as a reference), we use XPC for basic communication of state between the app and NE. These XPC connections stop working when the user installs a new version of the app, with OS logs from the process indicating that the connection is immediately invalidated. Subsequent connection attempts are also immediately invalidated. Toggling the VPN in system settings (or via the app) does not resolve the problem, nor does restarting the app, nor does deleting and reinstalling the app, nor does restarting the device. The only reliable workaround is to delete the system extension in Login Items & Extensions, under Network Extensions. No device restart is necessary to garbage collect the old extension - once the extension is reapproved by the user, the XPC issue resolves itself. This would be an acceptable workaround were it possible to automate the deleting of the system extension, but that appears deliberately not possible, and requiring our users to do this each time they update is unreasonable. When the upgraded app is opened for the first time, the OSSystemExtensionRequest request is sent, and the outcome is that the previously installed system network extension is replaced, as both the CFBundleVersion and CFBundleShortVersionString differ. When this issue is encountered, the output of systemextensionsctl list shows the later version is installed and activated. I've been able to reproduce this bug on my personal laptop, with SIP on and systemextensionsctl developer off, but on my work laptop with SIP off and systemextensionsctl developer on (where the network extension is replaced on each activation request, instead of only when the version strings differ), I do not encounter this issue, which leads me to believe it has something to do with the notarization process. We notarize the pkg using xcrun notarytool, and then staple to the pkg. This is actually the same issue described in: https://developer.apple.com/forums/thread/711713 https://developer.apple.com/forums/thread/667597 https://developer.apple.com/forums/thread/742992 https://developer.apple.com/forums/thread/728063 but it's been a while since any of these threads were updated, and we've made attempts to address it off the suggestions in the threads to no avail. Those suggestions are: Switching to a .pkg installer from a .dmg As part of the .pkg preinstall, doing all of the following: Stopping the VPN (scutil --nc stop), shutting down the app (using osascript 'quit app id'), and deleting the app (which claims to delete the network extension, but not the approval in Login Items & Extensions remains??), by running rm -rf on the bundle in /Applications As part of the .pkg postinstall: Forcing macOS to ingest the App bundle's notarization ticket using spctl --assess. Ensuring NSXPCListener.resume() is called after autoreleasepool { NEProvider.startSystemExtensionMode() } (mentioned in a forum thread above as a fix, did not help.) One thing I'm particularly interested in is the outcome of this feedback assistant ticket, as I can't view it: FB11086599. It was shared on this forum in the first thread above, and supposedly describes the same issue. I almost find it hard to believe that this issue has been around for this many years without a workaround (there's system network extension apps out there that appear to work fine when updating, are they not using XPC?), so I wonder if there's a fix described in that FB ticket. Since I can't view that above feedback ticket, I've created my own: FB17032197

Problem description Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments. We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested. Out of the many issues our main app exhibits, the test app showcases some: The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access. The app shows a different Local Network Usage Description than in the project's plist. Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off. We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings. Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior? Related material Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement. Local Network FAQ Technote TN3179 Steps to Reproduce Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested. On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1). We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The alert shows a different Local Network Usage Description than the one we set in our project's plist. The app properly shows packets are received from the console on our LAN. We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed. We then reboot the machine. After reboot, the same list does not show the app anymore. We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received. After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine. We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version. The updated version also asks for Local Network access, this time with proper Usage Description. A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app. We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off. We toggle on one of the app, all of them toggle on. All 3 versions have local network access.

Description of the Issue: We are experiencing intermittent, severe latency spikes during cellular data transmission (specifically with MQTT Publish) on iPhone 17 devices. Through internal testing and cross-referencing with similar user reports online, we suspect this is caused by an aggressive power-saving or sleep mechanism in the cellular modem/iOS network stack when traffic is sporadic or low-frequency. Steps to Reproduce / Observations: Establish an MQTT connection over a cellular network (5G/LTE) on an iPhone 17. Publish messages at irregular or low-frequency intervals (e.g., sporadic IoT data transmission). Result: Severe latency spikes occur intermittently during transmission. Diagnostic Findings & Documented Workarounds: Workaround 1 (Constant Traffic): If we connect a secondary device (e.g., a PC) to the iPhone 17's Personal Hotspot and run a continuous background ping (with a 10ms interval), the MQTT latency spikes disappear completely. This high-frequency traffic prevents the device/modem from dropping into power-save mode. Workaround 2 (VPN Tunnel): Utilizing a VPN profile (such as Cloudflare's 1.1.1.1 app) significantly mitigates the issue. We suspect this is due to either the VPN's background keep-alive packets maintaining the active state of the modem, or iOS applying a less aggressive power-saving policy to active VPN interfaces. System Environment: Device: iPhone 17 series OS: iOS 19 (or specify your current version) Network: Cellular (5G/LTE) Questions Regarding Temporary Workarounds & Mitigations: To unblock our current development and ensure a reliable user experience before an official OS-level fix is deployed, we would highly appreciate Apple's technical guidance on the following questions: Recommended Keep-Alive Mechanism: Since higher frequency traffic effectively prevents the modem from entering power-save mode, does iOS have a recommended, power-efficient way for an application to maintain an active cellular network state (e.g., recommended TCP/MQTT keep-alive intervals or NWPathEvaluator configurations) without being suspended or penalized by the system? Network Optimization APIs: Are there specific Network Framework APIs (Network.framework) or socket configuration flags (such as Multipath TCP, or Quality of Service (QoS) flags like Background vs Default) that can signal to the iOS kernel to apply a less aggressive power-saving policy on the active cellular interface? Background Execution Policy: For IoT applications that need to publish MQTT data seamlessly while running in the background, what is the best practice to prevent the cellular link from dropping into deep sleep mode? We would appreciate it if the Apple Network/CoreOS engineering team could look into this cellular power management behavior. Thank you for your support.

I have a MultipeerConnectivity-based app where a view controller is opened for a specific connected peer. When data arrives for that peer, my networking manager posts a Notification whose userInfo carries the sender's MCPeerID, and the view controller filters updates like this: guard let incomingPeerID = userInfo["peerID"] as? MCPeerID, incomingPeerID == self.peerID else { return } // apply update…

My app is sandboxed and for one feature listens for an incoming connection on a user selected port. When the firewall is enabled and block incoming (all, this app, or signed apps) is enabled, I want to be able to not offer this feature with a brief explanation. I tried using /usr/libexec/ApplicationFirewall/socketfilterfw but that fails when used in a sandboxed app. I have an XPC module, which is also sandboxed, and the call fails there as well. If I remove the sandbox from the XPC then the call succeeds but then is unable to communicate with the main app. Is there an API to determine if the firewall is enabled and all connections blocked? I've submitted a Feedback request (FB23378402) as well.

I'm building a gambling addiction recovery app for macOS that uses NEFilterDataProvider to block 208,000+ gambling domains system-wide. The app is already live on the iOS App Store under the same developer account. I need the restricted entitlement com.apple.developer.network-extension.content-filter to distribute via the Mac App Store. I submitted a request through Developer Support > Development and Technical Information > Rights/Entitlements (case #102914968660) on June 14th — 9 days ago with no response yet. My questions: Is this the correct channel for requesting this entitlement for Mac App Store distribution? Has anyone successfully obtained this entitlement? What channel/process worked for you? Is there a typical turnaround time I should expect? Any guidance appreciated. Thanks

I'm building a Wi-Fi captive portal (web page) that needs the camera to scan a boarding-pass barcode. Inside the iOS Captive Network Assistant (the sign-in pop-up that appears when you join Wi-Fi): getUserMedia() (live camera) doesn't work, and <input type="file" capture="environment"> opens only the photo library, not the camera. The same page works fine in full Safari on the same iPhone. Is camera access intentionally blocked in the CNA, or is there a supported way to use it? Has anyone gotten the camera working inside the captive portal on iOS? Thanks!

Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?

macOS allows you to directly distribute a Network Extension using Developer ID signing, but with an important wrinkle. This post explains that wrinkle, its affect on Xcode, and how you get around it. If you have questions or comments, start a new thread here on the forums. Put it in the App & System Services > Networking 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" Exporting a Developer ID Network Extension macOS supports a variety of Network Extension (NE) provider types. Starting with macOS 10.15, it’s possible to distribute an app containing NE providers directly, using Developer ID signing. See TN3134 Network Extension provider deployment for the full list of supported provider types. For your NE provider to work when distributed directly, it must: Be packaged as a system extension. Use Developer ID specific entitlements This post is focused on that second point, because it’s a common source of confusion. Note If you’re currently shipping an app extension and you want to move to a system extension, see Network Extension Provider Packaging. This post assumes that you’re building your app with Xcode; if you’re building your app outside of Xcode, you’ll have to adapt these steps to your build system. Entitlement Matters A Network Extension system extension and its container app must be signed with the Network Extension entitlement (com.apple.developer.networking.networkextension). That entitlement is an array, with a variety of different element values based on the provider type. For example, a standard NE content filter provider must include the content-filter-provider value. There are two groups of these values: the standard ones and the ones with the -systemextension suffix. During development and for App Store distribution, use the appropriate standard value. For direct distribution using Developer ID, use the corresponding value with the -systemextension suffix. For example, a Developer ID signed NE content filter must use content-filter-provider-systemextension instead of content-filter-provider. Xcode Issues IMPORTANT Xcode 27.0b1 is reported to have fixed this issue, meaning that it should now be possible to export a Developer ID signed app with an Network Extension system extension from the Xcode organiser. I did some basic tests of that here in my office and it seems to work. Yay! So the following is only relevant if you have to build your app with an earlier version of Xcode. Xcode 26 and earlier are not aware of this requirement. If you build your NE provider container app using Xcode, you might expect to export it for direct distribution using the Direct Distribution workflow in the Xcode organiser. This does not work on older versions of Xcode (r. 108838909). To get around this, manually export your app from your Xcode archive. Before attempting that, there are a few things to confirm: By default Xcode’s Signing & Capabilities editor uses the standard values for the NE entitlement. Leave them that way. During day-to-day development it’s best to use an Apple Development signing identity [1], and the standard values work with that. Continue to use Build > Archive [2] to create an Xcode archive for your product. The steps below replace the Direct Distribution workflow, and they assume you’re starting with an Xcode archive. Note For hints and tips about how to bring up and then debug an NE provider, see Debugging a Network Extension Provider. [1] Don’t use Developer ID for day-to-day development; see The Care and Feeding of Developer ID for more on that topic. [2] Or, if you’re automating this, the archive action in xcodebuild. Assemble Your Assets Imagine you’re working on a content filter for the Mac called WaffleFilter. You’ve used Xcode to build the app into an Xcode archive: % ls "WaffleFilter.xcarchive/Products/Applications" WaffleFilter.app That app is development signed: % codesign -d -vvv "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" … Authority=Apple Development: … … IMPORTANT The steps in this section are based on the much more comprehensive instructions in Creating distribution-signed code for macOS. If anything is unclear, read that documentation for clarification. To re-sign this app for direct distribution you’ll need three things: A Developer ID application signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. A Developer ID provisioning profile for the app. In this example I’ve called this WaffleFilter_Dev_ID.provisionprofile. A Developer ID provisioning profile for the system extension. In this example I’ve named this WaffleFilter_WFProvider_DevID.provisionprofile. If you’re not sure how to create these things, see Developer Account Help. Re-sign the App To start, make a copy of the app: % ditto "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" "WaffleFilter.app" Dump the entitlements of the app and its embedded system extension: % codesign -d --entitlements "WaffleFilter.entitlements" --xml "WaffleFilter.app" % codesign -d --entitlements "WaffleFilter_WFProvider.entitlements" --xml "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" And reformat them to make them more readable: % plutil -convert xml1 "WaffleFilter.entitlements" % plutil -convert xml1 "WaffleFilter_WFProvider.entitlements" Now edit these files to add the -systemextension suffix. The result will look something like this: % cat "WaffleFilter.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> % cat "WaffleFilter_WFProvider.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> Before you re-sign with these entitlements, replace the embedded provisioning profiles with their Developer ID variants: % cp "WaffleFilter_Dev_ID.provisionprofile" "WaffleFilter.app/Contents/embedded.provisionprofile" % cp "WaffleFilter_WFProvider_DevID.provisionprofile" "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension/Contents/embedded.provisionprofile" Now re-sign the app and the system extension with their new entitlements, from the inside out: % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter_WFProvider.entitlements" --timestamp -o runtime "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension: replacing existing signature % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter.entitlements" --timestamp -o runtime "WaffleFilter.app" WaffleFilter.app: replacing existing signature If you have multiple Developer ID Application signing identities, you’ll need to replace Developer ID Application with the name of the specific identity you want to use. IMPORTANT If your app contains other code items, like frameworks or an app extension, re-sign those as well. For advice on how to manually re-sign a more complex app, see Creating distribution-signed code for macOS. And you’re done! Manually Notarise Xcode’s Direct Distribution workflow also deals with notarisation. As you’re not using that workflow, manually notarise your app. For advice on how to do that, see Customizing the notarization workflow. You should also look at Packaging Mac Software for Distribution, which has a bunch of general info about packaging Mac apps. Revision History 2026-06-22 Xcode 27.0b1 is reported to have fixed this issue. Added information about that. Made other minor editorial changes. 2023-09-21 First posted.

I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?