Does Split Tunneling Work on iOS? The Honest Answer for Consumer VPNs
TL;DR: As of September 2026, no consumer VPN, including Palyfox, can offer per-app split tunneling on iOS. Apple reserves per-app VPN for managed apps deployed through device management. Your practical choices are to disconnect briefly, check whether local-network traffic can bypass the tunnel, or use Android or desktop software that implements split tunneling.
Does split tunneling work on iOS?
No, not as per-app split tunneling in a consumer VPN. As of September 2026, Apple’s VPN device-management documentation presents per-app VPN as a management capability for managed apps. A consumer VPN built with Apple’s Network Extension packet-tunnel system routes at the device level; Apple’s NETunnelProviderManager documentation does not give that consumer app a way to exclude any other individual app from its tunnel.
To be precise about what Apple’s framework does and does not allow: route-based, IP-level tunneling decisions (which network destinations go through the tunnel) are available to every VPN app, and managed per-app VPN exists for device-management deployments. What is missing is the consumer-facing version — the boundary applies to every consumer VPN on iOS, including Palyfox. It rules out the familiar controls people mean when they ask for split tunneling: “exclude just my banking app,” include only selected apps, or send only a browser through the VPN app. Those controls are not available to an ordinary consumer packet-tunnel VPN on iOS as of September 2026; Apple’s managed per-app VPN is a different deployment model (Apple deployment documentation).
Two public statements show how bluntly the industry itself talks about this — though both compress the nuance. Proton’s General Manager said in September 2025: “Correct. Apple disables split tunneling on iOS unless you have a corporate device.” Nym CEO Harry Halpin said in July 2026: “It doesn’t work on iOS because split-tunneling is not allowed on iOS for any VPN. Apple incorrectly thinks no user wants this and so split-tunneling is a data exfiltration attack.” Both are shorthand: Apple’s per-app VPN in fact ships through device-management enrollment (including User Enrollment, not only corporate-owned devices), route-based IP-level tunneling remains available to every VPN, and the “Apple thinks” sentence is Halpin’s characterization of Apple’s reasoning, not an established explanation from Apple. The accurate core survives the compression: an ordinary consumer VPN app cannot offer per-app exclusions on iOS.
“Managed” matters here. It means apps and VPN configuration deployed through device management, often called MDM, rather than apps a person installs and configures as an ordinary consumer. Apple’s September 2026 deployment model can associate managed apps with per-app VPN; it does not turn that management feature into a consumer VPN setting (Apple deployment documentation). For a broader explanation of what the tunnel changes, see what a VPN is.
Why can’t I exclude my banking app from the VPN?
An anonymized public X post from September 2026 captures the inconvenience: “I got tired of remembering to flip on my VPN before checking my bank balance”. The desired fix sounds modest: leave the VPN connected, but let only the banking app use the regular connection. On iOS, a consumer VPN cannot create that one-app exception because its packet tunnel operates at device scope, while Apple’s per-app routing belongs to managed deployments (Apple deployment documentation; NETunnelProviderManager documentation).
Security researchers Mysk (@mysk_co) noted publicly on X in June 2026 that iOS apps can detect that a VPN is active without requesting any permission. That observation explains how an app can know the VPN is on; it does not establish why any particular banking app rejects a connection. A block could be tied to the app’s own policy or another condition, so diagnosing one app requires evidence from that app rather than a blanket explanation.
The result is an awkward choice when a banking app behaves differently with the VPN active: use the app with the device-level tunnel, or disconnect the tunnel for that task. iOS does not provide a consumer VPN with a third, per-app route as of September 2026 (Apple deployment documentation). If you disconnect, the practical steps are in the iPhone VPN disconnect guide.
This is also why changing VPN providers does not unlock a native iOS per-app exclusion. The restriction is in Apple’s consumer packet-tunnel model, not a vendor-specific settings screen (NETunnelProviderManager documentation). You may not need a VPN for every banking session, but turning it off should be a deliberate, temporary choice rather than a promise that iOS will isolate the bank app automatically.
”More and more apps do not work with VPN on”
That heading comes from an anonymized August 2026 public X post: “Is there any news for split tunneling on iOS? More and more apps do not work with VPN on”. Another anonymized post from the same month described the platform gap this way: “Use split tunneling. Doesnt work on ios but works awesome on laptop and androids. But yeah still a struggle”. These are reports of user frustration, not controlled tests or proof about a particular app.
Local devices create a related but distinct problem. An anonymized January 2026 post said: “with VPN on, Apple music doesn’t airplay onto the home pods. Great way to turn off the VPN just to connect to homepods.” The complaint involves reaching devices on a local network; that is not the same mechanism as excluding one app from internet tunneling.
As of September 2026, Apple’s Network Extension routing configuration includes an excludeLocalNetworks setting on the packet-tunnel network settings. Whether AirPlay, HomePod, or a printer remains reachable while a VPN tunnel is connected depends on how the VPN app configures local-network routes. That makes local access a behavior to test, not something a VPN article should promise.
Until that test is filled with a real device, OS build, app version, network, date, and result, there is no product-specific claim to make. The useful distinction is narrower: local-network routing may be configurable at the tunnel level (excludeLocalNetworks), but it does not create per-app split tunneling.
What you can actually do about it (3 honest workarounds)
None of these workarounds turns consumer iOS into a per-app VPN platform. Each solves a smaller version of the problem within the limits Apple documents for consumer packet tunnels and managed per-app VPN as of September 2026 (Apple deployment documentation; NETunnelProviderManager documentation).
1. Disconnect for the task, then reconnect
If one app refuses to work while the VPN is active, disconnect the VPN, complete the task, and reconnect afterward. This temporarily sends the device outside the VPN rather than exempting only one app. Follow how to turn off a VPN cleanly on iPhone if the connection returns automatically.
The boundary is important: while disconnected, the workaround is device-wide. It is suitable when you accept that tradeoff for a short task. It is not equivalent to an exclusion rule, and it does not become one just because only one app is open.
2. Check local-network behavior for AirPlay, HomePod, and printers
If the problem is reaching something on the same local network, per-app split tunneling may not be the relevant tool. Apple’s Network Extension routing model can exclude local networks depending on tunnel configuration (excludeLocalNetworks), so the VPN app’s handling of local routes is the product-specific question.
Do not assume that means a given device or service will work. Use the Palyfox product question and pending test above before making a Palyfox-specific claim. This workaround is limited to local-network reachability; it does not let a banking app, browser, or other chosen app bypass the VPN for internet traffic.
3. Use a platform where per-app or rule-based routing is supported
Android supports per-app VPN controls at the platform level — VpnService.Builder lets a VPN app allow or disallow individual applications — and desktop VPN clients can implement rule-based routing themselves. Each VPN product still decides whether to expose these options.
That can solve the workflow if you already have an Android or desktop device and its VPN software implements the needed rule. It is not a hidden iPhone fix, and it is not a reason to promise support in a product that has not confirmed it.
Where split tunneling DOES work
At the platform level, Android supports per-app controls through VpnService, while desktop operating systems leave rule-based routing to the VPN client itself. Product support still varies: a platform capability does not mean every VPN app exposes it.
Palyfox VPN is currently available on iPhone and iPad; macOS, Android, Windows, and Linux apps are coming soon. This article makes no claim about split-tunneling options in apps that have not shipped yet.
The platform distinction is the reliable guide. Consumer iOS packet tunnels are device-level, and Apple’s per-app VPN is for managed apps (Apple deployment documentation; NETunnelProviderManager documentation). Android and desktop platforms can provide the underlying controls, but the chosen VPN product must implement them. For adjacent iPhone decisions, see whether an iPhone needs a VPN and iCloud Private Relay versus a VPN.
What is the practical answer?
Do not keep searching for an “exclude this app” switch in a consumer iPhone VPN: Apple does not make that control available. Disconnect briefly when necessary, test local-device access instead of assuming it, or move that workflow to Android or desktop software with confirmed split-tunneling support. If connection interruptions are the concern, use the separate iPhone VPN kill-switch test.
