Network control

VPN and Network Extension App Review checklist

Network extensions change traffic behavior at a sensitive layer. Review readiness depends on a clear purpose, correct entitlement use, transparent privacy, and user control.

Quick answer

Submit a VPN or Network Extension app only when the network function is central, user-visible, and testable. Apple Network Extension documentation covers VPN configurations, relay configurations, and filtering capabilities. AppReviewReady interpretation: create a traffic-scope ledger showing what is tunneled or filtered, why, what is logged, and how the user stops it.

01

State the network purpose plainly

A network extension should solve a specific user problem: enterprise access, personal privacy, parental controls, content filtering, threat protection, device management, or secure routing. If the app cannot explain what traffic changes and why, review will be harder.

Avoid generic security claims such as 'protects everything' unless the product truly provides that coverage and the privacy policy supports it. Network claims are safety and trust claims.

02

Match entitlement, capability, and UI

  • The app's capability should match the actual feature: Personal VPN, packet tunnel, app proxy, DNS proxy, content filter, or related network extension.
  • Onboarding should tell the user what configuration is installed and how to remove or disable it.
  • The app should handle denied configuration permission without misleading success screens.
  • A test account or server endpoint should be available during review.
03

Build a traffic-scope ledger

List what traffic is tunneled, filtered, inspected, blocked, logged, or ignored. Include whether DNS, domains, URLs, app identifiers, device identifiers, IP addresses, content categories, or diagnostics are processed.

AppReviewReady interpretation: compare the ledger with privacy labels and the privacy policy. If marketing says 'no logs' while diagnostics keep connection records, rewrite the claim or change the logging behavior before review.

04

Test connection and failure states

  1. Install from a clean device and create the network configuration from the app UI.
  2. Connect, disconnect, reconnect, revoke permission, delete the configuration, and reinstall.
  3. Test invalid credentials, expired subscription, offline network, captive portal, and server outage.
  4. Verify the status indicator reflects actual tunnel or filter state.
  5. Confirm support, privacy, and account deletion paths remain reachable when the network feature is off.
05

Give review a safe verification path

The reviewer should not need to guess whether the VPN or filter is active. Provide an observable result that does not require private production credentials or unsafe browsing.

Keep a privacy and support fallback in the route. Users need to understand what happens when the tunnel is off, when a subscription expires, or when the server is unavailable. Reviewers should be able to verify that the app fails closed or fails transparently instead of silently changing traffic handling.

If the app blocks or filters categories, include a harmless test domain or policy example. The reviewer should not need to browse dangerous content to prove the network extension is enforcing the documented rule.

Copy-ready frameworkAdapt every bracketed field
Network Extension review path:
Feature type: [Personal VPN, tunnel, filter]
Test account/server: [details]
Traffic scope: [what changes]
Logs retained: [none or fields]
How to enable/disable: [steps]
Expected verification: [IP change, blocked domain, policy result]
Sources

Primary references checked for this guide

Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.

Put it to work

Check network review risk

Review entitlement use, privacy claims, traffic scope, and test access before submission.

Open the tool