General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post URL filter: WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension URL filters documentation Filtering traffic by URL sample code Setting up a PIR server for URL filtering sample code Using the Bloom filter tool to configure a URL filter sample code PIR Service Example open source server sample and specifically its documentation Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Apple thought it was impossible. I made it possible. No server. Just an iPhone. LUMEN-JEV OS v3.0 — On-device OS using Pyto + iCloud Drive + Obsidian Architecture: Pyto runtime = server: Persistent loop, 922 tickers scanned, 502.6 ev/s, 12ms latency, sub-2ms cache iCloud Drive = bus: Writes JEV-BUS.md every 15s, shared working directory Obsidian = OS window manager: 00-JEV-DASHBOARD-main 48 nodes live Vault: 11/11 LOCKED, Factory Complete Anchor: 572b9df5e8e1f101365f8316ba7b34da4aa54ff89a2dcdb68ed20b126e8cabed Chain: REAL-EXCHANGE-PUBLIC-WS -> 8-MODULE-DEMO -> DEMO-TERMINATED -> NO EXECUTION Feed: real-public-readonly / public_ticker_only Modules (8-MODULE-v1px): WARREN-WATCHDOG, KEEPER-BOX, NODE-MODE-SYNC, VAULT-MULT, SCOUT-SCAN, SIREN-FILTER, FOCUS-SIGNAL-20K, ORACLE-PRICE-FEED, RELAY-ROUTER, AKE-ARBITRAGE, YIELD-BACK-4, MEDUSAs: 03 DYNAMIC OBSERVER-SPACE Context: Built in 33hrs over 11 nights, day job, single dad, solo dev, on iPhone only. Pyto working directory set to iCloud Drive. No Mac backend, no CloudKit function, no external server. Why this matters for iOS: Apple's sandbox says you can't run a persistent OS-like loop with live file sync on iOS. Pyto + iCloud Drive persistence proves you can. iPhone becomes the server. Proof: 48 NODES LIVE canvas PROOF CHAIN 11/11 FLAT VIEW VAULT LOCKED Jev.py V2.6 CLEAN BUS log (checked 50/100/150/200 -> 922/922 passes) Anchor hash matches zip JEV-OS-v3.0-572b9df5-40files.zip Requesting: Guidance on showcasing this as an iOS innovation + Ask Apple office hours. X proof pinned: @Activepython007

