We are building a VPN using NEPacketTunnelProvider where the intent is to route HTTP/S traffic through a local proxy server, while non-HTTP/S traffic flows directly to the network without being tunnelled at the IP layer. The configuration claims no included IP routes — it relies entirely on NEProxySettings to intercept HTTP/S traffic via the URL loading layer. private func configureIPSettings(_ settings: NEPacketTunnelNetworkSettings) { settings.ipv4Settings = NEIPv4Settings( addresses: ["192.168.1.1"], subnetMasks: ["255.255.255.255"] ) // No includedRoutes set — no IP traffic enters the tunnel } private func configureProxySettings(_ settings: NEPacketTunnelNetworkSettings) { let proxySettings = NEProxySettings() proxySettings.httpEnabled = true proxySettings.httpServer = NEProxyServer(address: "127.0.0.1", port: 9000) proxySettings.httpsEnabled = true proxySettings.httpsServer = NEProxyServer(address: "127.0.0.1", port: 9000) proxySettings.matchDomains = [""] settings.proxySettings = proxySettings } When matchDomains is nil or not set, HTTP/S traffic does not reach the local proxy in this configuration. Setting matchDomains = [""] makes it work correctly. The matchDomains documentation states: "If the destination host name of a HTTP connection shares a suffix with one of these strings then the proxy settings will be used." An empty string is a suffix of every string, so [""] matching all hostnames follows from that definition. But this isn't explicitly documented. Questions: Is matchDomains = [""] a supported and stable way to apply proxy settings to all HTTP/S traffic when no IP routes are claimed, or is this an unintended side-effect? Why does matchDomains = nil not apply the proxy globally in this configuration? The documentation doesn't describe its behaviour relative to IP routing. NEDNSSettings.matchDomains explicitly documents an empty string as matching all domains — is the same semantics intended for NEProxySettings.matchDomains?

I've been able to run this sample project with the PIRServer. But the urls are still not blocked. https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url https://github.com/apple/pir-service-example I got this on the log Received filter status change: <FilterStatus: 'running'>

When using the official Wi-Fi Aware demo app on iOS, with the iOS device configured as a NAN Subscriber, after successfully establishing a peer-to-peer connection with another device via Wi-Fi Aware (NAN), the network path object nwPath.availableInterfaces does not list the nan0 virtual network interface. The nan0 interface is the dedicated NAN (Neighbor Aware Networking) interface used for Wi-Fi Aware data communication. Its absence from availableInterfaces prevents the app from correctly identifying/using the NAN data path, breaking expected Wi-Fi Aware data transmission logic. log: iOS works as subscriber: [onPathUpdate] newPath.availableInterfaces: ["en0"] iOS works as publisher: [onPathUpdate] newPath.availableInterfaces: ["nan0"]

Hi, I see an interaction issue between a DNS Proxy system extension and MDM on macOS: after some time the device stops processing MDM commands until reboot, while DNS filtering continues to work. Environment: macOS: 15.x / 26.x (reproduced on multiple minor versions) App: /Applications/MyMacProxy.app System extension: NEDNSProxyProvider as system extension Bundle id: com.company.agent.MyMacProxy.dnsProxy Deployment: MDM (SimpleMDM) DNS proxy config via com.apple.dnsProxy.managed Devices: supervised Macs Steps to reproduce: Enrol Mac into MDM. Install MyMacProxy app + DNS proxy system extension via pkg and apply com.apple.dnsProxy.managed profile. DNS proxy starts, DNS is filtered correctly, user network works normally. After some hours, try to manage the device from MDM: push a new configuration profile, remove an existing profile, or install / remove an app. 5.MDM server shows commands as pending / not completed. On the Mac, DNS is still filtered via our DNS proxy, and general network access (Safari etc.) continues to work. After reboot, pending MDM commands are processed and we can remove the app, profile and system extension normally. This is reproducible on our test machines. What I see on the Mac in the “stuck” state apsd is running: sudo launchctl print system/com.apple.apsd # job state = running com.apple.mdmclient.daemon exists as a job but is not running: sudo launchctl print system/com.apple.mdmclient.daemon Abbreviated output: system/com.apple.mdmclient.daemon = { ... state = not running job state = exited runs = 5 last exit code = 0 ... } So the MDM client daemon has exited cleanly (exit code 0) and is currently not running; its APS endpoints are configured. Our DNS proxy system extension is still processing flows: we see continuous logging from our NEDNSProxyProvider, and DNS filtering is clearly active (requests go through our upstream). systemextensionsctl list still shows our DNS proxy system extension as active. From the user’s perspective, everything works (with filtered DNS). From the MDM server’s perspective, commands stay pending until the next reboot. After reboot, MDM behaviour is normal again. Uninstall / cleanup (current approach, simplified) We currently use an MDM‑delivered shell script that: disables our DNS proxy configuration for the console user by editing ~/Library/Preferences/com.apple.networkextension.plist and setting Enabled = false for our DNSProxyConfigurations entries; flushes DNS cache and restarts mDNSResponder; unloads our LaunchDaemon / LaunchAgent for the host app; kills the system extension process using pgrep -f "com.company.agent.MyMacProxy.dnsProxy" | xargs kill -9; removes the extension binary from /Library/SystemExtensions/.../com.company.agent.MyMacProxy.dnsProxy.systemextension; removes /Applications/MyMacProxy.app and related support files. We currently do not call systemextensionsctl uninstall <TEAMID> com.company.agent.MyMacProxy.dnsProxy from MDM, mainly because of SIP and because we understand that fully silent system extension uninstall is constrained. The MDM responsiveness issue, however, can appear even if we don’t run this aggressive uninstall script and just let the extension run for some hours. Questions Is it expected that a DNS Proxy system extension (managed via com.apple.dnsProxy.managed) can leave a device in a state where: apsd is running, com.apple.mdmclient.daemon is not running (last exit code 0), DNS proxy continues to filter traffic, but MDM commands remain pending until reboot? Are there known best practices or pitfalls when combining: DNS Proxy system extensions (NEDNSProxyProvider), MDM‑distributed com.apple.dnsProxy.managed profiles, and MDM app / profile management on recent macOS versions? For uninstall in an MDM environment, what pattern do you recommend? For example, is it better to: disable / remove the DNS proxy profile, stop the NE configuration via NEDNSProxyManager from the app, avoid killing the system extension or removing files from /Library/SystemExtensions immediately, and instead require a reboot for full removal? I can provide a sysdiagnose and unified logs (including nesessionmanager, mdmclient and our logs) from an affected machine if that would be helpful.

We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine). The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey. Forums that we referenced in the past: https://developer.apple.com/forums/thread/663858 TN3179: Understanding local network privacy | Apple Developer Documentation I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.

