Perché un'app per una directory di annunci per adulti non supera mai la revisione degli store, e cosa costruire al suo posto

Prima o poi, chi gestisce una directory di annunci si fa la stessa domanda che si fa ogni fondatore di un servizio mobile nei primi mesi: serve un'app. Sembra il passo successivo ovvio. Un'icona sulla schermata iniziale, notifiche push per un nuovo messaggio o un annuncio verificato, qualcosa che sembri più serio di un sito web. Qualcuno del team incapsula il sito, la invia, e qualche giorno dopo arriva un rifiuto che non ha niente a che fare con un bug o un'etichetta sulla privacy mancante. Viene rifiutata per cosa è l'attività, non per qualcosa che si possa correggere e reinviare.

Questo è il punto da capire prima di investirci del tempo di sviluppo. Apple e Google non decidono caso per caso se una particolare directory è ben gestita, ben moderata o pienamente conforme alla legge del proprio paese. Hanno deciso anni fa, per iscritto, che questa categoria di attività non appartiene alle loro piattaforme, punto. Quello che segue è cosa dicono davvero le regole, perché non esiste una configurazione di un mercato pulito, legale e con verifica dell'età che le aggiri, e come si presenta una presenza mobile che non dipende dal fatto che una delle due aziende cambi idea.

Cosa dicono davvero le regole

Le App Store Review Guidelines di Apple affrontano la questione direttamente sotto Objectionable Content, sezione 1.1.4. Il testo non è vago: le app non possono contenere "materiale apertamente sessuale o pornografico", e la linea guida prosegue dicendo che questo "include le app di 'hookup' e altre app che possono includere pornografia o essere usate per facilitare la prostituzione, o la tratta e lo sfruttamento di esseri umani". Nota cosa fa quella frase. Non vieta immagini esplicite, che una directory di annunci non ha comunque bisogno di mostrare. Vieta le app che facilitano la prostituzione come funzione, indipendentemente da come sono scritti o ritagliati gli annunci. Una directory di foto profilo eleganti e completamente vestite con un modulo di prenotazione resta un'app che facilita quello che la linea guida nomina.

La politica di Google Play è, se possibile, ancora più esplicita nel nominare la categoria. La sua regola sui contenuti sessuali afferma che Google non consente app o contenuti che "promuovano o sollecitino un atto sessuale in cambio di un compenso", e la politica elenca come esempio specifico le app che "promuovono intrattenimento a sfondo sessuale, servizi di escort, o altri servizi che possono essere interpretati come offerta o sollecitazione di atti sessuali in cambio di un compenso". I servizi di escort sono nominati direttamente, non sottintesi. Google va oltre e vieta separatamente gli "accordi di appuntamenti a pagamento o accordi sessuali in cui ci si aspetta o si sottintende che un partecipante fornisca denaro, regali o sostegno finanziario a un altro partecipante", l'accordo comunemente chiamato sugar dating. Quella clausola in più esiste perché alcuni operatori hanno provato a descrivere la stessa attività con un linguaggio più morbido, e Google ha chiuso quel varco specificamente invece di lasciarlo all'interpretazione.

Vale la pena capire perché le normali app di incontri non sono toccate da niente di tutto questo. Tinder, Bumble e app simili restano su entrambi gli store perché niente nella loro funzione dichiarata comporta un compenso per un accordo sessuale. Questa è la linea che tracciano entrambe le piattaforme, ed è una linea funzionale, non una linea di tono. Un'app di incontri può essere carica quanto vuole nel suo marketing, e una directory di annunci può essere clinica e professionale quanto vogliono i suoi fondatori, e il risultato non cambia, perché la domanda posta non è "questo sembra rispettabile" ma "questo facilita accordi sessuali a pagamento". Una directory risponde sì a quella domanda per costruzione, che è l'intero prodotto.

Perché non esiste un modo furbo per aggirarla

I nuovi operatori tendono a provare una di due cose prima di accettarlo. La prima è descrivere l'app con un linguaggio vago, neutro rispetto alla categoria, nella scheda dello store, chiamandola app di "social discovery" o "compagnia premium" mentre la funzionalità reale corrisponde ancora allo schema vietato non appena un revisore la apre. Non funziona, perché i team di revisione di entrambi gli store aprono l'app, seguono i flussi, e nelle categorie ambigue di solito creano un account di prova e sfogliano gli annunci come farebbe un utente vero. Una descrizione curata non cambia quello che il revisore vede sullo schermo trenta secondi dopo.

Il secondo tentativo è una separazione: un'app "pulita" che si limita a sfogliare profili, abbinata a un pagamento sul web o a un collegamento esterno dove avviene davvero la prenotazione o il pagamento, nell'idea che tenere il compenso fuori dall'app eviti la regola. Questo fraintende cosa stanno davvero valutando le due politiche. La linea guida di Apple sulle app con contenuti generati dagli utenti è scritta abbastanza ampiamente da intercettare app che esistono principalmente per incanalare gli utenti verso l'attività vietata anche se la transazione si conclude altrove, e i collegamenti in uscita vengono seguiti durante la revisione proprio perché questo schema è comune a molte categorie vietate, non solo a questa. Un'app che esiste per sfogliare un elenco di annunci di compagnia a pagamento è l'app sotto esame, non il passaggio di pagamento alla fine.

