A branded VPN app is not a to-do list with a lock icon. Apple treats it as a Network Extension product. Google treats it as a VPN service that must be declared. Both will read your privacy labels like a contract. If the binary, the labels, and the screenshots tell three stories, you will sit in rejection while your ads spend.
I have sat in that queue. Panic is useless. Patterns are useful. Most rejections I see on partner brands are not 'Apple hates VPNs.' They are mismatched metadata, vague VPN configuration descriptions, missing declarations, or a listing that sounds like a traffic-stealing utility. The Guideline text is public. People still improvise.
This is not a fear piece and it is not a guarantee you will pass. Policies move. Reviewers differ. I will show you the failure modes that repeat, and the boring packet of materials that shortens the loop. Klox white-label still ships under your developer accounts when you want a real brand. That means you own this paperwork. Reseller skips it because users install Klox. Different product.
If you are launching on a 14-day fantasy calendar, put store review on the critical path on day one, not day twelve.
I wrote this for operators who already decided they want a branded client. If you do not want the paperwork, resell Klox and send people to our listings. That is a valid motion. It is not a lesser motion. It is a different ownership story, and it skips this queue on purpose.
Related reading: Alpn: Not a VPN Setting and White-Label VPN and 14 Day Launch Checklist. Apple VPN Entitlements for a White-Label Brand and White-Label VPN and Pinpoint. What is a VPN? and Download KloxVPN.
Looking for a reliable VPN?
KloxVPN — from $2.83/month. Apps for every device.
Why VPN apps get a harder read
A VPN can see user traffic. Stores know that. They also know the category is full of junk: ad injectors, fake 'cleaner' VPNs, and apps that ask for a tunnel they do not need. You inherit that reputation even if your brand is clean. The way out is specificity. Say what the tunnel is for. Say what you collect. Do not dress a consumer privacy client as an enterprise MDM, and do not dress a tunnel as a 'web accelerator' if you are not one.
PowerCert's explainer video is a decent primer for non-engineers on what a VPN even is. It will not write your review notes. You still have to.
- 1Skim the seating / order diagram.
- 2Do the numbered steps once on your real network.
- 3Use the FAQ if a sentence was too long.
- 4Follow one related article — not ten tabs.
How to read this page
| Pattern | Where it shows up | What the reviewer is sniffing for | What usually fixes it |
|---|---|---|---|
| Vague Network Extension purpose | iOS entitlement / review notes | Is this a real VPN or a hijack? | Plain-language: encrypt device traffic to operator nodes |
| Nutrition label vs SDK reality | App Privacy / data safety | Crash reporter, payments, analytics | Align labels with every SDK, not the homepage |
| VPN config description as marketing | iOS VPN payload strings | User consent and honesty | Describe the hop, not the lifestyle |
| Missing Play VPN declaration | Play Console declarations | Undeclared VpnService | Declare and justify before rollout |
| Screenshots that overclaim | Listing graphics | Guarantees you cannot keep | Show the app you shipped |
If your review notes would embarrass you in front of a careful user, they will embarrass you in front of a reviewer.
— KloxVPN operator notes
Apple App Store Review Guidelines
Guideline 5.4 is not a rumor
Apple's Review Guidelines include a VPN Apps section (5.4 in the current public text). Read the live page, not a 2019 screenshot. The spirit is consistent: the app should be a VPN, it should not abuse the extension for ads or unrelated tracking, and it should be clear to the user. If your binary uses the extension as a cheap always-on hook for something else, you are in a different, worse category. Do not do that on a Klox-branded partner build. We will not help you invent it.
Play's VPN rules are a declaration problem first
Google's VPN policy page is the other tab you keep open. If you ship VpnService, you declare it. If you do not declare it, you are asking for a policy strike. If you declare it and the store listing sounds like a game with a hidden tunnel, you are also asking for a strike. Consistency is the whole job.
Apple Network Extension, entitlements, and the physical phone
Network Extension is gated. You request the entitlement. Apple grants it to the team, not to your optimism. A simulator demo that 'connects' is not evidence. Reviewers and you both need a build that brings up a packet tunnel on a device. If the entitlement is missing, the user sees a dead toggle. If the entitlement is present but your review notes cannot explain why, you stall.
I treat the entitlement letter and the review notes as one packet. Same words. Same purpose.
Purpose strings that sound like a crime
Do not write that you 'intercept all traffic to optimize the web experience and personalize content.' That is how you get read as adware. Write that the app establishes a VPN tunnel to the operator's servers so the user's internet traffic is encrypted in transit. If you have split tunnel, say the user can exclude apps. If you do not, do not imply you do.
Personal vs company developer accounts
A serious brand should be on an organization account that matches the legal entity on the site. Personal accounts plus a DBA on the listing create review questions and later transfer pain. Do this before you schedule a launch tweet. DUNS and entity matching eat calendar, not CPU.
Test accounts and a reproducible path
Give a reviewer an account that works without a credit card dance, or a clearly documented demo mode. If login requires a magic SMS to a number in your pocket, you will fail for 'we could not access the app.' This is the dumbest rejection and also the most common after metadata mismatches. Put the credentials in App Review Information. Put them again in notes. I have watched people hide them in a PDF nobody opened.
Privacy nutrition labels that do not match the binary
The label is not a brand exercise. It is a list of data types and purposes tied to what the app and its SDKs actually do. Payments, crash reporting, optional analytics, support chat: each one can create a 'yes we collect' that your homepage forgot. Reviewers and users can both spot a 'Data Not Collected' claim next to a crash SDK that sends device model and email.
No-logs positioning on the VPN path does not mean the account path is empty. Say what the account path holds.
Inventory SDKs like you inventory servers
Export the Gradle/Cocoa dependency list. For each SDK, write: data types, purpose, linked vs not linked, used for tracking or not. If you cannot fill the row, the SDK does not ship. This is slower than letting a contractor 'just add Firebase.' It is also how you avoid a week of 'Guideline 5.1.1' style back-and-forth.
Tracking is a word with a store meaning
Apple's tracking definition is not your blog's definition. ATT prompts, third-party advertising, and data sold to data brokers are the hot zone. A consumer VPN brand that also drops a behavioral ad SDK is asking for pain and for user distrust. I would rather you run ads on the web and keep the client quiet. If you insist on in-app attribution, staff the privacy form like an adult.
Privacy policy URL must resolve and match
A 404 policy is an instant own-goal. A policy that names a different company than the seller is the ownership problem from the other article, now inside review. Host it on your domain. Date it. If you change SDKs, change the policy in the same release.
VPN configuration descriptions users actually see
iOS will show system UI around VPN configuration. The description is not a tagline. If you write 'Ultimate stealth browsing, military grade, unblock everything,' you look like every spam listing from 2017. Write the hop: this configuration routes device traffic through a VPN operated by [Brand] so it is encrypted between your device and the VPN server.
Users who are already nervous will read this on a system screen. Reviewers will too. Hype here is a defect.
On-demand and always-on need extra honesty
If the tunnel can start without a tap because of an on-demand rule, say so in the app before you install the profile. Surprise tunnels feel like malware even when they are a feature. Reviewers have seen the malware version. They are allowed to be suspicious.
Local network and other extra permissions
Only request what the client needs. Local network, local notifications, background modes: each one is a question. A VPN needs network. It does not automatically need contacts, photos, or Bluetooth. If a library added a permission you cannot explain, remove the library.
Google Play VPN declarations and data safety
Play Console wants a VPN declaration and a Data safety form. Treat them as one story with Apple's labels, even if the taxonomies differ. If Play says you collect approximate location because a library grabs it, either drop the library or declare it. 'But we do not use it' is not a strategy if the code still can.
The policy page I linked is the source. Your contractor's memory of 2022 is not.
VpnService without a user-facing VPN is a red flag
If the app is a game that brings up a tunnel to mess with routing, you are in a different policy bucket. Branded Klox partner apps should be VPNs. Full stop. Do not hide a tunnel inside a 'security suite' that also wants accessibility services and device admin. That pattern is how entire developer accounts die.
Closed testing is not optional for new accounts
New Play accounts live under production-access rules that change. You may need a closed test with real testers before production. Budget that. A white-label calendar that assumes 'upload Friday, live Saturday' is a fiction for new publishers.
Signing keys are ownership
Play App Signing, upload keys, backup of the keystore if you still hold one. If the agency holds the key, they hold your update path. Same sermon as Apple team ID. Put secrets in a company vault. Two people. Hardware keys where you can.
Screenshots, copy, and the overclaim trap
Listings get rejected or later flagged for claims the app cannot keep: '100% anonymous,' 'undetectable,' 'no logs' next to a screenshot of a detailed connection calendar you actually shipped. If you position no-logs, the UI should not look like a surveillance product. If you show a server map, show cities you actually offer on that brand. Invented dots are how you earn a user-trust problem even if review misses it.
I do not want partner listings that dunk on named consumer brands with fake newsroom scores. We will not do that on Klox properties either.
Ratings and 'editor' badges you did not earn
Do not put fake review-site medals in screenshots. Stores have seen that scam. Use your own UI. If you quote a third party, be ready to prove it. Most small brands should just show the connect screen and the server list.
Localization mismatches
A German listing that promises a feature the English binary does not have is still a lie. Translate what you shipped. Machine-translated legal claims are how you invent a warranty.
The rejection loop and how to exit it
Rejection 1: vague purpose. You rewrite. Rejection 2: privacy form. You inventory SDKs. Rejection 3: reviewer could not log in. You add credentials. Each cycle is days to a week. The way out is to send a complete packet the first time: notes, demo account, video of a successful connect on a physical device, policy URLs, and a short explanation of the tunnel that a tired person can follow.
Do not argue philosophy in Resolution Center. Argue facts. Attach the screenshot of the working tunnel.
When to appeal versus when to change the app
Appeal if they missed a provided demo account or cited a guideline that does not match the binary. Change the app if they found a real permission or a real claim problem. Ego appeals waste the only resource you cannot purchase: calendar time before a campaign.
Version numbers and the 'same binary' trap
If you only change metadata, say so. If you change the binary, increment and note what changed. Reviewers are humans in a queue. Help them. A novel in the notes is worse than a ten-line diff summary plus a two-minute video.
White-label submissions versus first-party Klox
Klox consumer apps already live on stores. Your branded apps are a new listing with a new team. You inherit none of our review history. That surprises people. You also inherit our technical stack inside the binary, which is the point of white-label, but the reviewer sees your name. Your notes should not say 'this is just a reskin of a famous VPN' as a personality. They should say what the app does, who operates the service, and how to test it.
Reseller partners do not submit a branded client. If your plan depends on a store icon with your mascot, you are in white-label, and this article is your homework.
Who writes the notes
The partner should approve every sentence that names data practices. We can help with technical test steps. We cannot invent your legal identity. If your privacy counsel has not read the form, do not ship the form.
Shared backends and what to disclose
You do not need a packet-capture essay in the listing. You do need terms that do not claim you rack every node if you do not. Review notes can be plain: the app connects to VPN infrastructure operated with our platform partner. If your counsel wants different words, use theirs, as long as they are true.
A submission packet that is not theater
Here is the folder I want before anyone hits Submit. Legal name and DUNS. Organization developer account. Entitlement grant. Privacy policy and terms URLs that load. Data-safety / nutrition forms filled from an SDK inventory. Demo account. Two-minute video: install, login, connect, browse a page, disconnect. Review notes under 400 words. Screenshot set that matches the build. Support URL that is not a Google Doc set to private.
If an item is missing, you are not late because of Apple. You are late because the folder is empty. I have watched teams polish a launch film while the privacy policy still 404s. The film does not get you through review. The folder does.
Put a named owner on the folder. Not 'the contractor.' A person at the company that owns the brand. When review asks a question at 6 p.m. on a Friday, that person answers. If the only person who can answer is on a plane, you just added a weekend to the queue.
Video beats poetry
A reviewer who can see a tunnel go green will forgive slightly stiff copy. A reviewer who cannot get in will not read your manifesto. Record on a clean device. Show the status in Settings that proves a VPN configuration exists. That one frame saves arguments.
Internal QA before the queue
Test: fresh install, expired session, bad password, airplane mode, sleep/wake, split tunnel if you have it, IPv6 leak test, DNS leak test. You do not need to paste leak-test URLs into the listing. You need to not ship a client that fails them the day after you get featured in a Discord.
Common packet holes I still see
Support URL behind a login. Privacy policy that still says 'your company name here.' Screenshots from a different app skin. A demo password that expired last Tuesday. Review notes that argue with the guideline instead of showing a tunnel. Fix those five and you will beat half the branded VPN submissions I have watched fail twice.
Updates that re-trigger the whole circus
A 'tiny' SDK bump can reopen privacy questions. A new permission will. A new in-app purchase will. Treat every release as a chance to re-read the forms. Assign a human, not a hope. The cost of a broken update is review delay plus users stuck on a crashing build while you wait.
TLS and library CVEs (control plane included; RFC 8446 is the TLS 1.3 world your stacks live in) will force updates on someone else's schedule. That is ops. Budget it.
Phased rollout is your friend on Play
Roll to 5% and watch crash-free sessions. A VPN client that crashes on connect is worse than a late feature. Halt. Fix. Then go to 100%. Macho 100% rollouts are how you spend a weekend.
iOS phased release plus a kill switch for features
If you can remotely disable a new experimental setting, do. Do not remotely disable the tunnel for everyone as a 'feature flag' joke. People will think they were hacked.
Desktop stores and sideload are not an escape hatch
Founders who get tired of Apple sometimes say they will 'just do Android and a website.' That is a product with a hole. Households are mixed. The person who pays often has an iPhone. If your brand is missing there, they will install a competitor before they will sideload your IPA. Microsoft Store and macOS notarization have their own queues. They are usually kinder than Network Extension review, and they still need signing, privacy text, and a build that does not trip Gatekeeper.
Sideload is a power-user path. It is not a launch plan for a consumer brand that wants paid ads. Ads send people to store listings. If the listing is empty, the ad is a donation.
Windows SmartScreen and Authenticode
A fresh code-signing certificate looks unknown. Users see a scary blue or yellow wall. You either wait for reputation, use an EV certificate, or eat the support tickets from people who think you are malware. Budget weeks, not hours. A white-label Windows build still needs this if you want a brand that looks like software, not like a zip from an email.
macOS notarization and system extensions
Notarization is a gate. A VPN client that installs a system extension will get extra questions from the OS and from users who have to click through. Document the clicks. Record a video. If you skip this, your 'Mac support' is a README that only your engineer can follow. That engineer will become your only support agent for Mac, which is how burnout starts.
Enterprise MDM is a different store
If your actual customer is a company that will push a profile, you are not in consumer review. You are in a contract and a device-management conversation. Do not mix that path into a consumer listing to dodge 5.4. Reviewers have seen the dodge. Use /contact for that shape, and keep the consumer listing honest.
When to pause the listing and rewrite
If you have two rejections on claims, stop swapping adjectives. Rewrite the product story: what the app is, who it is for, what it is not. Remove the junk SDKs. Align the policy. Then resubmit. Three cosmetic resubmits in ten days looks like you are guessing. Reviewers can see the pattern.
If your category is wrong (you filed as a game, you are a VPN), fix the category. I wish this were rare. It is not.
Account-level risk
Repeated policy strikes are worse than one rejected build. New Play accounts are fragile. Do not use the same account to experiment with a second, sketchier app. Do not purchase 'aged' accounts. That marketplace is a swamp and a way to lose the brand you just printed.
What I tell partners on a 14-day plan
Start store setup on day one. Submit a boring, complete packet. Run web checkout and desktop clients if you must launch a campaign before iOS is live. Do not spend the entire ad budget on a store URL that is still in review. That is not a review problem. That is a media-plan problem.
Key Takeaways
Branded VPN apps fail review in clusters: entitlements and purpose text, privacy forms that ignore SDKs, configuration copy that sounds like a 2017 ad, missing Play declarations, and demo accounts that do not work. None of that is mysterious if you read Apple's guidelines and Google's VPN policy on the same afternoon.
Own the developer accounts. Inventory the SDKs. Record a two-minute connect video. Write like a person who expects a tired reviewer. Leave the lifestyle slogans on the website if you must, not in the system VPN screen.
White-label means this homework is yours. Reseller means users already have a Klox listing. Pick the motion that matches whether you want a store icon with your name on it. When you do, talk to us about white-label with the submission folder already started, not with a launch date and an empty App Store Connect.
Related Resources
Ship a listing that matches the binary
White-label puts your brand on the Klox network and on your store accounts. We can help with test steps. You still own the privacy form.
Talk to us about white-labelFrequently Asked Questions
KloxVPN Team
Experts in VPN infrastructure, network security, and online privacy. The KloxVPN team has been building and operating VPN services since 2019, providing consumer and white-label VPN solutions to thousands of users worldwide.