Hi, I’m looking for clarification on TN3134: Network Extension provider deployment, specifically iOS deployment requirements for: packet tunnel provider DNS proxy provider From the documentation: Packet Tunnel Provider App extension (min iOS 9.0): per-app mode requires a managed device DNS Proxy Provider App extension (min iOS 11.0): supervised devices only App extension (min iOS 11.0): per-app mode requires managed devices Issue I implemented a DNS proxy using NEDNSProxyManager. Works as expected in debug builds on a local device Fails to configure when distributed via TestFlight Console Output (TestFlight build) error 10:05:39.872258-0500 nehelper The production version of *** is not allowed to create DNS proxy configurations. Use MDM to create DNS Proxy configurations for the production version of ***. Question Is it possible to distribute a DNS proxy provider for use on non-MDM / non-supervised devices? If not: Is the limitation strictly enforced at distribution/runtime? Is a packet tunnel provider the only viable alternative for App Store distribution? There is a lot of different VPN apps on the App Store that appear to work out of the box without MDM or supervision, which suggests they are using a different deployment model. Thank you for any clarification or guidance!

I'm building a macOS network monitor using NEFilterDataProvider as a system extension, distributed with Developer ID signing. On macOS 26.3 (Tahoe), sysextd consistently rejects the activation request with "no policy, cannot allow apps outside /Applications" — despite the app being in /Applications and passing every verification check. I'm aware of the known Xcode NE signing bug (r. 108838909) and have followed the manual signing process from Exporting a Developer ID Network Extension. I've also tried both xcodebuild build and xcodebuild archive workflows — identical failure. Environment macOS 26.3 (25D125), SIP enabled Xcode 26.3 (17C529) Hardware Apple M2 Pro Certificate Developer ID Application (issued Jan 30, 2026 — 27 days old) MDM/Profiles None installed Signing & Verification (all pass) $ spctl -a -vv /Applications/Chakshu.app /Applications/Chakshu.app: accepted source=Notarized Developer ID origin=Developer ID Application: ROBIN SHARMA (R65679C4F3) $ codesign --verify --deep --strict -vv /Applications/Chakshu.app /Applications/Chakshu.app: valid on disk /Applications/Chakshu.app: satisfies its Designated Requirement $ xcrun stapler validate /Applications/Chakshu.app The validate action worked! App signing: Authority=Developer ID Application: ROBIN SHARMA (R65679C4F3) Authority=Developer ID Certification Authority Authority=Apple Root CA TeamIdentifier=R65679C4F3 Runtime Version=26.2.0 Notarization Ticket=stapled App entitlements: com.apple.application-identifier = R65679C4F3.dev.indrasvat.chakshu com.apple.developer.team-identifier = R65679C4F3 com.apple.developer.system-extension.install = true com.apple.developer.networking.networkextension = [content-filter-provider-systemextension] keychain-access-groups = [R65679C4F3.*] Extension signing: Same Developer ID authority, same team, same timestamp. Extension entitlements match (minus system-extension.install). Developer ID provisioning profiles are embedded in both app and extension. What sysextd logs Captured Feb 26, 2026 from log stream --predicate 'process == "sysextd"': sysextd [com.apple.sx:XPC] client activation request for dev.indrasvat.chakshu.filter sysextd attempting to realize extension with identifier dev.indrasvat.chakshu.filter sysextd (Security) SecKeyVerifySignature ← pass (×2) sysextd (Security) SecTrustEvaluateIfNecessary ← pass (×2) sysextd [com.apple.xpc:connection] activating connection: name=com.apple.CodeSigningHelper sysextd [com.apple.xpc:connection] invalidated after the last release sysextd no policy, cannot allow apps outside /Applications sysextd [com.apple.sx:XPC] client connection invalidated Signature and trust evaluation pass. CodeSigningHelper completes. Then the policy check fails. The app receives OSSystemExtensionError code 4 (extensionNotFound). What I've tried and ruled out Build process: Approach Result xcodebuild build -configuration Release + manual re-sign Same failure xcodebuild archive + export from archive + manual re-sign (per thread/737894) Same failure Minimal hand-crafted Xcode project (no xcodegen, trivial code) Same failure Both workflows follow Quinn's process exactly: build with Apple Development → copy app → embed Developer ID provisioning profiles → re-sign inside-out (extension first, then app) with -systemextension suffix entitlements → notarize → staple → install to /Applications. System-level checks: Rebooting — no change Killing sysextd — no change Removing com.apple.quarantine xattr — no change chown root:wheel on app bundle — no change lsregister -r (reset Launch Services) — no change Waiting 27 days for certificate propagation — no change Reinstalling via Finder drag-to-Applications — no change No MDM or configuration profiles installed /Library/SystemExtensions/db.plist shows extensionPolicies: [] (empty) Key observation Pre-existing network extensions activated before macOS 26 work fine on this machine. For example, Tailscale's NEPacketTunnelProvider shows state: activated_enabled in the system extensions database — it was activated on a prior macOS version and is still running. Only new system extension activations fail. I've seen similar Tahoe-specific reports from LuLu (same NEFilterDataProvider type, Developer ID distribution): LuLu #825 LuLu #831 Questions Is this a known regression in macOS 26's sysextd policy evaluation for new Developer ID system extension activations? sysextd's policy check fails after all signature and trust evaluation succeeds. Is there a separate trust/policy path that sysextd consults beyond what spctl, codesign, and CodeSigningHelper verify? Is there anything else I should be checking? I have a sysdiagnose captured immediately after the failure, a minimal reproducer project, and full raw sysextd logs available on request.

