Ablehnung bei Google Play
Google verbietet keine Apps, die um eine WebView herum gebaut sind. Google verbietet Apps, die eine Website einpacken, die dem Entwickler nicht gehört, und Apps, die nichts bieten, was Nutzer nicht auch in Chrome bekämen. Wenn die Website deine ist, lässt sich diese Ablehnung beheben, meist mit einer einzigen erneuten Einreichung.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Zwei getrennte Teile der Play-Richtlinien führen zu dieser Ablehnung. Die Spam-Richtlinie erfasst Apps, deren Hauptzweck es ist, eine Website anzuzeigen, die der Entwickler nicht einpacken darf, Apps, die nur Affiliate-Traffic erzeugen sollen, Copy-Paste-Apps mit demselben Inhalt unter verschiedenen Namen sowie Apps ohne echte Funktion. Die Richtlinie Minimum Functionality (Mindestfunktionalität) verlangt, dass eine App sich installieren lässt, zuverlässig läuft und ein grundlegendes, ansprechendes Erlebnis bietet statt eines Platzhalters oder einer kaputten Seite.
Reviewer sehen viele Apps, die die Website von jemand anderem einpacken, deshalb wird eine WebView-App genauer geprüft als eine native. Deine Aufgabe ist es, zwei Dinge innerhalb von Sekunden offensichtlich zu machen: Die Website gehört dir, und die App ist besser, als die URL im Browser zu öffnen. Alles Folgende dient einem dieser beiden Ziele.
Entwicklername, App-Name, die Domain in der WebView, die URL der Datenschutzerklärung und die verifizierte Website in deinem Entwicklerprofil zeigen alle auf dieselbe Marke. Ein Reviewer sollte nie raten müssen, ob du diese Website einpacken darfst.
Kein Desktop-Header, kein Cookie-Banner, kein Footer mit Sitemap, keine „Installiere unsere App“-Leiste, kein Link, der eine zweite Kopie deiner Website öffnet. Stattdessen Bottom-Navigation, Buttons in voller Breite und ein schneller erster Seitenaufbau hinter dem Splash Screen.
Push-Benachrichtigungen, ein nativer Offline-Screen, das System-Share-Sheet, biometrische Sperre, QR-Scan oder App Links. Ein oder zwei echte native Funktionen, sinnvoll eingesetzt, ändern in den Augen des Reviewers die Kategorie der App.
Jeder Menüpunkt führt irgendwohin, Formulare lassen sich absenden, der Login funktioniert mit den Zugangsdaten, die du unter „App-Zugriff“ (App access) hinterlegt hast, und nirgends steht „coming soon“ oder „lorem ipsum“.
Arbeite alle sechs Punkte durch; die meisten abgelehnten Apps scheitern an zwei oder drei davon gleichzeitig.
In der Play Console kannst du eine Website mit deinem Entwicklerkonto verknüpfen und sie über die Google Search Console verifizieren (ein DNS-TXT-Eintrag oder eine HTML-Datei auf deiner Domain). Verwende dieselbe Domain, die die App lädt. Eine Preview-Domain von Lovable, Bolt oder Replit lässt sich nicht verifizieren, ein Grund mehr, vorher auf eine eigene Domain umzuziehen.
App-Name, Entwicklername, Store-Eintrag und Domain sollten eine gemeinsame Geschichte erzählen. „Acme Fitness“ von „Acme Fitness Ltd“, das app.acmefitness.com lädt, ist eindeutig. „Fitness Tracker Pro“ von „John“, das eine .lovable.app-Subdomain lädt, sieht aus wie ein Wrapper um das Produkt von jemand anderem.
Aktiviere Push mit PUSH_ENABLED (OneSignal) oder FIREBASE_PUSH_ENABLED, behalte den Offline-Fallback mit FALLBACK_USE_LOCAL_HTML_FOLDER_IF_OFFLINE bei und ergänze die In-App-Bewertungsabfrage mit SHOW_RATE_DIALOG. Nutze dann mindestens eine davon für einen echten Zweck in deiner Web-App, etwa Bestell-Updates oder Erinnerungen. Siehe die Android-Push-Dokumentation.
Nutze die Custom-CSS- und JavaScript-Injection, um Cookie-Banner, Desktop-Header und App-Store-Badges zu entfernen, wenn die Seite in WebViewGold geladen wird, oder setze einen eigenen USER_AGENT und erkenne ihn in deiner Web-App, um ein App-only-Layout zu rendern.
Wenn irgendein Teil der App hinter einem Login liegt, hinterlege funktionierende Demo-Zugangsdaten unter App-Inhalte → App-Zugriff (App content → App access) und beschreibe, was der Reviewer vorfinden wird. Ein Reviewer, der nicht über den Login-Screen hinauskommt, sieht eine App ohne Funktion.
Erhöhe den Version Code, baue in Android Studio oder im Cloud Builder neu und rolle erneut aus. Wenn du glaubst, dass der Reviewer schlicht übersehen hat, dass die Website dir gehört, lege zusätzlich einen Einspruch mit Nachweis ein, statt nur erneut einzureichen; der Einspruchs-Guide enthält eine Vorlage für genau diesen Fall.
Mein iOS WebView wurde endlich genehmigt. Danke!!
| Besteht den Review | Wird beanstandet | |
|---|---|---|
| Website-Besitz | Dein eigenes Produkt auf deiner eigenen Domain, im Entwicklerprofil verifiziert | Eine fremde Website, eine gescrapte Nachrichtenseite, ein Affiliate-Shop |
| Inhalt | Produkt, Tool oder Community mit Login und echten Nutzern | Eine Landingpage, ein Blog mit drei Beiträgen, ein Formular, das ins Leere führt |
| Layout | Mobile-first, App-artige Navigation, Safe-Area-bewusst | Desktop-Layout mit Pinch-to-Zoom, Cookie-Banner bei jedem Start |
| Native Funktionen | Push, Offline-Screen, Share Sheet, QR, Biometrie, sinnvoll genutzt | Keine, oder im Store-Eintrag angegebene Funktionen, die nicht vorhanden sind |
| Store-Eintrag | Screenshots aus der echten App, ehrliche Beschreibung | Screenshots der Website im Browser, generische Keywords |
Ja. Die Spam-Richtlinie zielt auf Apps, die eine Website ohne Erlaubnis oder ohne Mehrwert einpacken, nicht auf die WebView-Komponente selbst. Apps, die das eigene Produkt des Entwicklers mit nativen Funktionen einpacken, werden jeden Tag veröffentlicht.
Oft, in Kombination mit einem App-artigen Layout und einem vollständigen, funktionierenden Produkt. Reviewer betrachten das Gesamtbild; eine Push-Funktion, die aktiviert ist, aber nie genutzt wird, hilft weniger als eine, die sichtbar Teil des Produkts ist.
Eine Ablehnung wegen des technischen Wrappers selbst ist eine Nicht-Inhalts-Ablehnung und wird von der Genehmigungsgarantie abgedeckt, wenn sie innerhalb von 14 Tagen nach dem Kauf geltend gemacht wird. Eine Ablehnung, weil die eingepackte Website nicht dir gehört oder keinen echten Inhalt hat, ist ein Inhaltsproblem und nicht abgedeckt.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.
