iOS VPN App Development: Personal VPN vs Packet Tunnel
You are starting iOS VPN app development, and the first architecture question is already on the table: do you configure the VPN client that iOS ships with, or build your own tunnel? The answer decides your protocols, team, servers and App Review notes.
The short answer: for a public VPN app that uses WireGuard, OpenVPN or an Xray based stack, build a packet tunnel provider. Choose Personal VPN only when IKEv2 is enough, because then iOS runs the protocol and you build very little. Apple’s third option, the app proxy provider, is limited to managed devices on iOS, so it rarely fits an App Store product.
This guide is for founders and product leads choosing an architecture. Platform facts come from Apple’s documentation, linked as we go, and our own readings are labelled.
What Are Apple’s Three VPN Options?
Apple’s Network Extension overview splits VPN support into three APIs, distinguished by the protocols they handle.
| Option | Protocols | What you build |
|---|---|---|
| Personal VPN | Built in IPsec or IKEv2 | An app that saves a configuration and starts the connection through NEVPNManager. No tunnel code. |
| Packet tunnel provider | A packet oriented custom protocol | An app plus an app extension that subclasses NEPacketTunnelProvider and carries the packets itself. |
| App proxy provider | A flow oriented custom protocol | An app plus an app extension that forwards each TCP connection or UDP conversation. |
With Personal VPN, iOS runs the client and your app supplies the settings. Apple’s Personal VPN page says the user must explicitly authorize your app the first time it saves a configuration. The packet tunnel pages we read do not say whether the same prompt applies there, so test that flow on a device.
With a packet tunnel provider, the system launches your extension, creates your provider class inside it and starts forwarding packets to it. Your code opens the tunnel to your server and hands returning packets back to the system.
The app proxy provider works the same way but at the level of flows. Apple’s TN3134 deployment note lists it on iOS as managed devices only. For an app you sell to the public, that leaves two realistic options.
IKEv2 or a Custom Protocol: Which Protocols Go With Which Option?
IKEv2 goes with Personal VPN. Apple’s page says Personal VPN configures a built in protocol, IPsec or IKEv2, and does not support legacy protocols such as PPTP and L2TP.
Everything else goes into a packet tunnel provider, because iOS has no built in client for it. That covers WireGuard, OpenVPN and the proxy stacks built on Xray or sing-box. None of them is one of the two built in protocols, so each is a custom protocol in Apple’s terms.
Xray and sing-box are cores, not iOS VPN protocols. The usual design embeds the core in the extension and feeds it the packets the system routes there. That is our engineering view, not an Apple statement. Apple’s part is that the protocol is custom and the flow based route is closed to unmanaged devices.
You could ship your own IKEv2 stack inside a packet tunnel provider, but that gives up the one reason to pick Personal VPN: not writing protocol code. For a view of the protocols themselves, see our VPN protocol comparison.
How Does Guideline 5.4 Fit a Packet Tunnel App?
Apple’s App Review Guidelines, last updated 16 October 2026, say in 5.4 that apps offering VPN services “must utilize the NEVPNManager API”. A packet tunnel app does not call that class directly, so the question is fair.
Apple’s references answer most of it. The NETunnelProviderManager reference says it inherits from NEVPNManager and takes most of its functionality from it. It is the class the containing app uses to create and control configurations for a packet tunnel provider. Apple’s TN3120 also lists a VPN client that tunnels traffic through a public VPN service as a recommended use of packet tunnel providers.
Our reading: a custom protocol VPN app built on NETunnelProviderManager sits inside the API family that 5.4 names. The guideline text does not mention the subclass, and we found no Apple page that says so in one sentence. Keep both references handy in case a reviewer asks, and have your iOS engineer confirm before you rely on this.
The rest of 5.4 applies whichever option you pick. Apple requires an organization developer account (see our guide to the Apple organization account for a VPN app), a clear data declaration on an app screen before purchase or use, and a privacy policy commitment not to sell, use or disclose data to third parties.
What Entitlements and Capabilities Does Each Option Need?
Personal VPN. Enable the Personal VPN capability in Xcode. Apple says Xcode then sets the com.apple.developer.networking.vpn.api entitlement to allow-vpn, and that entitlement lets your app manage a Personal VPN configuration through NEVPNManager.
Packet tunnel provider. Add the Network Extensions capability and check the Packet Tunnel box. Apple’s Xcode guide to configuring network extensions says Xcode writes the capabilities you enabled into the com.apple.developer.networking.networkextension array and, with automatic signing, enables the capability on your App ID.
Then build the extension. Add an app extension target, set its extension point to com.apple.networkextension.packet-tunnel, name your NEPacketTunnelProvider subclass as the principal class, override startTunnel and stopTunnel, and embed the target in the app, as Apple’s NEPacketTunnelProvider reference describes.
Both routes touch your developer account. Apple’s account help says an Account Holder or Admin enables capabilities on an App ID, and that editing an App ID invalidates provisioning profiles that use it. Its capability requests page describes managed capabilities as ones that need an entitlement assigned to your account by Apple, and says the Account Holder submits those requests. We found no page placing Network Extensions in that group, but check the Capability Requests tab for your App ID before you set a schedule.
What Can You Control With Each Option?
| Control | Personal VPN (IKEv2) | Packet tunnel provider |
|---|---|---|
| Protocol | Built in IKEv2 or IPsec only | Any packet oriented protocol you implement or embed |
| Protocol tuning | IKEv2 settings such as security association parameters, MOBIKE, PFS, dead peer detection rate and MTU | Whatever your own code exposes |
| Obfuscation | None, the system owns the wire format | Yours to build, ship and keep testing |
| Routes | Shaped by what the IKEv2 server sends and by protocol flags | Included and excluded IPv4 and IPv6 routes, set in code |
| Kill switch style setting | includeAllNetworks (Apple documents enforceRoutes only for packet tunnel route lists) |
includeAllNetworks, or enforceRoutes to enforce your own route lists |
| On demand rules | Yes | Yes |
| DNS | No resolver property on the Personal VPN reference pages we read | DNS settings in code, including DNS over HTTPS and DNS over TLS classes |
| Per app VPN | Not documented | Needs MDM on iOS |
| Configurations | One shared manager | Several, one enabled at a time |
First, includeAllNetworks means most traffic, not all of it. Apple’s routing guide says the system always exempts control plane traffic such as DHCP, captive portal negotiation, some cellular only services such as VoLTE, and companion device traffic. With the setting on, the system drops traffic when the VPN leaves the connected state, for example during a Wi-Fi to cellular handover while the tunnel reconnects. That is the kill switch behaviour you want, and your connection screens must be built around it. Our kill switch explainer covers the product side.
Second, Apple’s class reference calls configurations made through NETunnelProviderManager enterprise VPN configurations, as opposed to Personal VPN. If both are active, the tunnel provider’s routes win on a conflict and the Personal VPN stays connected.
Third, if your product is a DNS filter rather than a tunnel, TN3120 warns against using a packet tunnel provider to intercept all system DNS and points to the DNS settings and DNS proxy APIs.
What Does Choosing IKEv2 Mean for Your Servers?
Choosing IKEv2 moves the work from the phone to the server. iOS brings the client, and you bring a compliant IKEv2 server with certificates and an authentication backend.
Apple’s Platform Deployment guide to VPN lists the IKEv2 authentication methods iOS supports: shared secret, certificates, EAP-TLS and EAP-MSCHAPv2. It also lists MOBIKE, IKE fragmentation, server redirect and split tunnel. MOBIKE, defined in RFC 4555, lets a mobile client keep its VPN connection while its address changes, which is why IKEv2 copes well with Wi-Fi to cellular moves.
Apple’s test advice is simple. Build a configuration profile for your server with Apple Configurator. If you can connect with it, Personal VPN should connect too. Do this before you write any app code.
If you run strongSwan or another open source server, read its current notes for Apple clients and test your certificate and authentication settings on a real device.
The cost shows up in the network, not the phone. RFC 7296 says IKE normally listens on UDP port 500 and can also use port 4500. Any network that filters by port can therefore block it; that is our inference, not an RFC statement. In mainstream markets that is fine. Where filtering is heavy, IKEv2 on its own can be a weak choice, and Personal VPN leaves no room to add obfuscation. Each extra protocol you offer is also another server stack to run, patch and monitor.
Which Should You Choose for iOS VPN App Development?
| If this describes you | Build | Why |
|---|---|---|
| You already run an IKEv2 gateway and want the smallest app | Personal VPN | iOS runs the client, so there is no tunnel code |
| Consumer VPN on WireGuard, OpenVPN or an Xray stack | Packet tunnel provider | A custom protocol needs the extension |
| You want fallback between protocols or an obfuscation layer | Packet tunnel provider | Only an extension lets you own the transport, and results depend on the network and on testing |
| You want your own DNS settings or explicit route lists | Packet tunnel provider | Both are set in code |
| You want to validate demand quickly on IKEv2 | Personal VPN first | Less to build, but moving to an extension later is a second build |
| You want per app VPN in a consumer app | Neither on its own | Apple ties per app mode on iOS to managed devices |
| Your protocol is flow oriented and the app is public | Rethink the design | The app proxy provider is managed devices only on iOS |
How Do You Test Each Option, and What Happens in Review?
A test plan that fits both options:
- Server first. Connect with an Apple Configurator profile before app code exists.
- Lifecycle. Watch the
NEVPNStatustransitions across Wi-Fi to cellular, sleep and wake, and airplane mode. - Excluded traffic. Do not write “all your traffic” in the app until you have measured what leaves the tunnel on your configuration.
- Leaks. Check the exit IP and DNS resolvers on Wi-Fi and cellular with an IP checker.
- On demand rules. Apple’s guide says On Demand needs an authentication method without user interaction, so test auto connect on each network type.
- Extension limits. Your tunnel code runs in an app extension, not in the app. We do not quote a memory figure here. Ask your iOS engineer for the current ceiling and profile memory on the oldest device you support.
For review, the same guideline family applies to both options. Guideline 5.4 asks for a data declaration before purchase or use, a no sale and no disclosure commitment in the privacy policy, and license information in the App Review Notes field if you offer the app in a territory that requires a VPN license. Guideline 2.1(a) asks for demo account details and a live backend, and 2.3.1(a) asks you to describe new features and changes specifically in the Notes for Review. A reviewer who cannot sign in or connect cannot evaluate the app. Our VPN app store approval guide covers the rest of the process.
FAQ
Can I use WireGuard or Xray with Personal VPN?
No. Personal VPN configures only the built in IPsec or IKEv2 client. Any other protocol is a custom protocol, which means a packet tunnel provider app extension.
Is NETunnelProviderManager allowed under Guideline 5.4?
Apple’s guideline text does not name it, but it is a subclass of NEVPNManager and TN3120 lists a public VPN client as a recommended packet tunnel use. Keep those references ready and confirm with your iOS engineer.
Do I need an organization account for Personal VPN too?
Yes. Guideline 5.4 applies to apps offering VPN services and does not carve out any of the three options.
Can a consumer iOS app offer per app VPN?
Not on its own. Apple’s NETunnelProviderManager reference says per app VPN is configured by enrolling the device in MDM, and TN3134 says per app mode on iOS requires a managed device.
When to Pick Each
Pick Personal VPN when IKEv2 is genuinely enough: you run an IKEv2 server, your markets do not filter by port, and you want the smallest iOS build. Pick a packet tunnel provider when you need WireGuard, OpenVPN or an Xray stack, protocol fallback, obfuscation, custom DNS or explicit routes. For public iOS VPN app development, that is the usual answer. Leave the app proxy provider for managed device projects.
Choosing between Personal VPN and a packet tunnel provider for your iOS app? Tell us your protocols and markets on the contact page, and we will tell you which route we would take and what we would test first.
Last checked against Apple’s Network Extension documentation, TN3120, TN3134, the App Review Guidelines, Apple’s VPN deployment guide and developer account help, RFC 7296 and RFC 4555 on 30 October 2026.