Summary I'm implementing NEURLFilter with the com.apple.developer.networking.networkextension.url-filter-provider entitlement for a system-wide URL filtering feature. The feature works perfectly in development-signed builds (connecting successfully to my PIR server over extended testing) but every production-signed build fails before any network call is made. NEURLFilterManager reports .serverSetupIncomplete (code 9). After installing the NetworkExtension debug profile, the unredacted com.apple.CipherML logs reveal the cause: no privacy proxy is provisioned for this bundle identifier, and the connection is configured proxy fail closed. Environment iOS 26 Entitlement: com.apple.developer.networking.networkextension.url-filter-provider Extension point: com.apple.networkextension.url-filter-control PIR server configured via NEURLFilterManager.setConfiguration(...) Privacy Pass issuer configured Dev-signed builds: working correctly, connecting to the PIR server Production-signed builds (both TestFlight and distribution): failing identically The Error Chain Surfaced to the app via NEURLFilterManager.lastDisconnectError: NEURLFilterManager.Error.serverSetupIncomplete (code 9) ← NEAgentURLFilterErrorDomain Code 3 ← com.apple.CipherML Code 1100 "Unable to query status" ← com.apple.CipherML Code 1800 (error details were logged and redacted) After installing the VPN (NetworkExtension) debug profile, the unredacted com.apple.CipherML subsystem shows: 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://<my-pir-server>/config, NSUnderlyingError = { Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" }, _NSURLErrorPrivacyProxyFailureKey = true, NSLocalizedDescription = "The Internet connection appears to be offline." } The critical diagnostic line in the com.apple.network subsystem is: nw_endpoint_proxy_handler_should_use_proxy Proxies not present, but required to fail closed And the connection setup shows the proxy fail closed flag is mandatory for the connection: [C... ... Hostname#...:443 quic, bundle id: <my-bundle-id>, attribution: developer, using ephemeral configuration, context: NWURLSession (sensitive), proxy fail closed] start The network path itself is healthy (Wi-Fi good, DNS resolves correctly), but the connection is explicitly configured to fail closed if no proxy is present, and no proxy is provisioned for this bundle identifier. The entire failure happens in approximately 18 ms, far too fast for any network round-trip, confirming no traffic ever leaves the device. What I've Verified The entitlement is present in the distribution build The NEURLFilterControlProvider extension loads and returns a valid Bloom filter prefilter (with a tag that round-trips correctly between extension and framework) NEURLFilterManager.setConfiguration(pirServerURL:pirPrivacyPassIssuerURL:pirAuthenticationToken:controlProviderBundleIdentifier:) accepts all four parameters without error Development-signed builds of the same bundle identifier connect successfully to the same PIR server On production-signed builds, zero requests reach the PIR server — failure is purely client-side, before any network activity The Question How does the OHTTP privacy proxy get provisioned for a bundle identifier so that production builds can successfully use NEURLFilter? Specifically: Is there a Capability Request form I need to submit for url-filter-provider? I cannot find one in the Capability Requests section of my developer portal. Should I be running my own OHTTP gateway (for example using swift-nio-oblivious-http), and if so, does Apple then need to provision routing from their OHTTP relay to my gateway URL? Is the OHTTP relay path meant to be automatic once the entitlement is active, and if so, is there a specific activation step I'm missing? Is there any way to verify the current provisioning state for a specific bundle identifier from the developer portal? I can provide the full sysdiagnose and unredacted bundle/server details privately to an Apple engineer if that would help diagnose. I'd prefer to keep them out of a public post. Thanks!

