Discovery & threat model
Threat model (who is the user defending against — ISP, advertiser, public Wi-Fi attacker), no-logs invariants, GDPR + CCPA posture mapping, App Store and Google Play VPN entitlement review.
Case study · Consumer Privacy · Mobile
LiMP — WireGuard consumer VPN for iOS and Android
How we shipped a production consumer VPN — App Store and Google Play, live across the United States and the European Union — built on WireGuard with a no-logs control plane, one-tap connect, and an audit-ready architecture that holds up to GDPR and CCPA scrutiny from day one.
The brief — a consumer VPN that holds up to audit
The LiMP product team wanted a consumer VPN that did not feel like a 2015 throwback to a chunky tray icon and a 90-second connection dance. The core insight was that the modern consumer privacy buyer in the United States and the European Union does not just want encryption — they want a defensible no-logs posture, a one-tap connect that finishes in under a second, and a server map they can actually understand. Existing white-label VPN SDKs failed two acceptance tests immediately: their bundles bloated the IPA and APK past App Store cellular-install thresholds, and their default logging configurations could not pass an independent privacy review. We built LiMP from first principles as a native iOS and Android application: a thin client wrapped around the WireGuard protocol, a Go control plane with a strict separation between billing identity and tunnel identity, and a server fleet that runs in RAM-only mode so seizure of a node yields no persistent state. The result is a consumer VPN that ships to App Store and Google Play, lives at limpvpn.com, and is positioned for audiences across the US and EU under GDPR and CCPA expectations from day one.
Project highlights
WireGuard tunneling end-to-end
Native iOS NetworkExtension
Native Android VpnService
No-logs control plane in Go
One-tap connect under one second
Server map with live latency
Kill switch & auto-reconnect
App Store + Google Play live · US & EU
By the numbers
A snapshot of what the LiMP build delivered across iOS, Android, and a hardened control plane in its first production cycle.
2native platforms — iOS and Android, fully separate codebases optimized per platform
<100mstypical WireGuard handshake on mobile LTE and Wi-Fi across US and EU networks
0persistent session logs — edge VPN nodes run in RAM-only mode by design
~4klines of reference WireGuard protocol code — auditable in a single afternoon
2app stores live — Apple App Store and Google Play across US and EU storefronts
12–18 wktypical delivery window for a comparable consumer VPN MVP on both stores
Why WireGuard over OpenVPN, IKEv2, and proprietary stacks
The protocol decision dominates every other architectural choice in a VPN build. We chose WireGuard over OpenVPN and IKEv2 because the trade-offs line up cleanly with a 2024-era greenfield consumer product. WireGuard's reference implementation is roughly 4,000 lines of code with a single modern cryptographic suite — Curve25519 for key exchange, ChaCha20-Poly1305 for symmetric encryption, BLAKE2s for hashing — and is auditable in a single afternoon. OpenVPN, by contrast, is a much larger codebase with negotiated cipher suites and a longer attack surface that any honest no-logs claim has to reason about. IKEv2 is mature and well-supported on iOS natively, but its session-resumption semantics on roaming devices are noisier than WireGuard's session-key model, which was designed for exactly the carrier-handoff scenarios mobile users hit every day.
Proprietary VPN stacks — the kind bundled with white-label SDKs — were eliminated early: their licensing terms required server-side telemetry the no-logs posture cannot tolerate, and their cryptographic primitives are frequently undocumented. Going with the WireGuard whitepaper protocol meant the entire stack — client tunnel, control plane, key rotation — is open and citable end-to-end.
| Dimension | WireGuard (LiMP) | OpenVPN | IKEv2 / proprietary |
|---|---|---|---|
| Protocol code size | ~4,000 lines — auditable in one sitting | ~70,000+ lines including OpenSSL surface | Large OS stack or vendor binary |
| Cryptographic suite | Fixed modern primitives — Curve25519, ChaCha20-Poly1305, BLAKE2s | Negotiated — broader attack surface | Vendor-defined; often opaque |
| Handshake latency (typical) | Under 100 ms on mobile LTE | Hundreds of ms — TLS handshake plus tunnel setup | Variable; IKEv2 fast, proprietary varies |
| Roaming behavior | Built-in via session keys — no tunnel restart | Tunnel restart required on network switch | MOBIKE on IKEv2; proprietary varies |
| Kernel integration (Linux) | Mainline since 5.6 — line-rate throughput | Userspace — slower at high throughput | Mixed kernel/userspace |
| App Store / Play Store fit | Thin wrapper over NetworkExtension / VpnService | Larger bundle; userspace dependencies | IKEv2 native-fit; proprietary SDK adds bulk |
| No-logs auditability | Stateless tunnel — peer config is the only state | Per-session state — must be actively suppressed | Vendor-controlled — opaque |
Protocol references: WireGuard whitepaper (Donenfeld), Apple NetworkExtension documentation, Android VpnService reference.
iOS build — Swift, NetworkExtension, and one-tap connect
The iOS client is built in Swift with SwiftUI for the UI layer and a Packet Tunnel Provider extension built on Apple's NetworkExtension framework. The entire user-facing surface collapses into a single state machine — idle, connecting, connected, reconnecting — and the home screen is one large tap target that drives it. Region selection lives one tap behind the connect button with a latency-sorted list cached locally so the picker never blocks on a network round-trip. The Packet Tunnel Provider hosts the WireGuard userspace implementation; the main app process only handles UI, billing state, and the IPC bridge into the extension.
The tap-to-connect path is where most consumer VPNs leak time, and where we spent disproportionate engineering effort. The flow is: tap, validate cached session token (no network round-trip if valid), spin up the Packet Tunnel Provider, hand it the peer configuration over the NETunnelProviderProtocol bridge, and let WireGuard's handshake complete. On typical US and EU mobile networks the entire path completes in under a second from the user's perspective. The same iOS client carries the kill-switch behavior the App Store reviewer expects — when the tunnel drops, all non-tunneled traffic is blocked at the NetworkExtension layer until the user explicitly disconnects. The end-to-end iOS surface is delivered as part of our mobile app development practice.
Android build — Kotlin, VpnService, and the server map
The Android client is written in Kotlin with Jetpack Compose for the UI and a foreground service built on Android's VpnService API. The foreground service is mandatory: on Samsung, Xiaomi, OnePlus, and Pixel device families, aggressive battery optimizers terminate background-only tunnel processes within minutes, breaking the auto-reconnect contract the user implicitly signs up for. The service displays a minimal persistent notification that keeps the tunnel process alive across Doze mode cycles, and WorkManager handles non-urgent operations — server-list refresh, telemetry counter flush, certificate rotation — with backoff semantics that respect battery saver states across Android 10 through Android 14.
The server map is where the Android client earns its keep. Users see a curated list of regions across the Netherlands, Germany, France, Sweden, Ireland, and the US East and US West coasts, with live RTT probes refreshing in the background and a favorites list pinned at the top. The recommendation engine runs client-side: when the device's DNS traffic pattern looks streaming-heavy, the map surfaces throughput-optimized nodes first; when latency dominates (gaming, video calls), low-RTT nodes float up. After a Wi-Fi to LTE carrier handoff the client restores the last working node automatically — WireGuard's roaming model makes this a session-key swap rather than a full tunnel rebuild. The same engineering team carries iOS and Android in lockstep as part of our iOS and Android engineering practice.
No-logs architecture, RAM-only nodes, and audit-ready posture
LiMP's stated no-logs posture was an architecture decision before it was a marketing claim. Edge VPN nodes — the boxes that actually carry user packets — run in RAM-only mode: their root filesystem is an ephemeral overlay, and a power cycle or seizure yields no persistent session state. The Go control plane sits on a separate hardened plane and holds only what it must: peer public keys, subscription entitlement, and a counter-only view of capacity per region. There is no per-user session table, no connection log, and no metadata pipe to a centralized observability stack. Counters are aggregated at the edge and shipped as anonymous numeric series; identifiers do not leave the node.
Billing identity is deliberately separated from tunnel identity. Payment records live in Stripe's vault under a customer ID the VPN nodes never see; the nodes only receive short-lived session tokens that map opaquely to entitlement. Infrastructure-as-code policies enforce the no-logs invariants — any pull request that would introduce a session log, a per-user trace, or a long-lived identifier in the tunnel plane fails CI. The posture is built to align with GDPR obligations for users in the European Union and CCPA / CPRA obligations for users in California and the broader United States — and to make a future independent no-logs readiness review a documentation exercise, not an architectural retrofit.
Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.
Delivery methodology
A five-phase build that took LiMP from product specification to production across iOS, Android, and a no-logs control plane.
Protocol & control plane
WireGuard protocol selection, Go control plane skeleton, peer-config generation, key rotation policy, Stripe-isolated billing identity, RAM-only edge node images.
Platform builds
Swift / SwiftUI iOS client on NetworkExtension Packet Tunnel Provider; Kotlin / Jetpack Compose Android client on VpnService; one-tap connect, kill switch, auto-reconnect.
Audit-ready hardening
Infrastructure-as-code policies that block logging regressions, RAM-only node provisioning, kill-switch and DNS-leak QA, third-party readiness assessment scaffolding.
Launch & telemetry
App Store + Google Play submission across US and EU storefronts, server-fleet rollout across the Netherlands, Germany, France, Sweden, Ireland, and US East / West.
Anonymous billing, subscription state, and the entitlement bridge
LiMP's monetization layer was built to keep payment identity and tunnel identity provably separate, because the no-logs claim falls apart the moment a single database joins a Stripe customer ID to a session token. The subscription tier is sold through Apple StoreKit on iOS, Google Play Billing on Android, and Stripe for the web checkout that hands an entitlement code back to the mobile clients. Server-side receipt validation runs against each store's verification endpoint and writes a single entitlement record keyed by an opaque, rotated identifier — never by Apple ID, Google account, or email address. Inside the VPN nodes, the only thing visible is a short-lived bearer token that maps to entitlement and expires aggressively; the node has no path back to a payment identity even if compromised. Kill switch behavior, auto-reconnect on network handoff, and per-app split-tunnel selection (Android) all read from the same entitlement record, so a single subscription state resolves cleanly across reinstalls, device swaps, and the eventual desktop client. The whole subsystem was built with extensibility in mind: adding a family plan, a multi-device entitlement, or a B2B tier with team management is a configuration change against the entitlement service, not a code release.
Launching across the United States and the European Union
LiMP launched on Apple App Store and Google Play with storefronts active across the United States and the European Union. The English-language build serves users in California, New York, Texas, Florida, and Washington in the US, and users in the Netherlands, Germany, France, Ireland, and Sweden in the EU, without a separate codebase per region. Consent flows are region-aware at the client layer: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for any optional product analytics; users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure in the same flow. Data-handling practices are aligned with GDPR for European users and with the US state-privacy patchwork — CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA. Because the no-logs architecture removes the per-user data the patchwork is most concerned with, regional compliance reduces to honest disclosure rather than per-jurisdiction data segregation.
The server fleet was rolled out across EU and US data centers in parallel — Netherlands, Germany, France, Sweden, and Ireland for EU coverage; US East and US West for North America — with each region's nodes provisioned identically from RAM-only images. The matching service that picks the lowest-RTT node per user runs stateless workers that can be pinned to EU or US regions independently for future data-residency commitments. Both the App Store age rating and the Google Play content rating were calibrated for the VPN feature set, and the in-app privacy policy was drafted to document exactly the architecture above, citing GDPR obligations and California CCPA obligations directly. The engineering team behind the build sits across CET and runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and incident response — the timezone that lets a US product team and an EU engineering team share four hours of live overlap every day.
Tech stack and roadmap
Swift
SwiftUI
NetworkExtension
Packet Tunnel Provider
Kotlin
Jetpack Compose
Android VpnService
WireGuard
Go
PostgreSQL
Redis
Stripe
Apple StoreKit
Google Play Billing
Docker
Kubernetes
Terraform
Prometheus
Grafana
The active custom software development roadmap for LiMP includes per-app split tunneling on Android (Pixel and Samsung first), a MultiHop relay tier for users who want a second-jurisdiction hop, an obfuscation transport for restrictive networks where vanilla WireGuard handshakes are blocked, and a desktop client built on Tauri to share business logic with the mobile codebase. A B2B tier with bring-your-own-domain, team management, and SSO is planned for US and EU small businesses, with the entitlement subsystem already structured for multi-seat assignment. Infrastructure plans include further server-fleet automation, an internal no-logs continuous-verification harness, and a future independent readiness assessment scaffolded into the cloud & DevOps roadmap.
Build a consumer VPN like this — talk to us
If you are planning a consumer VPN, a privacy-engineering product, or any mobile app where the no-logs claim has to survive an outside reviewer for audiences in the US and EU, we have shipped this stack end-to-end and can compress the build timeline meaningfully. The live product is available at limpvpn.com on iOS and Android, and the engineering team behind it sits inside YuSMP Group. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.
Frequently asked questions
How much does it cost to build a consumer VPN app like NordVPN or Mullvad?
A consumer VPN MVP covering iOS and Android clients with WireGuard tunneling, a basic control plane, and store submissions typically costs $120k–$260k. Adding a multi-region server fleet, kill switch, split tunneling, obfuscation transports, anonymous billing, and audit-ready logging policies brings a full-featured product to $300k–$650k. The dominant cost drivers are the server-fleet automation, the no-logs hardening work, and the App Store and Google Play review choreography around VPN entitlements.
Why use WireGuard instead of OpenVPN or IKEv2 for a new VPN app?
WireGuard is a roughly 4,000-line protocol with a single modern cryptographic suite (Curve25519, ChaCha20-Poly1305, BLAKE2s), while OpenVPN is a much larger codebase with negotiated cipher suites and a longer attack surface. WireGuard handshakes typically complete in under 100 ms, roaming between networks is built into the protocol via session keys rather than tunnel restarts, and the kernel-module implementation is in the mainline Linux kernel since 5.6. For a new build with no legacy clients, WireGuard is the lower-risk choice.
How do you build a true no-logs VPN architecture?
A defensible no-logs posture is an architecture decision, not a marketing claim. Edge VPN nodes run in RAM-only or ephemeral disk mode so a seizure yields no persistent state. The control plane separates billing identity from tunnel identity — Stripe holds the payment record, the VPN nodes only see short-lived session tokens. Connection events are aggregated to counters and discarded; no per-user session table exists. Infrastructure-as-code policies prevent accidental re-introduction of logging during incident response.
What are the App Store and Google Play rules for VPN apps?
Apple requires VPN apps to use the NetworkExtension framework with a Personal VPN or Packet Tunnel entitlement and to publish a clear privacy policy. Google Play requires VPN apps to use the VpnService API, declare the VPN purpose prominently, and pass additional permissions review. Both stores require functioning kill switch behavior, a transparent disclosure of any data collection, and — for apps serving EU and California users — a granular consent mechanism that satisfies GDPR and CCPA / CPRA in the same flow.
How long does it take to ship a VPN app on iOS and Android?
A focused MVP with WireGuard tunneling, a single-region server pool, one-tap connect, and both store submissions typically takes 12–18 weeks. Adding a multi-region server map with live latency, kill switch, split tunneling, and an obfuscation fallback transport adds 6–10 weeks. The audit-ready hardening pass — RAM-only nodes, infrastructure-as-code policy enforcement, third-party readiness assessment — is frequently underestimated and should be budgeted at 4–6 weeks of dedicated work.
Related cases
More mobile & consumer platform builds
PropTech · Real estate
ANT
PropTech marketplace + admin for residential developers — apartment-level inventory grids, multi-role workflows, US + EU data residency.
View case → Social · Consumer TechJoyJet
Native iOS + Android social platform with geo-radar discovery, real-time chat, and a virtual coin economy across US & EU.
View case → Industrial · ManufacturingREHAU
Enterprise digital tooling for a multinational manufacturer — partner portals, configurators, and EU + US deployment.
View case →Related services
Mobile App Development
Native iOS, Android, and cross-platform apps with store-ready release pipelines.
Learn more →
Custom Software Development
Custom platforms engineered to your business model, scaling cleanly from MVP to millions of users.
Learn more →
IT Staff Augmentation
Senior engineers embedded into your Jira and standups in two weeks. CET workday with US East Coast overlap.
Learn more →