Ever wondered why your VPN's Mac app can't do what its Windows app does? This is the technical explainer: how macOS actually lets software make per-app routing decisions, why the mechanism is a transparent proxy rather than a firewall rule, and what that means for reliability and privacy.
The Network Extension model
Apple doesn't let ordinary apps rummage through the network stack. Instead, macOS offers Network Extensions — sandboxed system extensions with specific, Apple-reviewed capabilities. The one that matters for split tunneling is the transparent proxy provider: once the user approves it, macOS hands the extension new outbound connections *before* they hit the wire, along with metadata about which process created them. The extension then decides where each connection goes.
That approval flow is why a split-tunneling app asks you to enable something under System Settings → Login Items & Extensions on first launch. It's a one-time, user-consented installation of the routing layer — nothing kernel-level, nothing hidden.
What happens to a packet, per app
When an app opens a connection, macOS tells the extension which app (and helper process) it belongs to. The extension looks up your rule for that app and picks a lane: bind the connection to the VPN's tunnel interface, bind it to the physical interface (Wi-Fi/Ethernet) for direct traffic, or refuse it entirely for blocked apps. Because the decision happens per connection with process identity attached, helper processes inherit the parent app's rule — Chrome's networking helper follows your Chrome rule automatically.
One consequence worth knowing: a connection that's already open can't be moved to a different lane mid-stream — a live TCP connection is bound to the addresses it started with. That's why every split-tunneling product applies rule changes to *new* connections, and why nudging apps to reconnect (or restarting them) applies changes immediately. More on that in the troubleshooting guide.
Why VPN vendors skip this on the Mac
A VPN vendor's core product is the tunnel. Per-app routing on macOS is a second product: a separate extension type, a separate approval flow, and a pile of edge cases (DNS handling, LAN traffic, captive portals, System processes that must never be blocked). Windows offers cheaper paths to the same feature, and Windows is where most VPN customers are — so the Mac feature rarely gets built. That's the gap a dedicated utility fills: AppLanes is exactly this Network Extension layer, built to work with every VPN rather than for one.
The privacy angle: routing without snooping
A transparent proxy sees connection metadata — it has to, to route. It does not have to decrypt, store, or transmit anything. AppLanes runs entirely on-device: no account, no telemetry, no servers of its own; the App Store privacy label reads "Data Not Collected". Routing decisions and the live activity feed exist only in memory on your Mac. When evaluating any split-tunneling tool, that's the property to check: does traffic metadata stay on the machine?
Frequently asked questions
Is a transparent proxy the same as a kernel extension?
No. Kernel extensions (kexts) are deprecated for this use; Network Extensions run in user space, sandboxed, with entitlements Apple reviews. That's why modern tools install via a System Settings approval rather than lowering your Mac's security.
Does per-app routing slow down my connection?
The routing decision happens once per connection, not per packet, so overhead is negligible. Direct-lane traffic actually gets faster than an all-VPN setup because it skips the tunnel round-trip entirely.
Can macOS built-in tools do per-app VPN routing?
Not for personal use. Apple exposes per-app VPN only through enterprise MDM profiles. On a personal Mac, per-app routing requires a Network Extension–based utility such as AppLanes.
Get per-app VPN routing on your Mac
Every feature unlocked for 3 days, free — no account, works with any VPN, macOS 13+.