Hello ! following up from a related thread (account transfer issue, now resolved: https://developer.apple.com/forums/thread/843546?answerId=911820022), but this is a distinct, new issue so starting fresh as suggested. The extension launches fine, XPC handshake succeeds, and PIR registration completes successfully. But the subsequent NEPIRChecker status check fails every time (retried repeatedly over several minutes, same result each time): 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=0x677037cf0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}>Config being registered (confirmed from the logs): pirServerURL = https://pir.dropbet.app/ pirPrivacyPassIssuerURL = https://pir.dropbet.app/issueBoth endpoints are live and were already validated as part of the original NEURL Filter configuration approval. I've captured a sysdiagnose from the device right when this was happening, so I have that ready to attach to a bug report if useful — just let me know and I'll file one. Any idea what CipherML error 1100/1800 typically indicates?

Hello, We are developing a macOS application with many different components that are required for our business features. We distribute the product outside the App Store and sign it with our Developer ID certificate. Rebranding an app is a rare case, but sometimes it happens. My question is: Does Apple have any guide or recommendations on how to rebrand an app properly, other than distributing a completely new product? I am asking because our application has a complex structure: UI app (MyApp1, bundle ID = com.myApp1.osx.app) Helper tool (MyApp1HelperTool, bundle ID = com.myApp1.osx.HelperTool) Privileged daemon (MyApp1Daemon, bundle ID = com.myApp1d) System Extension, Transparent Proxy (MyApp1Proxy, bundle ID = com.myApp1.osx.proxy) As you can see, the brand name is used not only in the bundle and product names, but also in the bundle IDs. At some point, I need to change the product name from MyApp1 to MyApp2. Ideally, I would also like to change the bundle IDs to match the new brand. After rebranding, end users should not see MyApp1 anywhere in the system, only MyApp2. Also, components that are already installed and approved (System Extension, proxy configuration, helper tool, etc.) should stay approved. We would like to avoid showing the approval prompts again to all our end users. I did some research and found that bundle IDs technically cannot be changed. To solve this, I would need to release a new app and implement an in-app update mechanism that updates MyApp1 to MyApp2. However, even with a new app and an in-app update mechanism, I did not find a way to avoid user prompts for approving the new extension, the proxy, and possibly the privileged helper tool. For macOS, these will be new components that require explicit user approval. MDM is not a solution for us: some of our customers use MDM, but many of them do not. We want the update to be as smooth as possible. Thank you!

In August 2026 we requested the Local Push Connectivity entitlement. On September 12 we received two emails one minute apart: the automated "Network Extension (additional values) entitlement confirmation" from developer@email.apple.com, followed by a reply from Local Push Review ("Re: Requesting Network Extension App Push Entitlement") stating the request was "approved for development and testing purposes only. If and when you have a product ready for the store, please resubmit your request and include a description of your product." We built the NEAppPushProvider, tested it on the vessel's Wi-Fi, and resubmitted through the same request page on September 15. On October 20 we received only the same automated "Network Extension (additional values) entitlement confirmation" — identical wording to September 12 — and no reply from Local Push Review. Since the same automated confirmation accompanied the development-only approval, we can't tell what the October 20 assignment means. The App ID editor shows Network Extension (additional values) either way. Is our resubmission approved for App Store distribution, or is it still pending review? Our team ID is M4S46K7L33.

Hi Apple Developer Support / community, I am seeing a URL filter startup failure only in TestFlight builds. The same code path works in development and Ad Hoc builds. App setup: Host app bundle id: com.expleo.protectus.filter.main URL filter control extension bundle id: com.expleo.protectus.filter.main.buf Extension point: com.apple.networkextension.url-filter-control Using NEURLFilterManager / NEURLFilterControlProvider on iOS 26.x App Group and network extension entitlements are configured on host + extension Observed behavior: Extension process starts successfully (pid created) Status changes to starting Then updatePrefilterWithCompletionHandler runs Immediately after, plugin transitions to stopping with error 3 System retries in a loop Key logs: Error Domain=NEAgentURLFilterErrorDomain Code=3 Failed to startFilter NEPIRChecker start block reports: Error Domain=com.apple.CipherML Code=1100 Underlying Error Domain=com.apple.CipherML Code=1800 Message says details are redacted Example sequence: NEURLFilterPlugin ... started with pid ... status changed to starting updatePrefilterWithCompletionHandler enter acceptAgentClients enter setStatus:error ... NEAgentURLFilterErrorDomain Code=3 status changed to stopping with error 3 extension disposed / teardown repeats Important detail: This failure is reproducible in TestFlight only. Same code and configuration works in development and Ad Hoc builds. What we already checked: Extension launches and is discovered correctly by neagent App/extension bundle identifiers are correct App group and network extension entitlements are present in source and archive checks We tested startup gating around local bloom/prefilter readiness We still get NEMembershipCheckerErrorDomain Code=3 with CipherML 1100/1800 in TestFlight Questions: Is NEMembershipCheckerErrorDomain Code=3 in this startup path known to indicate PIR membership/status validation failure in distribution context? Are there TestFlight-specific prerequisites or server-side requirements for PIR/CipherML path that differ from development/Ad Hoc? Is there any supported way to get non-redacted diagnostic details for CipherML 1100/1800 (beyond sysdiagnose submission)? Are there recommended fail-open/fail-closed startup patterns when PIR status is temporarily unavailable? If needed, I can provide: Full sysdiagnose timestamped bundle Exact iOS version and device model Repro steps from clean install Full log stream around NEPIRChecker and NEURLFilterPlugin transitions Thanks in advance.

Two field incidents show an _nstat_rwlock/UDP socket mutex ABBA deadlock followed by a configd watchdog panic. Raw wait-owner records and UUID-matched KDK stacks identify the same cycle in each incident's earlier configd diagnostic and later panic. Affected systems Both kernels: xnu-13432.1.9~1. Kernel UUIDs are in the attachments. Report AReport BmacOS27.0 (26A428)27.0.1 (26A434)HardwareMac16,10 / T8132Mac15,6 / T6030CloudShell PID87443906Blocked configd threadPID 341, TID 19794593PID 113, TID 309370Our NEDNSProxyProvider can capture CloudShell's DNS UDP traffic and forward it via a separate upstream socket. Provider flows and CloudShell sockets have separate lifetimes. Symptoms and reproduction During DNS UDP forwarding and flow/socket cleanup, CloudShell blocks in final socket close. configd's IPConfigurationAgentQueue blocks creating a UDP socket: a diagnostic is captured after 60 seconds without check-ins, followed by panic/restart after 180 seconds: userspace watchdog timeout: no successful checkins from configd (1 induced crashes) in 180 secondsExpected: socket close completes or returns an error. We have no deterministic reproducer, measured failure rate, or reconstructed per-flow close history. Direct lock-owner evidence Raw waitInfo records (mutex tokens are opaque): Report A, 26A428: thread 18691491: kernel mutex 0x61c831d7f38edbc3 owned by thread 19491850 thread 19491850: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491 thread 19794593: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491Report B, 26A434: thread 36984: kernel mutex 0x44aa649ef3095ae1 owned by thread 12555 thread 12555: krwlock 0xfffffe000ca01730 for writing owned by thread 36984 thread 309370: krwlock 0xfffffe000ca01730 for writing owned by thread 36984In each incident, the first two records form a cycle in both snapshots; the third is configd. All three threads are TH_WAIT / TH_UNINT. UUID-matched kernel stacks Caller-to-callee chains; listed offsets match in both kernels. Kernel worker (A: TID 18691491; B: TID 36984): nstat_idle_check + 808 -> in_pcb_checkstate + 128 -> udp_lock + 200 -> lck_mtx_lock_contended + 1212Holds _nstat_rwlock exclusively; waits for CloudShell's UDP socket mutex. CloudShell (A: TID 19491850; B: TID 12555): soclose + 212 -> soclose_locked + 2300 -> sofreelastref + 60 -> flow_divert_detach + 332 -> in_pcbdetach + 168 -> nstat_pcb_detach + 92 -> lck_rw_lock_exclusive + 180 -> lck_rw_lock_exclusive_gen + 912Holds the socket mutex; waits for _nstat_rwlock. XNU acquires these locks, not application code. configd (downstream victim): socket_common -> socreate_internal -> udp_attach -> nstat_udp_new_pcb -> lck_rw_lock_exclusivePossible enabling condition Matched 27 KDK disassembly shows a provider CLOSE path through cfil_sock_is_dead that directly marks the PCB DEAD and schedules GC without nstat cleanup. Public xnu-12377.121.6 (26.5) uses ordinary detach first. Provider CLOSE and final fd close are distinct. A DEAD PCB can retain an nstat locus/reference. Under _nstat_rwlock, nstat_idle_check removes the locus and releases the reference via in_pcb_checkstate(..., WNT_RELEASE, FALSE), which can take the socket mutex. Final close takes the reverse order; nstat_pcb_detach requests the nstat lock even when the locus is null. This is a possible enabling path from disassembly/source analysis, not proof of the preceding provider CLOSE in either incident. The older source already has opposite static lock orders; 26.5 is not proven immune. Questions for Apple Our provider calls closeReadWithError:nil and closeWriteWithError:nil when finished, as documented for NEAppProxyFlow. This does not validate the entire asynchronous lifecycle. Is this cycle known, and is there a fixed build? How is reverse locking avoided after the direct DEAD transition? Is there a supported workaround preserving flow cleanup? Close rate-limiting is not proven to eliminate the issue. Which diagnostics would help correlate provider CLOSE, DEAD, and final fd close? Attachments and timestamps Four EXCERPT attachments contain watchdog messages, raw frames, KDK annotations, and wait-owner records. Full reports are retained for private Feedback Assistant submission. 26A428_panic_excerpt.txt 26A428_configd_excerpt.txt 26A434_panic_excerpt.txt 26A434_configd_excerpt.txt 2026-10-15, +0800: configd capture -> embedded panic event: A: 04:24:43.1258 -> 04:26:44 B: 08:49:29.4349 -> 08:51:32 Use embedded panic times, not file/header timestamps. Original pairs match on boot identity; identifiers are omitted from excerpts. Sources: NEAppProxyFlow, XNU 26.5 comparison.

On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.

I've been investigating memory consumption issues with a network extension. It seems as though the "leak" exists within the network extension framework. Looking at a memory graph, there appears to be a _socketFlows dictionary or similar in the network extension framework that holds all of the flows and they continue to pile up and consume memory. The problem seems to be particularly bad when I leave my MacBook plugged in and running over the weekend and come back on Monday. For instance, in that time period, the memory consumption grew from <100MB to >1GB. To try to narrow this down to see if it was an "us" problem or truly in the framework, I installed Objective-See Foundation's Lulu tool, which also uses a network extension. It similarly saw memory grow from around 30MB or less to 600MB in the same time frame. Has anyone else seen this? We do have an open feedback ticket FB18731867 that might be related that has to do with seeing multiple instances of the same data filter provider started and maybe running in a network extension.

Hi, My NEURL Filter configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was approved on August 5, 2026, but it turned out to be attached to the wrong Apple Developer Team — an old individual account (S5VDH23BBZ) I no longer have access to, instead of my actual organization team, KRKJ76BC7W (SCOTTO), which owns and signs the app (bundle ID com.dropbet.DropBet). I contacted Developer Support, who said they couldn't transfer it and suggested replying to the original approval email — I did (on 08/08, then several times) with no response. I then tried resubmitting the same configuration under the correct team (KRKJ76BC7W), but the portal rejected it with: "A configuration with the same PIR Server Domain already exists." So a fresh submission is technically impossible while the original stays attached to the wrong account — the only real fix is transferring or re-attaching the existing approved configuration to KRKJ76BC7W. Has anyone dealt with this kind of Team ID mix-up before, or know who on the Network Extension / NEURL Filter team could help reassign an approved configuration? Happy to provide any additional details. Thanks in advance.

I'm developing an iOS app that aims to manage network usage on an iPhone acting as a Personal Hotspot. I'd like to know whether there is a supported public API that allows a third-party iOS app running on the host iPhone to limit the download speed of devices connected through Personal Hotspot. For example, I'd like to limit the download speed of tethered devices to a maximum of 1 Mbps, without limiting the host iPhone's own network traffic. Is this technically possible using public iOS APIs, or is this type of bandwidth control restricted to the system? Thank you for your guidance.

Steps to reproduce: Open captive network (DHCP + DNS → portal, hotspot-detect.html returns 302). Scan the Wi-Fi QR code with Camera and tap "Join". Stay in Camera. Expected: CNA is presented after a Camera-initiated join, as it is after a join from Settings > Wi-Fi. Actual: CNA is not presented until the user manually opens Settings > Wi-Fi. Impact: In-flight Wi-Fi with no internet, where the portal is mandatory. QR codes are the only onboarding method, and most users stay in Camera. Environment: iOS 18.7, iPhone 15 Pro max Questions: Is there any supported way to have the CNA presented after a Camera-initiated Wi-Fi join, without requiring the user to open Settings or Safari? If not, is this expected behavior, or a bug worth tracking?

We're moving our VPN client's firewall off pf (TN3165) and, following the advice in https://developer.apple.com/forums/thread/781996, relying on enforceRoutes plus a content filter. That works well for keeping traffic in the tunnel, but it has a side effect we can't work around. We add excluded routes at runtime (hostname-based split tunnelling), so the provider calls setTunnelNetworkSettings while connected. With enforceRoutes = true, any connected socket to a tunnelled destination (TCP, or UDP after connect()) that sends during the update gets EPIPE and stays broken until the app reopens it. It happens with identical settings too, and the EPIPE raises SIGPIPE, so apps that don't ignore it are terminated. From a sysdiagnose, every update logs "Resetting the virtual interface", the utun's address is removed and re-added about 5 ms later, and a socket that sends in that gap is marked defunct by necp_socket_find_policy_match ("Marking socket in state 258 as defunct"). With enforceRoutes = false nothing dies, but packets for tunnelled destinations leave on the physical interface during the update. It reproduces on macOS 15.7, 26.5, 27.0 and 27.2 beta 3 (26B5101f). I filed FB25176278 with a minimal sample (a packet tunnel provider that echoes UDP, so no server is needed) and a sysdiagnose from 27.2 beta 3. Two questions: Is there a supported way to change excludedRoutes on a running tunnel without the interface reset? If not, is there anything a provider can do to avoid this today, short of not updating routes while connected? Thanks!

Hi, We're in the process of following Apple’s guidance on transitioning away from Packet Filter (pf) and migrating to a Network Extension-based solution that functions as a firewall. During this transition, we've encountered several limitations with the current Content Filter API and wanted to share our findings. Our VPN client relies on firewall functionality to enforce strict adherence to split tunneling rules defined via the routing table. This ensures that no traffic leaks outside the VPN tunnel, which is critical for our users for a variety of reasons. To enforce this, our product currently uses interface-scoped rules to block all non-VPN traffic outside the tunnel. Replicating this behavior with the Content Filter API (NEFilterDataProvider) appears to be infeasible today. The key limitation we've encountered is that the current Content Filter API does not expose information about the network interface associated with a flow. As a workaround, we considered using the flow’s local endpoint IP to infer the interface, but this data is not available until after returning a verdict to peek into the flow’s data—at which point the connection has already been established. This can result in connection metadata leaking outside the tunnel, which may contain sensitive information depending on the connection. What is the recommended approach for this use case? NEFilterPacketProvider? This may work, but it has a negative impact on network performance. Using a Packet Tunnel Provider and purely relying on enforceRoutes? Would this indeed ensure that no traffic can leak by targeting a specific interface or by using a second VPN extension? And more broadly—especially if no such approach is currently feasible with the existing APIs—we're interpreting TN3165 as a signal that pf should be considered deprecated and may not be available in the next major macOS release. Is that a reasonable interpretation?

Hi Apple engineers and developers, I am developing a consumer digital-wellbeing app called Ghostie and am trying to determine the correct Apple-supported architecture for its iOS version before continuing implementation. Ghostie's core functionality is to let the user temporarily disconnect selected third-party apps from the Internet while keeping the rest of the device online. For example: WhatsApp: blocked Instagram: blocked Slack: blocked Maps: remains online Banking: remains online Music: remains online On Android, this is implemented using VpnService with per-app traffic handling. For iOS, I have been researching Network Extension, including: NEFilterDataProvider / NEFilterControlProvider content-filter-provider NETunnelProvider / packet-tunnel-provider per-app VPN configurations Apple's current documentation appears to indicate restrictions around per-app configurations and content filtering on iOS, including managed/supervised-device requirements in certain cases. My question is specifically about a normal consumer application distributed through the App Store, where the user owns and controls their personal device and Ghostie is not an MDM/enterprise product. Is there currently an Apple-supported API, entitlement, or Network Extension architecture that would allow Ghostie to: identify selected installed third-party apps; prevent those selected apps from establishing network connections; leave all other apps' network connectivity unaffected; and allow the user to turn this blocking on and off from Ghostie? If this is not possible for an ordinary consumer App Store application, could an Apple engineer please confirm which specific iOS restriction prevents it and whether there is any alternative supported architecture? I am trying to establish the technically and commercially viable architecture before implementing the iOS version. Thank you!

Title: NEFilterDataProvider — fail-closed behaviour after provider crash or suspension I'm investigating the documented failure behaviour of NEFilterDataProvider on macOS. For a content filter handling outbound socket flows: If the data provider process crashes, is terminated, or disconnects unexpectedly, what happens to existing allowed, paused and partially released flows? If the provider is suspended or its callback queue stops making progress, does macOS retain existing verdicts indefinitely, block further data, or apply some other behaviour? Can an existing passBytes allowance remain usable after the provider becomes unavailable? Is there a supported mechanism for independently confirming that all relevant existing flows and outstanding release allowances have been fenced? I'm particularly interested in documented guarantees, rather than implementation behaviour observed in individual tests. Any relevant Apple API documentation or technical clarification would be appreciated.

Hello, I am writing about a Network Extension URL Filter configuration submitted through the Identity & Trust section of the CloudKit Console on 5 September 2026 Status shown: In Review / Waiting for Approval Last Modified: 5 September 2026 (unchanged since submission) It has now been 37 days with no response — no approval, no rejection, and no request for changes. The PIR server , Privacy Pass issuer and HTTP/2 OHTTP gateway have been live and serving since the day of submission, configured per the Onboarding.md guidance in Apple's PIR service example, including the apple-url-filter DNS TXT record on the service URL and the url-filter-test validation entry. Could anyone please let me know: Whether this configuration is actually in a review queue, and the expected timeframe; Whether anything further is required from our side — if so, we will act on it the same day. The URL filter is a core protection feature of our app, which is currently in App Store review; the feature stays disabled for users until this registration is approved, so the delay is holding up what we can ship. Thank you for your help.

We're seeing a recurring kernel panic across six Mac17-family Macs (Mac17,2 / Mac17,4 / Mac17,8; T8142 and T6050) in a managed fleet. 34 panic logs collected 30 Sept – 9 Oct, all with the same signature: panic(cpu N caller ...): Kernel tag check fault (expected tagged address: 0x...028), esr 0x96000011 Faulting address is always at offset 0x28 of the object Same crash PC per build: kernel text exec base + 0x48da38 on 27.0/27.0.1, + 0x46a784 on 26.7, + 0x466ee0 on 26.5 Panicked task is "Google Chrome Helper" in all 34 cases, thread Chrome_ChildIOThread (Chrome's IPC/network I/O thread) Always 3–60 s after wake from sleep, usually a dark wake with the lid closed (overnight or after a 3–18 min sleep) No third-party kexts loaded; "Post-boot loaded kexts" lists only Apple drivers Affected builds: 26.5 (25F71), 26.7 (25G229), 27.0 (26A428), 27.0.1 (26A434). Not a regression from one update: a machine still on 26.5 panics identically. Only Mac17-family hardware is affected. Older Apple silicon Macs with the same software stack are fine. Present on every affected machine: Chrome PWAs (Gmail/Chat/Meet) running in the background, keeping Chrome's network service alive across sleep. On one machine Microsoft Edge is the primary browser and never panics; only Chrome Helper does. Microsoft Defender for Endpoint with its network filter (content filter) extension, MDM-managed. This looks related to thread 821372, where DTS described a kernel networking panic on M5-family hardware with a Network Extension present (r.172793638 / FB22401652), fixed in 26.5b2. We appear to be seeing a tag-check-fault variant on 26.5 release and later. Questions: Is this a known issue, and is it the same root cause as r.172793638? Is there a build where it's fixed? Any recommended mitigation beyond preventing sleep and quitting Chrome? Feedback Assistant: FB25128015 with panic logs and sysdiagnose. Happy to collect more data or test a build. Backtrace from a 27.0.1 panic (kernel text exec base 0xfffffe003aa54000), panic PC first: lr: 0xfffffe003aee1a38 lr: 0xfffffe003aeec580 lr: 0xfffffe003b12cf34 lr: 0xfffffe003b12dc50 lr: 0xfffffe003b07b1f8 lr: 0xfffffe003b07c758 lr: 0xfffffe003b237ff4 lr: 0xfffffe003ac787f0 lr: 0xfffffe003aa576ac lr: 0x000000018747a57c (userspace)

We are developing a DLP agent that uses a NETransparentProxyProvider to perform traffic inspection and modification. Our architecture currently includes: LaunchAgent, which monitors user session activity (login/logout, session activation) Container App, which: installs and activates a System Extension creates and saves the NETransparentProxyManager configuration starts the transparent proxy via startVPNTunnel. We would like to automate the startup of the Transparent Proxy for all users, including newly created users, in a way that is fully supported by macOS. We are looking for official guidance on the correct and supported mechanism for starting a user‑level Network Extension (specifically NETransparentProxyProvider) automatically at user login. Questions: What is the recommended and supported way to automatically start a NETransparentProxyProvider at user login? Are there any constraints or best practices we should follow when designing an automatic startup flow for a Network Extension such as NETransparentProxyProvider? We would appreciate official clarification on the supported deployment patterns for starting a user‑level Transparent Proxy Network Extension automatically in multi‑user enterprise environments.

Hello, It seems that starting Xcode 27, the logs from NetworkExtensions do not show up in the Xcode Console anymore. They still show in Console.app somehow. I have filed a bug report (FB24985332) about it, if you encounter the same issue, please upvote this so that the NetworkExtension team can fix this faster, thanks !

I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): `let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes.