Why your iPhone app can't turn the system VPN on or off

A product manager asks for a button that turns the company VPN on, and the request sounds trivial. On iOS it is not a small feature; it sits outside the public contract, and every workaround either fails review or breaks at the next release. Walk the request through what the platform actually permits and the design largely writes itself. An app can own a VPN configuration and start it. An app cannot reach the system switch, cannot read the state of a profile it did not create, and cannot keep a user connected against their will.

Start from the three things the user means

Separate the meanings before you separate the APIs. Sometimes the user wants your app's tunnel connected, sometimes they want the Settings switch flipped for a profile someone else installed, and sometimes they want the phone to be unable to browse without the tunnel. Those map to three different mechanisms, and only the first is open to an ordinary app.

The second meaning is what generates the Stack Overflow questions, and it has no supported answer. The Settings toggle belongs to the user and, on managed devices, to the profile. No public API enumerates VPN configurations, reports whether the system tunnel is up, or flips it.

What an app can actually create

NetworkExtension gives an app a configuration of its own through NEVPNManager. With the Personal VPN entitlement and the user's consent, the app saves a configuration that appears in Settings under its own name, and it can start or stop that one connection. That is a real, reviewable capability, and it is also the whole scope: the manager reads and writes only what it created.

The entitlement is not automatic. You request it from Apple and justify why the app needs a tunnel at all, and a client whose only goal is switching on somebody else's profile has no good answer. Packet tunnel providers follow the same rule with a different class: NETunnelProviderManager owns provider-based configurations that the app itself installed. Neither path reaches a profile that MDM delivered.

Consent applies at save time as well. Writing a configuration prompts the user, and the prompt is not something an app may suppress for convenience.

Reading the state hits the same wall

Status looks friendlier than control and is equally closed. NEVPNStatus reports invalid, disconnected, connecting, connected, reasserting or disconnecting for the app's own configuration, and a notification fires on every change. It says nothing about a tunnel installed by a management profile, which is the state a help desk actually wants to see.

Network path monitoring and interface changes get offered as substitutes during design reviews. They describe the path the app's traffic takes, which changes for reasons unrelated to VPN state, and using them as a VPN readout yields a UI that lies in both directions.

On Demand and Always On are the real levers

The supported levers live in the profile rather than in the app. On Demand rules tell the system when to connect: an ordered list of conditions with actions, evaluated by the operating system, not by your code. A rule that connects on any interface creates an always-connect feel without granting any app control.

Always On VPN is the enforcement mechanism, and it is tied to supervision. On a supervised device, MDM installs a profile that keeps the tunnel up; on an unsupervised personal phone the same keys do not produce the same behaviour. That asymmetry is deliberate, and no combination of payload keys removes it. When the requirement is genuinely that the VPN must be on, the requirement is really that the device must be managed.

Between the two sits the weaker cousin: a rule that reconnects after the user disconnects. It reconnects when the rule is next evaluated, which is not the same as immediately, and a user who disconnected on purpose will notice the difference. Design the interface around that gap instead of promising a lock.

Ship the supported path

Four questions settle the mechanism before any code exists: who owns the device, whether it is supervised, which client terminates the tunnel, and where the profile comes from. If any of those is unknown, the feature request is not ready for estimation.

A private API that pokes the system VPN will pass a demo and fail review, and if it ships by other means it breaks on the next iOS release. There is no version of that trade worth making for a toggle.

Management telemetry is a separate channel: it reports that a profile is installed and whether the device is compliant, which is reporting rather than a per-app control surface. Test the flow on a real device after each update, because the supported behaviour lives in the OS and the OS moves.