Warum eine App für ein Anzeigenverzeichnis für Erwachsene die Store-Prüfung nie besteht, und was man stattdessen baut
Früher oder später stellt sich jedem, der ein Anzeigenverzeichnis betreibt, dieselbe Frage, die sich jeder Gründer eines mobilen Dienstes in den ersten Monaten stellt: Braucht das eine App. Es wirkt wie der naheliegende nächste Schritt. Ein Symbol auf dem Startbildschirm, Push-Benachrichtigungen für eine neue Nachricht oder eine verifizierte Anzeige, etwas, das ernsthafter wirkt als eine Website. Jemand im Team verpackt die Seite, reicht sie ein, und ein paar Tage später kommt eine Ablehnung, die nichts mit einem Fehler oder einem fehlenden Datenschutzhinweis zu tun hat. Sie wird abgelehnt für das, was das Geschäft ist, nicht für etwas, das man beheben und erneut einreichen könnte.
Das ist der Teil, den man verstehen sollte, bevor man Entwicklungszeit hineinsteckt. Apple und Google entscheiden nicht App für App, ob Ihr bestimmtes Verzeichnis gut geführt, gut moderiert oder vollständig mit dem Recht Ihres Landes vereinbar ist. Sie haben vor Jahren schriftlich festgelegt, dass diese Geschäftskategorie auf ihren Plattformen keinen Platz hat, Punkt. Im Folgenden geht es darum, was die Regeln tatsächlich sagen, warum es keine Konfiguration eines sauberen, legalen, altersverifizierten Marktplatzes gibt, die sie umgeht, und wie eine mobile Präsenz aussieht, die nicht davon abhängt, dass eines der beiden Unternehmen seine Meinung ändert.
Was die Regeln tatsächlich sagen
Apples App Store Review Guidelines behandeln das direkt unter Objectionable Content, Abschnitt 1.1.4. Der Wortlaut ist nicht vage: Apps dürfen kein "offen sexuelles oder pornografisches Material" enthalten, und die Richtlinie führt weiter aus, dies "schließt 'Hookup'-Apps und andere Apps ein, die Pornografie enthalten oder zur Erleichterung von Prostitution oder Menschenhandel und Ausbeutung genutzt werden können". Beachten Sie, was dieser Satz bewirkt. Er verbietet nicht explizite Bilder, die ein Anzeigenverzeichnis ohnehin nicht zeigen muss. Er verbietet Apps, die Prostitution als Funktion erleichtern, unabhängig davon, wie die Anzeigen formuliert oder zugeschnitten sind. Ein Verzeichnis mit dezenten, vollständig bekleideten Profilfotos und einem Buchungsformular bleibt eine App, die das erleichtert, was die Richtlinie benennt.
Google Plays Richtlinie ist, wenn überhaupt, noch expliziter darin, die Kategorie zu benennen. Ihre Regel zu sexuellen Inhalten besagt, dass Google keine Apps oder App-Inhalte zulässt, die "für eine sexuelle Handlung gegen Entgelt werben oder diese anbieten", und die Richtlinie führt als konkretes Beispiel Apps an, die "für sexuell orientierte Unterhaltung, Begleitservices oder andere Dienste werben, die als Angebot oder Anwerbung sexueller Handlungen gegen Entgelt ausgelegt werden können". Begleitservices werden direkt genannt, nicht nur angedeutet. Google geht noch weiter und verbietet gesondert "bezahlte Dating- oder sexuelle Arrangements, bei denen erwartet oder unterstellt wird, dass ein Teilnehmer einem anderen Geld, Geschenke oder finanzielle Unterstützung gewährt", das Arrangement, das gemeinhin als Sugar Dating bezeichnet wird. Diese zusätzliche Klausel existiert, weil Anbieter versucht haben, dasselbe Geschäft mit weicherer Sprache zu beschreiben, und Google hat diese Lücke gezielt geschlossen, statt sie der Auslegung zu überlassen.
Es lohnt sich zu verstehen, warum gewöhnliche Dating-Apps davon nicht betroffen sind. Tinder, Bumble und ähnliche Apps bleiben auf beiden Stores, weil an ihrer beworbenen Funktion nichts eine Entlohnung für ein sexuelles Arrangement beinhaltet. Das ist die Grenze, die beide Plattformen ziehen, und es ist eine funktionale Grenze, keine Grenze des Tonfalls. Eine Dating-App kann im Marketing so aufgeladen sein, wie sie will, und ein Anzeigenverzeichnis kann so nüchtern und geschäftsmäßig sein, wie es die Gründer wollen, das Ergebnis ändert sich nicht, weil die gestellte Frage nicht lautet "wirkt das seriös", sondern "erleichtert das bezahlte sexuelle Arrangements". Ein Verzeichnis beantwortet diese Frage schon durch seine Bauweise mit Ja, das ist das gesamte Produkt.
Warum es keinen cleveren Weg daran vorbei gibt
Neue Anbieter versuchen meist eines von zwei Dingen, bevor sie das akzeptieren. Das erste ist, die App im Store-Eintrag in vager, kategorieneutraler Sprache zu beschreiben, sie als "Social Discovery"- oder "Premium-Begleitung"-App zu bezeichnen, während die tatsächliche Funktion weiterhin dem verbotenen Muster entspricht, sobald ein Prüfer sie öffnet. Das funktioniert nicht, denn die Prüfteams beider Stores öffnen die App, klicken sich durch die Abläufe und legen bei mehrdeutigen Kategorien in der Regel ein Testkonto an und stöbern in den Anzeigen wie ein echter Nutzer. Eine geschliffene Beschreibung ändert nichts daran, was der Prüfer dreißig Sekunden später auf dem Bildschirm sieht.
Der zweite Versuch ist eine Aufteilung: eine "saubere" App, die nur Profile durchsucht, kombiniert mit einer Web-Zahlung oder einem externen Link, über den die eigentliche Buchung oder Zahlung erfolgt, in der Annahme, dass das Fernhalten der Bezahlung von der App die Regel umgeht. Das verkennt, was beide Richtlinien tatsächlich prüfen. Apples Richtlinie zu Apps mit nutzergenerierten Inhalten ist bewusst weit genug gefasst, um Apps zu erfassen, die vor allem dazu dienen, Nutzer zur eingeschränkten Aktivität zu leiten, selbst wenn die Transaktion anderswo abgeschlossen wird, und ausgehende Links werden bei der Prüfung verfolgt, gerade weil dieses Muster in vielen eingeschränkten Kategorien verbreitet ist, nicht nur in dieser. Eine App, die dazu existiert, eine Liste bezahlter Begleitangebote zu durchsuchen, ist die geprüfte App, nicht der Zahlungsschritt am Ende.
Es gibt einen zweiten Preis für den Versuch eines dieser beiden Umwege, der mehr wiegt als eine einfache Ablehnung. Eine unkomplizierte Ablehnung, bei der die App ehrlich kategorisiert ist und schlicht unter eine Inhaltsregel fällt, wird von beiden Plattformen genau so behandelt: als Ablehnung. Eine App in ihren Metadaten anders zu beschreiben, als sie nach der Installation tatsächlich funktioniert, liest sich für ein Prüfteam anders, näher an einem Täuschungsversuch als an einer gutgläubigen Fehlkategorisierung. Apples Entwicklervereinbarung räumt weitreichende Befugnisse ein, gegen ein Konto wegen unehrlicher oder irreführender Einreichungen vorzugehen, getrennt von und schwerwiegender als eine gewöhnliche Inhaltsablehnung, und ein Muster wiederholter Einreichungen einer getarnten Version derselben abgelehnten App ist genau die Art von Muster, die eskaliert. Das realistische Risiko ist nicht, dass eine abgelehnte App verschwindet. Es ist, dass ein Entwicklerkonto, das an einen Firmennamen, ein Bankkonto und jede andere darunter registrierte App gebunden ist, auf einen Schlag entfernt wird, wegen einer App, die ohnehin nie genehmigt worden wäre, egal wie sie beschrieben wurde.
Nichts davon ist ein Urteil über das zugrunde liegende Geschäft, das in seiner eigenen Rechtsordnung vollständig legal, gut moderiert und korrekt altersverifiziert sein kann und diese Prüfung trotzdem nicht besteht, weil die Prüfung nichts mit Rechtmäßigkeit oder Moderationsqualität zu tun hat. Es ist die Produktrichtlinie eines privaten Unternehmens, und sie ist so geschrieben, dass sie die Kategorie insgesamt ausschließt, statt einzelne Anbieter darin zu bewerten.
Was man stattdessen bauen sollte
Die Alternative ist kein Notbehelf aus Budgetmangel. Sie ist die einzige mobile Präsenz, die ein Verzeichnis dieser Kategorie tatsächlich langfristig behalten kann, weil sie nicht von einem Unternehmen gemietet ist, das bereits schriftlich erklärt hat, dass es Sie nicht will. Eine mobile Web-App, gebaut mit einem Web-Manifest und einem Service Worker, kann mit einem eigenen Symbol zum Startbildschirm eines Telefons hinzugefügt werden, öffnet sich im Vollbild ohne Browserleiste und verhält sich aus Nutzersicht wie eine installierte App. Nichts davon durchläuft die Store-Prüfung von Apple oder Google, weil sie über keinen der beiden vertrieben wird. Die Inhaltsregeln, die für Apps in deren Marktplätzen gelten, gelten schlicht nicht für eine Website, die auf beiden Plattformen deutlich leichteren und allgemeineren Browsing-Regeln unterliegt.
Push-Benachrichtigungen schließen den größten Teil der verbleibenden Lücke zu einer nativen App. Web-Push auf Android ist ausgereift und funktioniert genauso wie eine native Benachrichtigung. Auf iOS können Web-Apps auf dem Startbildschirm seit Version 16.4 Push-Benachrichtigungen empfangen, was inzwischen praktisch den gesamten aktiven iPhone-Bestand abdeckt. Ein Nutzer, der das Verzeichnis zum Startbildschirm hinzufügt, kann eine Benachrichtigung für eine neue Nachricht, die Freigabe einer Anzeige oder einen abgeschlossenen Verifizierungsschritt genau so erhalten wie von einer heruntergeladenen App, ohne dass eines der beiden Unternehmen sie je prüfen, freigeben oder entfernen kann.
Das beseitigt außerdem eine Abhängigkeit, die strukturell mit einem Problem identisch ist, dem Anbieter bei Infrastrukturdienstleistern bereits begegnen: eine Plattform, deren Bedingungen öffentlich sind, deren Antwort bereits im Voraus feststeht und die die Beziehung nach eigenem Zeitplan beenden kann, unabhängig davon, wie sich das Geschäft verhält. Ein Store-Eintrag für diese Kategorie ist kein schleichendes Risiko, das sich möglicherweise nach einer Richtlinienprüfung materialisiert. Es ist eine garantierte Ablehnung mit einer durchsuchbaren, zitierbaren Regel dahinter, was sie zu einem der Infrastrukturrisiken macht, die sich am leichtesten schlicht vermeiden statt verwalten lassen.
Was Anbieter wirklich entscheiden müssen
Die erste Entscheidung ist keine technische. Es ist die Frage, ob eine App je das Problem gelöst hätte, das sie lösen sollte. Gründer wollen meist eines von zwei Dingen: eine Möglichkeit, so auffindbar zu wirken wie Mainstream-Apps, oder eine Möglichkeit, Push-Benachrichtigungen zu senden, ohne den Browser um Erlaubnis zu bitten. Die Store-Suche ist für diese Kategorie kein realistischer Entdeckungskanal, unabhängig von einer Genehmigung, da ein derart spezifischer Eintrag entfernt würde, bevor er für irgendetwas rankt, sodass das Sichtbarkeitsargument nicht einmal im besten Fall trägt. Die organischen und direkten Traffic-Strategien, die für ein Anzeigenverzeichnis bereits funktionieren, sind davon unberührt, ob es eine native App gibt, weil keine von ihnen über die Store-Suche läuft.
Es gibt eine engere Kategorie, die es zu kennen lohnt, weil sie sich von einer öffentlichen Marktplatz-App echt unterscheidet und manchmal tragfähig ist: ein Betriebswerkzeug für verifizierte Anbieter, um ihre eigene Anzeige, Nachrichten und ihr Konto zu verwalten, das nicht der öffentlichen Suche ausgesetzt ist und selbst kein durchstöberbares Verzeichnis bezahlter Begleitung für Store-Nutzer anzeigt. Das kommt gewöhnlicher Geschäftssoftware näher, und obwohl auch hier vor jeder Einreichung eine sorgfältige Lektüre der jeweils aktuellen Richtlinien nötig ist, da die Grenze genau davon abhängt, was die App zeigt und wem, wird es nicht automatisch von derselben Regel erfasst, die eine öffentlich zugängliche Verzeichnis-App blockiert.
Für alle anderen lautet die Antwort, aufzuhören, das fehlende App-Symbol als etwas zu behandeln, wofür man sich entschuldigen oder das man irgendwann nachliefern müsste. Stattdessen die mobile Web-Erfahrung richtig bauen: eine schnelle, installierbare Seite mit einem echten Manifest, ein Hinweis zum Hinzufügen zum Startbildschirm, der zu einem sinnvollen Zeitpunkt erscheint statt beim Laden der Seite, und Push-Benachrichtigungen, denen ein Nutzer tatsächlich zustimmt. Das ist hier nicht die Notlösung. Es ist die einzige mobile Strategie, die nicht mit einem Ablehnungsschreiben endet und, bei ausreichendem Beharren, einer Kontokündigung für ein Geschäft, das ohnehin nie zugelassen worden wäre.
