Fallstudie · Consumer Privacy · Mobile
Wie wir ein produktionsreifes Consumer-VPN ausgeliefert haben — im App Store und bei Google Play, live in den USA und der Europäischen Union — gebaut auf WireGuard mit einer No-Logs-Control-Plane, One-Tap-Connect und einer prüfungsbereiten Architektur, die einer DSGVO- und CCPA-Prüfung von Tag eins an standhält.
Das LiMP-Produktteam wollte ein Consumer-VPN, das sich nicht wie ein Rückfall ins Jahr 2015 anfühlt — klobiges Tray-Icon und ein 90-sekündiger Verbindungstanz. Die zentrale Erkenntnis: Der moderne Consumer-Privacy-Käufer in den USA und der Europäischen Union will nicht nur Verschlüsselung — er will eine belastbare No-Logs-Haltung, einen One-Tap-Connect, der in unter einer Sekunde abgeschlossen ist, und eine Server-Karte, die er tatsächlich versteht. Bestehende White-Label-VPN-SDKs scheiterten sofort an zwei Abnahmetests: Ihre Bundles blähten die IPA und APK über die App-Store-Schwellen für Mobilfunk-Installationen hinaus auf, und ihre Standard-Logging-Konfigurationen konnten eine unabhängige Datenschutzprüfung nicht bestehen. Wir haben LiMP von Grund auf als native iOS- und Android-Anwendung entwickelt: einen schlanken Client um das WireGuard-Protokoll herum, eine Go-Control-Plane mit strikter Trennung zwischen Abrechnungsidentität und Tunnelidentität und eine Server-Flotte, die im RAM-only-Modus läuft, sodass die Beschlagnahme eines Knotens keinen persistenten Zustand liefert. Das Ergebnis ist ein Consumer-VPN, das im App Store und bei Google Play ausgeliefert wird, unter limpvpn.com lebt und von Tag eins an für Zielgruppen in den USA und der EU nach DSGVO- und CCPA-Anforderungen positioniert ist.
Eine Momentaufnahme dessen, was die LiMP-Entwicklung in ihrem ersten Produktionszyklus über iOS, Android und eine gehärtete Control-Plane geliefert hat.
Die Protokollentscheidung dominiert jede andere architektonische Wahl bei einer VPN-Entwicklung. Wir wählten WireGuard gegenüber OpenVPN und IKEv2, weil die Abwägungen sauber zu einem Greenfield-Consumer-Produkt der 2024er-Ära passen. WireGuards Referenzimplementierung umfasst rund 4.000 Codezeilen mit einer einzigen modernen kryptografischen Suite — Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die symmetrische Verschlüsselung, BLAKE2s für das Hashing — und ist an einem einzigen Nachmittag prüfbar. OpenVPN ist im Gegensatz dazu eine deutlich größere Codebasis mit ausgehandelten Cipher-Suites und einer größeren Angriffsfläche, mit der jede ehrliche No-Logs-Aussage umgehen muss. IKEv2 ist ausgereift und auf iOS nativ gut unterstützt, doch seine Session-Resumption-Semantik auf roamenden Geräten ist „lauter" als WireGuards Session-Key-Modell, das genau für die Carrier-Handoff-Szenarien entworfen wurde, denen mobile Nutzer täglich begegnen.
Proprietäre VPN-Stacks — die Art, die mit White-Label-SDKs gebündelt wird — schieden früh aus: Ihre Lizenzbedingungen verlangten serverseitige Telemetrie, die die No-Logs-Haltung nicht dulden kann, und ihre kryptografischen Primitive sind häufig undokumentiert. Die Wahl des WireGuard-Whitepaper-Protokolls bedeutete, dass der gesamte Stack — Client-Tunnel, Control-Plane, Schlüsselrotation — offen und durchgängig belegbar ist.
| Dimension | WireGuard (LiMP) | OpenVPN | IKEv2 / proprietär |
|---|---|---|---|
| Umfang des Protokollcodes | ~4.000 Zeilen — in einer Sitzung prüfbar | ~70.000+ Zeilen inklusive OpenSSL-Fläche | Großer OS-Stack oder Anbieter-Binary |
| Kryptografische Suite | Feste moderne Primitive — Curve25519, ChaCha20-Poly1305, BLAKE2s | Ausgehandelt — größere Angriffsfläche | Anbieterdefiniert; oft intransparent |
| Handshake-Latenz (typisch) | Unter 100 ms bei mobilem LTE | Hunderte ms — TLS-Handshake plus Tunnelaufbau | Variabel; IKEv2 schnell, proprietär variiert |
| Roaming-Verhalten | Eingebaut über Session-Keys — kein Tunnel-Neustart | Tunnel-Neustart beim Netzwechsel erforderlich | MOBIKE bei IKEv2; proprietär variiert |
| Kernel-Integration (Linux) | Mainline seit 5.6 — Line-Rate-Durchsatz | Userspace — langsamer bei hohem Durchsatz | Gemischt Kernel/Userspace |
| Eignung für App Store / Play Store | Schlanker Wrapper über NetworkExtension / VpnService | Größeres Bundle; Userspace-Abhängigkeiten | IKEv2 nativ-passend; proprietäres SDK erhöht Umfang |
| No-Logs-Prüfbarkeit | Zustandsloser Tunnel — Peer-Config ist der einzige Zustand | Zustand pro Session — muss aktiv unterdrückt werden | Anbieter-gesteuert — intransparent |
Protokoll-Referenzen: WireGuard-Whitepaper (Donenfeld), Apple-NetworkExtension-Dokumentation, Android-VpnService-Referenz.
Der iOS-Client ist in Swift mit SwiftUI für die UI-Schicht und einer Packet-Tunnel-Provider-Erweiterung gebaut, die auf Apples NetworkExtension-Framework basiert. Die gesamte nutzerseitige Oberfläche verdichtet sich in eine einzige State Machine — untätig, verbindend, verbunden, wiederverbindend — und der Startbildschirm ist ein großes Tap-Ziel, das sie steuert. Die Regionsauswahl liegt einen Tap hinter dem Connect-Button mit einer nach Latenz sortierten, lokal zwischengespeicherten Liste, sodass die Auswahl nie auf einen Netzwerk-Roundtrip wartet. Der Packet Tunnel Provider beherbergt die WireGuard-Userspace-Implementierung; der Haupt-App-Prozess übernimmt nur UI, Abrechnungszustand und die IPC-Brücke in die Erweiterung.
Der Tap-to-Connect-Weg ist die Stelle, an der die meisten Consumer-VPNs Zeit verlieren, und an der wir überproportionalen Engineering-Aufwand investiert haben. Der Flow lautet: tippen, das zwischengespeicherte Session-Token validieren (kein Netzwerk-Roundtrip, falls gültig), den Packet Tunnel Provider starten, ihm die Peer-Konfiguration über die NETunnelProviderProtocol-Brücke übergeben und WireGuards Handshake abschließen lassen. In typischen US- und EU-Mobilfunknetzen wird der gesamte Weg aus Sicht des Nutzers in unter einer Sekunde abgeschlossen. Derselbe iOS-Client trägt das Kill-Switch-Verhalten, das der App-Store-Reviewer erwartet — wenn der Tunnel abbricht, wird der gesamte nicht getunnelte Verkehr auf der NetworkExtension-Schicht blockiert, bis der Nutzer die Verbindung ausdrücklich trennt. Die durchgängige iOS-Oberfläche wird im Rahmen unserer Praxis der Mobile App-Entwicklung geliefert.
Der Android-Client ist in Kotlin mit Jetpack Compose für die UI und einem Foreground-Service geschrieben, der auf Androids VpnService-API basiert. Der Foreground-Service ist zwingend erforderlich: Bei den Gerätefamilien Samsung, Xiaomi, OnePlus und Pixel beenden aggressive Akku-Optimierer reine Hintergrund-Tunnelprozesse innerhalb von Minuten und brechen damit den Auto-Reconnect-Vertrag, den der Nutzer implizit eingeht. Der Service zeigt eine minimale persistente Benachrichtigung an, die den Tunnelprozess über Doze-Modus-Zyklen hinweg am Leben hält, und WorkManager übernimmt nicht dringende Vorgänge — Aktualisierung der Serverliste, Telemetrie-Zähler-Flush, Zertifikatsrotation — mit Backoff-Semantik, die Energiesparzustände über Android 10 bis Android 14 hinweg respektiert.
Die Server-Karte ist die Stelle, an der der Android-Client seinen Wert zeigt. Nutzer sehen eine kuratierte Liste von Regionen in den Niederlanden, Deutschland, Frankreich, Schweden, Irland sowie an der US-Ost- und US-Westküste, mit Live-RTT-Sonden, die im Hintergrund aktualisieren, und einer Favoritenliste, die oben angeheftet ist. Die Empfehlungs-Engine läuft clientseitig: Wenn das DNS-Verkehrsmuster des Geräts streaming-lastig wirkt, zeigt die Karte zuerst durchsatzoptimierte Knoten; wenn die Latenz dominiert (Gaming, Videoanrufe), steigen Knoten mit geringem RTT nach oben. Nach einem Carrier-Wechsel von WLAN zu LTE stellt der Client den zuletzt funktionierenden Knoten automatisch wieder her — WireGuards Roaming-Modell macht daraus einen Session-Key-Tausch statt eines vollständigen Tunnel-Neuaufbaus. Dasselbe Engineering-Team trägt iOS und Android im Gleichschritt als Teil unserer Praxis des iOS- und Android-Engineerings.
LiMPs erklärte No-Logs-Haltung war eine Architekturentscheidung, bevor sie eine Marketingaussage war. Edge-VPN-Knoten — die Maschinen, die tatsächlich Nutzerpakete tragen — laufen im RAM-only-Modus: Ihr Root-Dateisystem ist ein ephemeres Overlay, und ein Neustart oder eine Beschlagnahme liefert keinen persistenten Session-Zustand. Die Go-Control-Plane sitzt auf einer separaten gehärteten Ebene und hält nur das Nötigste: Peer-Public-Keys, Abonnement-Entitlement und eine reine Zähler-Sicht auf die Kapazität pro Region. Es gibt keine Session-Tabelle pro Nutzer, kein Verbindungs-Log und keine Metadaten-Leitung zu einem zentralisierten Observability-Stack. Zähler werden am Edge aggregiert und als anonyme numerische Reihen versendet; Identifikatoren verlassen den Knoten nicht.
Die Abrechnungsidentität ist bewusst von der Tunnelidentität getrennt. Zahlungsdatensätze liegen in Stripes Vault unter einer Customer-ID, die die VPN-Knoten nie sehen; die Knoten erhalten nur kurzlebige Session-Tokens, die intransparent auf das Entitlement abgebildet werden. Infrastructure-as-Code-Richtlinien erzwingen die No-Logs-Invarianten — jeder Pull-Request, der ein Session-Log, einen Trace pro Nutzer oder einen langlebigen Identifikator in der Tunnelebene einführen würde, fällt in der CI durch. Die Haltung ist darauf ausgelegt, mit den Verpflichtungen der DSGVO für Nutzer in der Europäischen Union und den Verpflichtungen des CCPA / CPRA für Nutzer in Kalifornien und den übrigen USA übereinzustimmen — und eine künftige unabhängige No-Logs-Bereitschaftsprüfung zu einer Dokumentationsaufgabe statt einer nachträglichen Architekturanpassung zu machen.
Compliance-Haltung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Eine fünfphasige Entwicklung, die LiMP von der Produktspezifikation bis zur Produktion über iOS, Android und eine No-Logs-Control-Plane führte.
Bedrohungsmodell (gegen wen verteidigt sich der Nutzer — ISP, Werbetreibender, Angreifer in öffentlichem WLAN), No-Logs-Invarianten, Mapping der DSGVO- + CCPA-Haltung, Prüfung der App-Store- und Google-Play-VPN-Entitlements.
WireGuard-Protokollauswahl, Go-Control-Plane-Grundgerüst, Peer-Config-Erzeugung, Schlüsselrotations-Richtlinie, Stripe-isolierte Abrechnungsidentität, RAM-only-Edge-Knoten-Images.
Swift- / SwiftUI-iOS-Client auf NetworkExtension Packet Tunnel Provider; Kotlin- / Jetpack-Compose-Android-Client auf VpnService; One-Tap-Connect, Kill-Switch, automatische Wiederverbindung.
Infrastructure-as-Code-Richtlinien, die Logging-Regressionen blockieren, Provisionierung von RAM-only-Knoten, QA für Kill-Switch und DNS-Leaks, Gerüst für die Bereitschaftsbewertung durch Dritte.
Einreichung im App Store + Google Play über US- und EU-Storefronts, Server-Flotten-Rollout in den Niederlanden, Deutschland, Frankreich, Schweden, Irland sowie an der US-Ost- / Westküste.
LiMPs Monetarisierungsschicht wurde so gebaut, dass Zahlungsidentität und Tunnelidentität nachweislich getrennt bleiben, denn die No-Logs-Aussage fällt in dem Moment in sich zusammen, in dem eine einzige Datenbank eine Stripe-Customer-ID mit einem Session-Token verknüpft. Die Abonnement-Stufe wird über Apple StoreKit auf iOS, Google Play Billing auf Android und Stripe für den Web-Checkout verkauft, der den Mobile-Clients einen Entitlement-Code zurückgibt. Die serverseitige Beleg-Validierung läuft gegen den Verifizierungs-Endpunkt jedes Stores und schreibt einen einzigen Entitlement-Datensatz, der durch einen intransparenten, rotierten Identifikator referenziert wird — niemals durch Apple-ID, Google-Konto oder E-Mail-Adresse. Innerhalb der VPN-Knoten ist das einzig Sichtbare ein kurzlebiges Bearer-Token, das auf das Entitlement abgebildet wird und aggressiv abläuft; der Knoten hat selbst bei Kompromittierung keinen Weg zurück zu einer Zahlungsidentität. Kill-Switch-Verhalten, automatische Wiederverbindung beim Netzwechsel und die Per-App-Split-Tunnel-Auswahl (Android) lesen alle aus demselben Entitlement-Datensatz, sodass ein einziger Abonnementstatus über Neuinstallationen, Gerätewechsel und den künftigen Desktop-Client hinweg sauber aufgelöst wird. Das gesamte Teilsystem wurde mit Blick auf Erweiterbarkeit gebaut: Das Hinzufügen eines Familientarifs, eines Multi-Geräte-Entitlements oder einer B2B-Stufe mit Teammanagement ist eine Konfigurationsänderung am Entitlement-Service, kein Code-Release.
LiMP startete im Apple App Store und bei Google Play mit aktiven Storefronts in den USA und der Europäischen Union. Die englischsprachige Umsetzung bedient Nutzer in Kalifornien, New York, Texas, Florida und Washington in den USA sowie Nutzer in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU, ohne eine separate Codebasis pro Region. Die Einwilligungs-Flows sind auf der Client-Schicht regionsbewusst: Nutzer in der EU und im EWR erhalten einen granularen Einwilligungsbildschirm im DSGVO-Stil mit separaten Schaltern für optionale Produkt-Analytics; Nutzer in Kalifornien erhalten im selben Flow eine Offenlegung im CCPA-Stil „Do Not Sell or Share My Personal Information". Die Praktiken zur Datenverarbeitung sind an der DSGVO für europäische Nutzer und am Flickenteppich der US-Bundesstaaten-Datenschutzgesetze ausgerichtet — CCPA/CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Da die No-Logs-Architektur die nutzerbezogenen Daten entfernt, die diesen Flickenteppich am meisten beschäftigen, reduziert sich die regionale Compliance auf ehrliche Offenlegung statt auf datenrechtliche Segregation pro Rechtsraum.
Die Server-Flotte wurde parallel über EU- und US-Rechenzentren ausgerollt — Niederlande, Deutschland, Frankreich, Schweden und Irland für die EU-Abdeckung; US-Ost und US-West für Nordamerika — wobei die Knoten jeder Region identisch aus RAM-only-Images provisioniert wurden. Der Matching-Service, der den Knoten mit dem geringsten RTT pro Nutzer auswählt, betreibt zustandslose Worker, die für künftige Datenresidenz-Zusagen unabhängig an EU- oder US-Regionen gebunden werden können. Sowohl die App-Store-Altersfreigabe als auch die Google-Play-Inhaltsbewertung wurden auf das VPN-Funktionsset abgestimmt, und die In-App-Datenschutzrichtlinie wurde so verfasst, dass sie genau die obige Architektur dokumentiert und direkt auf die DSGVO-Verpflichtungen und die CCPA-Verpflichtungen Kaliforniens verweist. Das Engineering-Team hinter der Entwicklung sitzt in der MEZ-Zeitzone und arbeitet einen MEZ-Arbeitstag mit Überlappung zur US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie der Store-Reviews und Incident-Response — die Zeitzone, die es einem US-Produktteam und einem EU-Engineering-Team ermöglicht, jeden Tag vier Stunden Live-Überlappung zu teilen.
Die aktive Roadmap der individuellen Softwareentwicklung für LiMP umfasst Per-App-Split-Tunneling auf Android (Pixel und Samsung zuerst), eine MultiHop-Relay-Stufe für Nutzer, die einen Hop über eine zweite Jurisdiktion wünschen, einen Obfuskations-Transport für restriktive Netze, in denen normale WireGuard-Handshakes blockiert werden, und einen auf Tauri gebauten Desktop-Client, der die Geschäftslogik mit der Mobile-Codebasis teilt. Eine B2B-Stufe mit eigener Domain, Teammanagement und SSO ist für kleine Unternehmen in den USA und der EU geplant, wobei das Entitlement-Teilsystem bereits für die Mehrplatz-Zuweisung strukturiert ist. Die Infrastrukturpläne umfassen eine weitere Automatisierung der Server-Flotte, ein internes Harness zur kontinuierlichen No-Logs-Verifizierung und eine künftige unabhängige Bereitschaftsbewertung, eingebettet in die Roadmap von Cloud & DevOps.
Wenn Sie ein Consumer-VPN, ein Privacy-Engineering-Produkt oder eine beliebige Mobile-App planen, bei der die No-Logs-Aussage einem externen Prüfer für Zielgruppen in den USA und der EU standhalten muss, haben wir diesen Stack durchgängig ausgeliefert und können den Entwicklungszeitraum spürbar verkürzen. Das Live-Produkt ist unter limpvpn.com auf iOS und Android verfügbar, und das dahinterstehende Engineering-Team ist Teil der YuSMP Group. Wir arbeiten zum Festpreis für klar umrissene MVPs und mit dedizierten Entwicklerteams für die laufende Auslieferung, mit einem MEZ-Arbeitstag und einem garantierten Zeitfenster der Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Response.
Ein Consumer-VPN-MVP mit iOS- und Android-Clients samt WireGuard-Tunneling, einer grundlegenden Control-Plane und Store-Einreichungen kostet typischerweise 120.000–260.000 $. Mit einer Multi-Region-Server-Flotte, Kill-Switch, Split-Tunneling, Obfuskations-Transporten, anonymer Abrechnung und prüfungsbereiten Logging-Richtlinien erreicht ein voll ausgestattetes Produkt 300.000–650.000 $. Die maßgeblichen Kostentreiber sind die Automatisierung der Server-Flotte, die No-Logs-Härtungsarbeit und die Choreografie der App-Store- und Google-Play-Reviews rund um die VPN-Entitlements.
WireGuard ist ein Protokoll mit rund 4.000 Zeilen und einer einzigen modernen kryptografischen Suite (Curve25519, ChaCha20-Poly1305, BLAKE2s), während OpenVPN eine deutlich größere Codebasis mit ausgehandelten Cipher-Suites und einer größeren Angriffsfläche ist. WireGuard-Handshakes werden typischerweise in unter 100 ms abgeschlossen, das Roaming zwischen Netzwerken ist über Session-Keys statt Tunnel-Neustarts ins Protokoll eingebaut, und die Kernel-Modul-Implementierung ist seit Version 5.6 im Mainline-Linux-Kernel. Für eine Neuentwicklung ohne Legacy-Clients ist WireGuard die risikoärmere Wahl.
Eine belastbare No-Logs-Haltung ist eine Architekturentscheidung, keine Marketingaussage. Edge-VPN-Knoten laufen im RAM-only- oder ephemeren Disk-Modus, sodass eine Beschlagnahme keinen persistenten Zustand liefert. Die Control-Plane trennt die Abrechnungsidentität von der Tunnelidentität — Stripe hält den Zahlungsdatensatz, die VPN-Knoten sehen nur kurzlebige Session-Tokens. Verbindungsereignisse werden zu Zählern aggregiert und verworfen; es existiert keine Session-Tabelle pro Nutzer. Infrastructure-as-Code-Richtlinien verhindern die versehentliche Wiedereinführung von Logging während der Incident-Response.
Apple verlangt, dass VPN-Apps das NetworkExtension-Framework mit einem Personal-VPN- oder Packet-Tunnel-Entitlement nutzen und eine klare Datenschutzrichtlinie veröffentlichen. Google Play verlangt, dass VPN-Apps die VpnService-API nutzen, den VPN-Zweck deutlich angeben und eine zusätzliche Berechtigungsprüfung durchlaufen. Beide Stores verlangen ein funktionierendes Kill-Switch-Verhalten, eine transparente Offenlegung jeglicher Datenerhebung und — für Apps, die EU- und kalifornische Nutzer bedienen — einen granularen Einwilligungsmechanismus, der DSGVO und CCPA / CPRA im selben Flow erfüllt.
Ein fokussiertes MVP mit WireGuard-Tunneling, einem Single-Region-Server-Pool, One-Tap-Connect und Einreichungen in beiden Stores dauert typischerweise 12–18 Wochen. Eine Multi-Region-Server-Karte mit Live-Latenz, Kill-Switch, Split-Tunneling und einem Obfuskations-Fallback-Transport fügt 6–10 Wochen hinzu. Der prüfungsbereite Härtungsdurchlauf — RAM-only-Knoten, Durchsetzung von Infrastructure-as-Code-Richtlinien, Bereitschaftsbewertung durch Dritte — wird häufig unterschätzt und sollte mit 4–6 Wochen dedizierter Arbeit eingeplant werden.
Verwandte Fallstudien
PropTech-Marktplatz + Admin für Wohnbauträger — Inventarraster auf Wohnungsebene, Multi-Rollen-Workflows, US- + EU-Datenresidenz.
Fallstudie ansehen → Social · Consumer TechNative iOS- + Android-Social-Plattform mit Geo-Radar-Entdeckung, Echtzeit-Chat und einer virtuellen Coin-Ökonomie für USA & EU.
Fallstudie ansehen → Industrie · FertigungEnterprise-Digitalwerkzeuge für einen multinationalen Hersteller — Partnerportale, Konfiguratoren und EU- + US-Deployment.
Fallstudie ansehen →
Native iOS-, Android- und plattformübergreifende Apps mit store-fertigen Release-Pipelines.
Mehr erfahren →
Individuelle Plattformen, die auf Ihr Geschäftsmodell zugeschnitten sind und sauber vom MVP bis zu Millionen Nutzern skalieren.
Mehr erfahren →
Senior-Entwickler in zwei Wochen in Ihr Jira und Ihre Stand-ups eingebunden. MEZ-Arbeitstag mit Überlappung zur US-Ostküste.
Mehr erfahren →