We observed intermittent failures when iOS devices repeatedly attempt to connect to an AP via NEHotspotConfiguration. When sniffing the packets, most failures occur before the WPA 4‑way handshake, with a smaller number happening during the handshake itself. SSID and Password were verified to be correct. Root Causes Association fails before handshake (primary issue) iOS often fails at the association phase (Apple80211AssociateAsync errors such as -3905 / -3940). These attempts never reach the WPA 4‑way handshake. iOS auto‑join suppression amplifies the problem After a single association failure, iOS marks the network as failed and blocks retry attempts. Subsequent attempts are rejected by policy (Already failed to auto-join known network profile) without new radio activity. This makes one real failure appear as many repeated failures. 4‑Way handshake failures (secondary) In some cases, association succeeds but the connection drops during WPA setup (Join Failure(6)). The error (if received, not always) is Internal Error - 8. Could we inquire on what might be the best steps to resolve this issue?

Hello! I have an accessory, which is paired already with an iPhone, and am attempting to upgrade its SSID permission to Wi-Fi Aware. In ideal conditions, it works perfectly. However, if I dismiss the picker at the time of pin-code entry, I am unable to re-initialize an upgrade authorization picker. Even though the authorization is not completed a WAPairedDeviceID is assigned to the object of 18446744073709551615. Any subsequent attempts to start the picker up again spits out when treated as a failure serves: [ERROR] updateAuthorization error=Error Domain=ASErrorDomain Code=450 "No new updates detected from existing accessory descriptor." Attempting with a mutated descriptor serves: [ERROR] updateAuthorization error=Error Domain=ASErrorDomain Code=450 "Accessory cannot be upgraded with given descriptor." If I try using failAuthorization i get a 550 "Invalid State" error and furthermore if I try finishAuthorization to attempt to clear the descriptor/paired device ID it fails to clear it. If I could be pointed to the intended behavior on how to handle this, or this can be acknowledged as a bug, that would be incredibly appreciated. Thank you!

