Ablehnung bei Google Play
Google hat das Release abgelehnt, weil der Reviewer nicht über deinen Login-Screen hinausgekommen ist. In der App ist nichts kaputt; der Reviewer hatte schlicht keinen funktionierenden Zugang. Lege in der Play Console unter Anmeldedaten (Sign-in details, in älteren Anleitungen App-Zugriff) einen wiederverwendbaren Testaccount an, sorge dafür, dass er ohne Einmalcodes und E-Mail-Links auskommt, und reiche erneut ein.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Die Reviewer von Google müssen alles sehen können, was deine App tut. Ist ein Teil davon durch einen Login, eine Mitgliedschaft, einen Standort oder eine andere Form der Authentifizierung eingeschränkt, musst du ihnen alles geben, was sie für den Zugang brauchen: Test-Zugangsdaten, einen Demo-Account oder eine Anleitung für Codes und andere Sonderfälle. Das trägst du in der Play Console unter Richtlinie und Programme → App-Inhalte → Anmeldedaten (Sign-in details) ein. Ältere Anleitungen, Forenbeiträge, manche Hinweise und die deutsche Google-Hilfe nennen den Abschnitt noch App-Zugriff (App access); gemeint ist dasselbe. Du kannst bis zu fünf Anleitungen hinterlegen, jede mit den Login-Daten und einem Feld Weitere Informationen (Any other instructions) für alles, was an deinem Login ungewöhnlich ist.
Die Anforderungen von Google an die Anmeldedaten sind kurz und streng. Die Zugangsdaten müssen jederzeit verfügbar, wiederverwendbar, aus jedem Land gültig, dauerhaft funktionsfähig und auf Englisch sein (oder eine englische Version mitliefern). Braucht dein Login normalerweise ein Einmalpasswort oder einen zweiten Faktor, musst du Zugangsdaten bereitstellen, die diesen Schritt überspringen. Ein Login per QR-Code braucht stattdessen eine statische URL, und Inhalte hinter einer Paywall brauchen eine Anleitung, mit der der Reviewer den bezahlten Teil frei nutzen kann. Ein Passwort, das während des Reviews abläuft, kann zur Ablehnung führen.
Der Eintrag im Richtlinienstatus trägt meist einen Titel in der Art von Need login credentials for app review. Er erklärt, dass der Reviewer nicht auf die ganze App oder auf Teile davon zugreifen konnte, und bittet um einen aktiven Demo-Account plus alle weiteren Ressourcen, die für das Review nötig sind, etwa Codes. Der angehängte Screenshot zeigt typischerweise deinen Login-Screen, eine Seite zur E-Mail-Bestätigung oder eine „Schau in dein Postfach“-Meldung.
Dieselbe Ursache steckt auch hinter anderen Ablehnungen. Ein Reviewer, der am Login hängen bleibt, kann die App unter Minimum Functionality einordnen, weil er nur ein Anmeldeformular gesehen hat (der Guide zu Minimum Functionality behandelt den Rest dieser Ablehnung). Eine Erklärung zum Standort im Hintergrund, zur Kontolöschung oder zu einer anderen Funktion kann abgelehnt werden, weil der Reviewer die Funktion hinter dem Login nicht prüfen konnte. Bevor du irgendetwas anderes umschreibst, prüfe, ob der Reviewer überhaupt hineingekommen ist.
KI-Builder erzeugen standardmäßig moderne, passwortlose Authentifizierung. Für Nutzer ist das großartig, für einen Reviewer auf einem frischen Testgerät eine Sackgasse.
Passwortlose E-Mail-Links sind ein häufiger Standard in Supabase-basierten Apps und vielen Auth-Kits. Der Reviewer hat keinen Zugriff auf das Postfach deines Testaccounts, und auf einem Smartphone öffnet sich der Link ohnehin im Browser oder in der Mail-App statt in deiner WebView, wie der Guide zu Magic Links erklärt.
Ein sechsstelliger Code per E-Mail oder SMS an eine Adresse, die nur du kontrollierst, stoppt das Review sofort. Google verlangt wiederverwendbare Zugangsdaten, die den Code-Schritt überspringen.
In einer WebView verweigert Google die eigene Anmeldeseite, solange der WebViewGold-Login-Helper nicht konfiguriert ist (GOOGLE_LOGIN_HELPER_TRIGGERS, siehe den Fix für disallowed_useragent). Selbst wenn es funktioniert, wird ein Reviewer kein privates Google-Konto verwenden. Biete zusätzlich E-Mail und Passwort an.
Wartelisten, Einladungscodes und Abläufe nach dem Motto „Ein Admin schaltet dein Konto frei“ bedeuten, dass eine neue Registrierung nie beim Produkt ankommt. Schalte den Review-Account vorab frei.
Ländersperren, strenge Firewall-Regeln, aggressive Bot-Challenges oder Rate Limits auf der Login-Route können das Gerät eines Reviewers ausbremsen. Google erwartet Zugangsdaten, die unabhängig vom Standort funktionieren.
Ablaufende Testphasen, Aufräumjobs für inaktive Nutzer und dein eigener Ablauf zur Kontolöschung (den ein Reviewer testen kann) können den Account zwischen zwei Reviews entfernen.
Mein iOS WebView wurde endlich genehmigt. Danke!!
Einmal etwa dreißig Minuten; danach funktioniert er für jedes Update.
Nimm eine Adresse wie [email protected], die nur für Store-Reviews existiert. Gib nie deinen eigenen Login oder den eines echten Kunden weiter: Google verlangt Zugangsdaten, die zum Testen angelegt wurden. Markiere die E-Mail im Dashboard deines Auth-Anbieters als bestätigt, damit keine Bestätigungsmail nötig ist.
Meldet sich deine App nur per Magic Link oder Einmalcode an, ergänze eine normale Anmeldung mit E-Mail und Passwort, die jeder Nutzer wählen kann, zum Beispiel einen Link „Stattdessen Passwort verwenden“ unter dem E-Mail-Feld (der Prompt unten erledigt das für dich). Für Telefon-Logins gibt es oft eine feste Testnummer: Firebase Authentication etwa lässt dich Testtelefonnummern mit einem festen Bestätigungscode registrieren. Schreib die genauen Schritte in die Anleitung.
Lege realistische Beispielinhalte an, damit jeder Screen seinen Zweck zeigt, und schalte den bezahlten Zugang auf deinem Server frei, damit Premium-Screens ohne Kauf geprüft werden können. Hat deine App Rollen (Kunde und Anbieter, Mitglied und Admin), lege pro Rolle einen Account an und nutze für jeden eine eigene Anleitung.
Nimm den Account von Aufräumskripten und vom Ablauf der Testphase aus. Melde dich nach jedem Review einmal an und prüfe, ob er noch existiert; ein Reviewer, der deinen Ablauf zur Kontolöschung testet, hat ihn vielleicht benutzt. Ein kleines Skript, das den Account samt Beispieldaten neu anlegt, erspart dir eine Ablehnung.
Erlaube die Login-Route aus allen Ländern und sorge dafür, dass der Bot-Schutz ein frisches Android-Gerät beim ersten Start nicht herausfordert. Ist dein Service nur in einem Land aktiv, halte zumindest den Review-Account weltweit funktionsfähig und schreib das in die Anleitung.
Öffne Richtlinie und Programme → App-Inhalte → Anmeldedaten (Sign-in details), wähle Starten oder Verwalten und dann + Neue Anleitung hinzufügen. Füge die Zugangsdaten genau so ein, wie sie auf dem Login-Screen eingetippt werden, und nutze das Feld Weitere Informationen (Any other instructions) für alles Ungewöhnliche: welcher Button anzutippen ist, wie der Code-Schritt übersprungen wird, welche Rolle der Account hat und wo die Hauptfunktionen liegen.
Deinstalliere die App, installiere den Build aus dem internen Test-Track und melde dich an, indem du die Zugangsdaten aus der Play Console einfügst. Steht CLEAR_CACHE_ON_STARTUP in Config.java auf true, löscht die App bei jedem Start die Cookies, und der Reviewer muss sich nach jedem Start neu anmelden; erwähne das. Ist die App-Sperre (enableBioMetricAuth) aktiv, erwähne auch das und teste auf einem Gerät ohne eingerichteten Fingerabdruck, damit du weißt, was der Reviewer sieht. Beide Optionen sind in der Config.java-Referenz für Android beschrieben.
Haben sich nur die Anmeldedaten geändert, speichere sie und sende das Update zur Überprüfung; die Play Console listet ausstehende Änderungen in der Veröffentlichungsübersicht. Hast du die App geändert, etwa um die Passwort-Option zu ergänzen, lade ein neues Release mit höherem Version Code hoch. Eine kurze Antwort im Richtlinienstatus mit Verweis auf die neue Anleitung hilft.
Einfaches Englisch, nummerierte Schritte, kein Marketing. Der Reviewer liest das, während die App auf einem Testgerät geöffnet ist. Die Vorlage bleibt auf Englisch, weil die Reviewer von Google Englisch lesen.
Login method: email and password. On the start screen tap [Log in], then [Use a password instead] below the email field. This account is pre-confirmed and needs no one-time code or email link. It works from any country. Role: [customer]. A second instruction set contains the [provider / admin] account. The account has the [Pro] plan unlocked on our server, so all paid features are visible without a purchase. Where to find the main features: 1. [Bookings tab]: create and cancel a booking. 2. [Profile > Notifications]: turn on reminders; a test notification arrives within [2] minutes. 3. [Profile > Settings > Delete account]: account deletion. Please use the second test account for this, so the main account stays available for future reviews. The app asks for [location] only on the [Store finder] screen, after an in-app explanation. [Only if enabled:] The app is protected by an app lock on launch; [describe what appears on a device without fingerprint or face unlock]. Contact during review: [email address].
Behält deinen Magic-Link- oder Code-Ablauf bei und ergänzt einen normalen Passwort-Login, den jeder Nutzer verwenden kann. Genau das braucht der Reviewer, und es ist keine versteckte Hintertür.
Meine App meldet Nutzer derzeit mit [Magic Links / Einmalcodes per E-Mail] über [Supabase Auth / Firebase Auth / Clerk] an. Ergänze eine normale Anmeldung mit E-Mail und Passwort neben der bestehenden Methode, ohne diese zu entfernen: - Füge auf dem Login-Screen einen gut sichtbaren Link 'Stattdessen Passwort verwenden' hinzu, der das Formular auf E-Mail + Passwort umschaltet. - Füge in den Kontoeinstellungen 'Passwort festlegen' hinzu, damit bestehende Nutzer eines anlegen können. - Nutze die eingebaute Passwort-Anmeldung des Auth-Anbieters. Baue keinen eigenen, geheimen oder versteckten Umweg. - Zeig bei einem falschen Passwort eine klare Fehlermeldung und baue einen 'Passwort vergessen'-Ablauf ein. - Halte die Sitzung über App-Neustarts hinweg aufrecht; die App läuft in einer Android-WebView. - Ändere sonst nichts. Liste am Ende die geänderten Dateien auf und erkläre, wie ich im Dashboard von [Anbieter] einen vorab bestätigten Testnutzer mit Passwort anlege.
Nur wenn die Registrierung sofort funktioniert, ohne E-Mail-Bestätigung, Codes oder Freigabe, und selbst dann erwartet Google Zugangsdaten, wenn ein Login nötig ist. Ein fertiger Account geht schneller und erspart dir eine zweite Ablehnung.
Nicht, wenn er eine normale, sichtbare Option ist, die jeder Nutzer verwenden kann. Vermeiden musst du einen geheimen Code oder Weg, der für Reviewer ein anderes Verhalten freischaltet; das fällt unter die Regeln zu irreführendem Verhalten.
Die robuste Lösung ist, E-Mail und Passwort zu ergänzen. Ein eigenes Google-Konto für das Review läuft beim Anmelden auf einem neuen Gerät oft in zusätzliche Bestätigungsschritte, und Google-Login in einer WebView braucht den WebViewGold-Login-Helper, um überhaupt zu funktionieren.
Nur wenn sich etwas ändert, aber jedes Update wird mit den hinterlegten Daten geprüft. Halte den Account dauerhaft gültig und aktualisiere die Anleitung, sobald du eine Rolle, eine Paywall oder eine neue Hauptfunktion hinzufügst.
Nur wenn du ihm einen echten Account gibst, was du nicht tun solltest. Google verlangt Zugangsdaten, die zum Testen angelegt wurden. Nutze Beispieldaten, die zeigen, wofür jeder Screen da ist.
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.
