Getting a VPN App Approved on the App Store and Google Play
App store rejection is the most common way a VPN launch stalls. Teams build the app, submit it, and discover the VPN-specific rules only when the rejection lands. The frustrating part is that most of these rejections are predictable, and almost all of them are avoidable if you know the requirements before you submit.
We have shipped VPN apps through both stores, so this is the guide we wish more founders read first. It covers what Apple and Google actually require for VPN apps in 2026, the specific traps that catch people (including the organization-account requirement that rejects developers even after they think they have fixed it), and a pre-submission checklist. None of this is legal advice. Store policies change, so re-check the official pages before you submit.
Why VPN Apps Get Extra Scrutiny
Both stores treat VPN apps as a sensitive category because a VPN sees and routes a user’s traffic. That power is exactly what the policies are written to constrain. Reviews are slower than average, rejections are common, and the reasons are sometimes vague. The defense is not cleverness, it is compliance: build on the official APIs, disclose data practices honestly, use the right kind of developer account, and present a clean, truthful listing. Get those right and most of the risk disappears.
Apple App Store: Guideline 5.4
Apple’s rules for VPN apps live in App Store Review Guideline 5.4. The current text is specific, and worth reading in full, but here are the requirements that decide approvals.
You must use the NEVPNManager API
Apple requires VPN apps to “utilize the NEVPNManager API.” In practice this means building on Apple’s NetworkExtension framework. For a custom protocol, that means running your tunnel inside a Packet Tunnel Provider. Apple’s documentation describes NEPacketTunnelProvider as “the principal class for a packet tunnel provider app extension,” and using it requires the com.apple.developer.networking.networkextension entitlement, which Apple grants on request. A VPN app that tries to route traffic by unofficial means will not pass.
You must be enrolled as an organization
This is the single most common hard stop. Apple’s guideline states that VPN services “may only be offered by developers enrolled as an organization.” An individual Apple Developer account cannot ship a VPN app. You need a company or organization enrollment, which requires a legal entity and a D-U-N-S number.
The trap that catches teams: switching your account to an organization is necessary but does not automatically clear a rejection. Developers regularly report that even after enrolling as an organization, the app is rejected again, because something else is also wrong (the data-disclosure screen, the API usage, or a spam-related issue covered below). Treat the organization account as the price of entry, not the whole solution.
You must disclose data collection before any user action
Apple requires “a clear declaration of what user data will be collected and how it will be used on an app screen prior to any user action to purchase or otherwise use the service.” This is a real screen in your app, shown before the user signs up or connects, not a line buried in your privacy policy. Reviewers check for it.
You may not sell or disclose VPN data
The guideline is blunt: VPN apps “may not sell, use, or disclose to third parties any data for any purpose, and must commit to this in their privacy policy.” This has a practical consequence that surprises founders: advertising and analytics SDKs that monetize or share user data conflict with this rule. If your monetization plan depends on selling data, the App Store is not compatible with it.
Provide license info where required
If you make your VPN app available in a territory that requires a VPN license, Apple requires you to “provide your license information in the App Review Notes field.” Missing this in a regulated market is an avoidable rejection.
The Guideline 4.3 spam trap
Separately from 5.4, VPN apps frequently hit Guideline 4.3 (spam), because the store has many similar VPN apps. If your app looks like a thin reskin of a common template, it can be rejected as a duplicate or spam. The defense is genuine differentiation: a real brand, a distinct experience, and a clear reason your app exists. A rebranded template with nothing changed but the logo is the classic 4.3 casualty.
Google Play: The VpnService Policy
Google’s requirements live in the VpnService policy. Android VPN apps build on the VpnService API, and the policy governs how you are allowed to use it.
VPN must be the app’s core functionality
Google permits the device-level tunnel only for “apps that use the VpnService and have VPN as their core functionality.” You cannot bolt a VpnService onto an app whose real purpose is something else. The policy is explicit that picking an eligible store category is not by itself sufficient; the VPN has to be what the app is for.
You must submit a policy declaration (and usually a demo video)
Apps using VpnService must complete the VpnService declaration in Play Console. Google also asks for a short demonstration video (in the range of 90 seconds or shorter) showing the app opening and the VPN being used. Skipping the declaration is a direct path to rejection.
Prominent in-app disclosure and consent
If your app collects personal or sensitive data, Google requires prominent disclosure inside the app itself, displayed during normal use, with affirmative user consent. As with Apple, this is an in-app screen, not just a policy document.
No traffic manipulation, and encrypt the tunnel
The VpnService “cannot be used to redirect or manipulate user traffic from other apps on a device for monetization purposes,” and apps must encrypt data from the device to the VPN tunnel endpoint. Using the tunnel to inject ads or reroute other apps’ traffic for profit is a policy violation.
Foreground service requirements
Android requires a long-running VPN to run as a foreground service with a visible notification, and on Android 14 and later a declared foreground service type. Getting the service lifecycle wrong shows up as instability and can surface in review.
The Most Common Rejections, and How to Avoid Them
| Rejection cause | Store | How to avoid it |
|---|---|---|
| Individual developer account | Apple | Enroll as an organization before you build the listing |
| Missing data-disclosure screen | Both | Show a clear data-use screen before signup or connect |
| Data-selling SDKs (ads/analytics) | Apple | Remove SDKs that sell or share VPN data; commit to no-sale in your privacy policy |
| Looks like a template reskin | Apple (4.3) | Ship genuine differentiation, not a logo swap |
| No VpnService declaration / demo video | Complete the Play Console declaration and record the demo | |
| VPN not the core function | Make VPN the app’s actual purpose | |
| Missing VPN license info | Apple | Add license details in the App Review Notes for regulated territories |
| Unofficial tunneling method | Both | Build on NEVPNManager / NetworkExtension (iOS) and VpnService (Android) |
A Pre-Submission Checklist
Run this before you submit, on both stores:
- Apple Developer account enrolled as an organization (not individual).
- iOS app uses NetworkExtension with the Network Extension entitlement granted.
- In-app data-use disclosure screen shown before signup or connect.
- Privacy policy commits to not selling or sharing VPN data; no data-monetizing SDKs.
- No ad/analytics SDK that conflicts with Apple 5.4.
- Genuine differentiation so the app does not read as a 4.3 duplicate.
- VPN license info in App Review Notes for any regulated territory you target.
- Android app uses VpnService as core functionality, with tunnel encryption.
- VpnService declaration completed in Play Console, with the demo video.
- Android foreground service with the correct type for Android 14+.
- Prominent in-app disclosure and consent for any data collection.
- Extra time budgeted for review and a possible resubmission.
What to Do When You Are Rejected
Rejections happen even to careful teams. When one lands:
- Read the exact guideline cited. Apple and Google reference specific rules. The fix is almost always tied to that exact clause, not a general “make it better.”
- Do not just resubmit unchanged. Resubmitting the same build after a content rejection wastes a review cycle and can read as not engaging with the feedback.
- Use the resolution channels. Apple’s Resolution Center and the ability to reply or appeal exist for exactly this. A factual, specific reply that shows what you changed moves things along.
- Check the obvious VPN-specific causes first. Account type, the disclosure screen, data-selling SDKs, and the Play declaration cause most VPN rejections. Rule those out before assuming something exotic.
- Expect iteration. Especially on iOS, a VPN app may take more than one round. Plan the timeline so a second review does not blow your launch date.
FAQ
Why do VPN apps get rejected so often?
Because both stores treat VPN as a sensitive category with extra rules, and teams usually discover those rules only after submitting. The most common causes are using an individual rather than organization Apple account, missing the required in-app data-disclosure screen, including SDKs that sell or share data (which conflicts with Apple’s Guideline 5.4), looking like a template reskin, and skipping Google’s VpnService declaration. Almost all are avoidable with preparation.
Can I publish a VPN app under an individual Apple Developer account?
No. Apple’s Guideline 5.4 requires VPN services to be offered by developers enrolled as an organization, which needs a legal entity and a D-U-N-S number. Switching to an organization account is necessary, but it does not by itself guarantee approval if another requirement, such as the data-disclosure screen, is also unmet.
What does Google require for a VPN app?
Google’s VpnService policy requires VPN to be the app’s core functionality, the tunnel to be encrypted, a completed VpnService declaration in Play Console (usually with a short demo video), prominent in-app disclosure and consent for data collection, and no use of the tunnel to manipulate other apps’ traffic for monetization. Android 14 and later also require a declared foreground service type.
How long does VPN app review take?
There is no fixed number, and VPN apps tend to be reviewed more slowly than average because of the extra scrutiny. Plan for a longer review than a typical app and for the real possibility of at least one rejection and resubmission, especially on iOS. Build that buffer into your launch timeline.
Do ad-supported VPN apps pass review?
They can on Android within the policy limits, but Apple’s Guideline 5.4 prohibits selling, using, or disclosing VPN data to third parties, which rules out ad and analytics SDKs that monetize user data. If your business model depends on selling data, it is incompatible with the App Store. Subscription and in-app purchase models avoid this conflict.
Approval Is a Build Decision, Not a Submission Step
The teams that pass review on the first or second try are the ones who designed for the rules from the start: an organization account, the official APIs, an honest data-disclosure screen, no data-selling SDKs, genuine differentiation, and the Google declaration completed. The teams that get stuck are the ones who treated compliance as a final step. Approval is a build decision.
If you want a partner who builds VPN apps to meet these requirements and works through submission and rejections with you, DigitalD.tech does this as part of how we ship. For the broader build picture, see our guide on how much it costs to build a VPN app, and when you are ready, get in touch with your target platforms and markets.