I'm developing a lighting control app for iOS that receives Art-Net (UDP port 6454) and sACN (UDP port 5568) packets from a lighting console and relays commands to BLE wristbands with LEDs. This is used in live event production — the participant locks their phone while in a show and expects lighting control to continue uninterrupted. The problem UDP receive stops reliably ~30 seconds after the screen locks. I understand this is by design - iOS suspends apps in the background. However, I'm trying to understand if any supported path exists for this use case. What I've already tried UIRequiresPersistentWiFi = true - helps with Wi-Fi association but doesn't prevent app suspension Silent AVAudioEngine loop with UIBackgroundModes: audio - keeps the app alive, works in testing, but risks App Store rejection and feels like an abuse of the audio background mode NWListener (Network framework) on the UDP port - same suspension behaviour Socket rebind on applicationWillEnterForeground - recovers after resume but doesn't prevent dropout What I'm asking Is there any supported background mode or entitlement for sustained UDP receive in a professional/enterprise context? (Similar to how VoIP apps get the voip background mode for sustained network activity.) Is the silent audio workaround considered acceptable for App Store distribution in a professional tools context, or will it be rejected? Is NEAppProxyProvider or another Network Extension a viable path, and if so does it require a special entitlement? Test project I have a minimal Xcode project (~130 lines) demonstrating the issue — NWListener on port 6454, packet counter, staleness timer, and silent audio toggle. I can share the test code. STEPS TO REPRODUCE In Xcode (one-time setup): Select the UDPBackgroundTest target → Signing & Capabilities → set your Team Plug in your iPhone → select it as the run destination Build & run — confirm packets appear on screen when you run 'send_test_udp.py' Lock the phone and observe the dropout Test: Open the app and run 'python3 send_test_udp.py 192.168.0.XXX' The app counts up the packages, they match the python output. 1 packet per second. lock screen & and wait 10 seconds unlock phone an see the numbers are 10 packets off

Hello. There is a condition that two requests are executed from an iPhone to the application, and the same session must be maintained throughout the execution of these two requests. The application resides within AWS. AWS ALB offers a Sticky Session feature to maintain sessions; to use this feature, Sticky Session Cookies are utilized, and it seems that the iPhone must be able to set the cookie. I would like to know if the iPhone can accept cookies for Sticky Sessions. Has anyone experienced a similar situation before?

I’m building an app on macOS 26.4 with Xcode 26.4. When I build and run my app it started prompting me for network access, which it didn’t do before with Xcode 26. It did that repeatedly, and I had been approving the prompts and the app had been working. Now the app’s network features are not working, and I assume its because its being blocked by macOS, even though I accepted the network requests each time. In System Settings - Privacy and Security - Local Network, the app has many repeated entries, like 20, and all of them are turned on.