C'è un secondo costo nel tentare uno di questi due aggiramenti, e conta più di un singolo rifiuto. Un rifiuto diretto, in cui l'app è categorizzata onestamente e ricade semplicemente sotto una regola sui contenuti, viene trattato da entrambe le piattaforme esattamente per quello che è: un rifiuto. Descrivere un'app in un modo nei suoi metadati mentre funziona in un altro una volta installata si legge in modo diverso per un team di revisione, più vicino a un tentativo di ingannarli che a una categorizzazione errata in buona fede. L'accordo per sviluppatori di Apple gli dà ampi margini per agire contro un account per invii disonesti o ingannevoli, separatamente e più gravemente rispetto a un normale rifiuto sui contenuti, e un pattern di reinvio di una versione camuffata della stessa app già rifiutata è il tipo di pattern che fa scalare la situazione. Il rischio reale non è che sparisca un'app rifiutata. È che un account sviluppatore legato a una ragione sociale, un conto bancario e ogni altra app registrata sotto di esso venga tolto in blocco, per un'app che non sarebbe mai stata approvata comunque fosse stata descritta.

Niente di tutto questo è un giudizio sull'attività di fondo, che può essere del tutto legale, ben moderata e con verifica dell'età corretta nella propria giurisdizione, e fallire comunque questo esame, perché l'esame non ha niente a che fare con la legalità o la qualità della moderazione. È la politica di prodotto di un'azienda privata, ed è scritta per escludere la categoria in blocco, non per valutare i singoli operatori al suo interno.

Cosa costruire al suo posto

L'alternativa non è un ripiego scelto per mancanza di budget. È l'unica presenza mobile che una directory di questa categoria può davvero mantenere nel tempo, perché non è affittata da un'azienda che ha già dichiarato, per iscritto, che non ti accetterà. Un'app web mobile, costruita con un manifest e un service worker, può essere aggiunta alla schermata iniziale del telefono con una propria icona, si apre a schermo intero senza l'interfaccia del browser, e si comporta come un'app installata dal punto di vista dell'utente. Niente di tutto questo passa dalla revisione degli store di Apple o Google, perché non viene distribuita da nessuno dei due. Le regole sui contenuti che valgono per le app nei loro marketplace semplicemente non si applicano a un sito web, che è governato da regole di navigazione molto più leggere e generali su entrambe le piattaforme.

Le notifiche push chiudono buona parte del divario rimasto rispetto a un'app nativa. Il web push su Android è maturo e funziona come una notifica nativa. Su iOS, le app web sulla schermata iniziale possono ricevere notifiche push dalla versione 16.4, che ormai copre praticamente tutto il parco iPhone attivo. Un utente che aggiunge la directory alla schermata iniziale può ricevere una notifica per un nuovo messaggio, l'approvazione di un annuncio o un passaggio di verifica completato esattamente come farebbe da un'app scaricata, senza che nessuna delle due aziende debba mai esaminarla, approvarla o poterla togliere.

Questo elimina anche una dipendenza strutturalmente identica a un problema che gli operatori affrontano già con i fornitori di infrastruttura: una piattaforma le cui condizioni sono pubbliche, la cui risposta è già nota in anticipo, e che può chiudere il rapporto secondo i propri tempi indipendentemente da come si comporta l'attività. Una scheda su uno store per questa categoria non è un rischio a lenta combustione che potrebbe materializzarsi dopo una revisione delle politiche. È un rifiuto garantito, con dietro una regola cercabile e citabile, il che lo rende uno dei rischi infrastrutturali più facili da evitare del tutto invece che da gestire.

Cosa devono davvero decidere gli operatori

La prima decisione non è tecnica. È se un'app avrebbe mai risolto il problema che doveva risolvere. I fondatori di solito vogliono una di due cose: un modo per sentirsi individuabili come lo sono le app mainstream, o un modo per mandare notifiche push senza chiedere il permesso al browser. La ricerca sugli store non è un canale di scoperta realistico per questa categoria a prescindere dall'approvazione, dato che una scheda così specifica verrebbe rimossa prima ancora di posizionarsi per qualunque cosa, quindi l'argomento della visibilità non regge nemmeno nel migliore dei casi. Le strategie di traffico organico e diretto che già funzionano per una directory di annunci non sono toccate dal fatto che esista o meno un'app nativa, perché nessuna di esse passa dalla ricerca sugli store.

C'è una categoria più ristretta che vale la pena conoscere, perché è davvero diversa da un'app di mercato pubblico ed è a volte percorribile: uno strumento operativo per inserzionisti verificati per gestire il proprio annuncio, i messaggi e l'account, non esposto alla ricerca pubblica e che non mostra di per sé una directory sfogliabile di compagnia a pagamento agli utenti dello store. Questo si avvicina di più a un normale software gestionale, e anche se richiede comunque una lettura attenta delle linee guida attuali prima di inviarlo, dato che la linea dipende esattamente da cosa mostra l'app e a chi, non viene intercettato automaticamente dalla stessa regola che blocca un'app di directory rivolta al pubblico.

Per tutti gli altri, la risposta è smettere di trattare l'icona dell'app mancante come qualcosa di cui scusarsi o da sistemare prima o poi. Costruire invece per bene l'esperienza web mobile: un sito veloce e installabile con un manifest vero, un invito ad aggiungere alla schermata iniziale mostrato in un momento sensato invece che al caricamento della pagina, e notifiche push a cui l'utente aderisce davvero. Non è il ripiego, qui. È l'unica strategia mobile che non finisce con una lettera di rifiuto e, se si insiste abbastanza, un avviso di chiusura dell'account per un'attività che non sarebbe mai stata ammessa comunque.