We have been testing several domains (including xiaohongshu.com, bilibili.com, douyin.com, and tls13.xargs.org) and have encountered a systemic issue related to Apple's Certificate Transparency (CT) policy enforcement on iOS 18. We would like to seek clarification from the Apple team. Observed Behavior: On iOS 18 devices where the CT log list (assetVersion) is at version ≤1006, Safari presents "This Connection Is Not Private" for the affected domains. NSURLSession returns error -1202 (NSURLErrorServerCertificateUntrusted), and SecTrust rejects the certificate chain entirely. Other domains whose certificates use 2026-series CT log servers connect normally on the same device. Key Affected User Pattern: The vast majority of affected devices are those upgraded directly from iOS 14 or iOS 15 to iOS 18, where the CT log list did not automatically update after the upgrade and remains stuck at version ≤1006. Brand-new devices and devices that have updated their CT list to version 1012 connect normally — confirmed through direct testing. This suggests the issue is not a bug in iOS 18 itself, but rather a failure to refresh the CT log list on older devices after a major OS upgrade, resulting in a low-… (truncated) Root Cause Analysis: The failing certificates embed SCTs from three CT log servers: Cloudflare Nimbus2027, Tiger2027h1, and Elephant2027h1. These servers were added to Apple's trusted CT log list between September and November 2025. Devices whose CT list is still at version ≤1006 do not include these servers, causing all SCTs to be deemed invalid and the certificate to be rejected. Questions: What triggers a CT log list update? Under what conditions does the Trusted Asset (CT log list) update on iOS devices? Is there an update mechanism independent of the system OTA? Why does upgrading from iOS 14/15 to iOS 18 appear to leave the CT list at an older version rather than refreshing it as part of the upgrade? Is Apple aware of this as a known issue? For devices that upgraded to iOS 18 from iOS 14/15 and whose CT list was not refreshed, while CAs are already using newly-trusted log servers — does Apple have an official recommendation or a fix planned? Is there a "safe use window" guidance for CAs? Does Apple communicate to CAs a recommended waiting period after a new CT log server is added to the trust list, before it should be used to issue certificates targeting iOS users? If not, are there plans to publish such guidance? CT list behavior across upgrade paths: Can Apple clarify whether devices upgrading from iOS 14/15 to iOS 18 receive a different CT list assetVersion compared to devices upgrading from iOS 16/17 or performing a clean install? Is there a patch or mechanism to ensure devices on older upgrade paths also receive timely CT list updates? Thank you for your attention. We look forward to a clear response.

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.

How do I make a basic request with URLSession? See https://stackoverflow.com/questions/30573898 for reference. Also https://developer.apple.com/documentation/ has details.

URLSession question

Hello team, We are using below example https://github.com/apple/pir-service-example as a starting point to setup PIR server for our backend, but I am not really understanding what else we need in this example to configure OHTTP gateway. Any help will be appreciated.

I'm relatively new to socket networking, and am migrating an older project from CocoaAsyncSocket to Swift's native Network. The project utilises GCDAsyncUdpSocket.enableBroadcast(_ flag: Bool), but I don't know how to replicate this in Network. How do I enable UDP Broadcast on NWConnection?

Hello, I am currently developing a headless macOS daemon (HarmonBridge) that requires extremely low-latency, high-bandwidth UDP video streaming between a Mac and a Linux host over a dedicated 2.5GbE/5GbE local network link. We are utilizing widely available Realtek RTL8156 / RTL8156B based USB 2.5G network adapters. Under macOS, these adapters default to the generic com.apple.DriverKit.AppleUserECM driver. The hardware itself natively supports Jumbo Frames (MTU 9000), but the DriverKit implementation artificially restricts the MTU cap to 1500 bytes. Because we are forced through MTU 1500, we are incurring significant performance penalties: Excessive IP fragmentation for our large UDP video payloads. Unnecessary CPU overhead due to increased hardware interrupts and header processing at 2.5Gbps speeds. For a latency-critical application like ours, reducing CPU interrupts and utilizing true hardware-level Jumbo Frames is essential. My Questions: Is there an undocumented boot-arg or network sysctl parameter that permits overriding the AppleUserECM 1500 MTU hard-limit for 2.5G USB adapters on Apple Silicon? Are there any roadmap plans from the DriverKit/Networking team to re-enable standard Jumbo Frame negotiation for RTL8156 hardware using the generic ECM driver? If the answer to both is no, does Apple grant NetworkingDriverKit Entitlements to independent developers specifically for the purpose of writing custom hardware overrides to patch missing MTU features in the default ECM stack? Because AppleUserECM effectively acts as a gatekeeper to the underlying MAC/PHY capabilities of these modern USB NICs, any guidance on achieving wire-native MTU 9000 under the current DriverKit paradigm would be hugely appreciated. Thank you!