Por que um app de anúncios para adultos nunca passa pela revisão das lojas, e o que construir no lugar
Mais cedo ou mais tarde, quem administra um diretório de anúncios se faz a mesma pergunta que todo fundador de um serviço mobile se faz nos primeiros meses: isso precisa de um app. Parece o próximo passo óbvio. Um ícone na tela inicial, notificações push para uma nova mensagem ou um anúncio verificado, algo que pareça mais sério que um site. Alguém da equipe empacota o site, envia, e alguns dias depois chega uma rejeição que não tem nada a ver com um bug ou um aviso de privacidade faltando. É rejeitado pelo que o negócio é, não por algo que possa ser corrigido e reenviado.
Esse é o ponto que vale a pena entender antes de investir tempo de desenvolvimento nisso. Apple e Google não decidem app por app se o seu diretório em particular é bem administrado, bem moderado ou totalmente conforme com a lei do seu país. Decidiram anos atrás, por escrito, que essa categoria de negócio não tem lugar em suas plataformas, ponto final. O que segue é o que as regras realmente dizem, por que não existe configuração de um marketplace limpo, legal e com verificação de idade que as contorne, e como é uma presença mobile que não depende de nenhuma das duas empresas mudar de ideia.
O que as regras realmente dizem
As App Store Review Guidelines da Apple tratam disso diretamente em Objectionable Content, seção 1.1.4. O texto não é vago: os apps não podem conter "material abertamente sexual ou pornográfico", e a diretriz continua dizendo que isso "inclui apps de 'hookup' e outros apps que possam incluir pornografia ou serem usados para facilitar a prostituição, ou o tráfico e a exploração de pessoas". Repare no que essa frase faz. Ela não proíbe imagens explícitas, que um diretório de anúncios não precisa mostrar de qualquer forma. Ela proíbe apps que facilitam a prostituição como função, independentemente de como os anúncios são redigidos ou recortados. Um diretório de fotos de perfil elegantes e totalmente vestidas com um formulário de reserva continua sendo um app que facilita o que a diretriz nomeia.
A política do Google Play é, se possível, ainda mais explícita ao nomear a categoria. Sua regra sobre conteúdo sexual afirma que o Google não permite apps ou conteúdo de app que "promovam ou solicitem um ato sexual em troca de compensação", e a política lista como exemplo específico apps que "promovem entretenimento de cunho sexual, serviços de acompanhantes, ou outros serviços que possam ser interpretados como oferecendo ou solicitando atos sexuais em troca de compensação". Serviços de acompanhantes são nomeados diretamente, não apenas sugeridos. O Google vai além e proíbe separadamente "acordos de encontros remunerados ou arranjos sexuais em que se espera ou se pressupõe que um participante forneça dinheiro, presentes ou apoio financeiro a outro participante", o arranjo comumente chamado de sugar dating. Essa cláusula extra existe porque operadores tentaram descrever o mesmo negócio com uma linguagem mais suave, e o Google fechou essa brecha especificamente, em vez de deixá-la à interpretação.
Vale a pena entender por que apps de namoro comuns não são afetados por nada disso. Tinder, Bumble e apps semelhantes permanecem em ambas as lojas porque nada em sua função anunciada envolve compensação por um arranjo sexual. Essa é a linha que ambas as plataformas traçam, e é uma linha funcional, não uma linha de tom. Um app de namoro pode ser tão sugestivo quanto seu marketing quiser, e um diretório de anúncios pode ser tão clínico e profissional quanto seus fundadores quiserem, e o resultado não muda, porque a pergunta feita não é "isso parece respeitável" mas "isso facilita arranjos sexuais remunerados". Um diretório responde sim a essa pergunta por construção, que é o produto inteiro.
Por que não existe um jeito esperto de contornar isso
Operadores novos costumam tentar uma de duas coisas antes de aceitar isso. A primeira é descrever o app em linguagem vaga e neutra quanto à categoria na ficha da loja, chamando-o de app de "descoberta social" ou "companhia premium" enquanto a funcionalidade real ainda corresponde ao padrão proibido assim que um revisor o abre. Isso não funciona, porque as equipes de revisão de ambas as lojas abrem o app, percorrem os fluxos, e em categorias ambíguas normalmente criam uma conta de teste e navegam pelos anúncios como um usuário real faria. Uma descrição bem elaborada não muda o que o revisor vê na tela trinta segundos depois.
A segunda tentativa é uma divisão: um app "limpo" que apenas permite navegar por perfis, combinado com um pagamento web ou um link externo onde a reserva ou o pagamento de fato acontece, na teoria de que manter a compensação fora do app evita a regra. Isso interpreta mal o que as duas políticas realmente avaliam. A diretriz da Apple sobre apps com conteúdo gerado por usuários é escrita de forma ampla o suficiente para pegar apps que existem principalmente para canalizar usuários rumo à atividade restrita, mesmo que a transação se conclua em outro lugar, e links de saída são seguidos durante a revisão justamente porque esse padrão é comum em muitas categorias restritas, não só nesta. Um app que existe para navegar por um catálogo de anúncios de companhia remunerada é o app sendo revisado, não a etapa de pagamento no final.
Há um segundo custo em tentar qualquer um dos dois contornos, que pesa mais do que uma simples rejeição. Uma rejeição direta, em que o app é categorizado honestamente e simplesmente se enquadra em uma regra de conteúdo, é tratada por ambas as plataformas exatamente como isso: uma rejeição. Descrever um app de um jeito nos metadados enquanto ele funciona de outro depois de instalado soa diferente para uma equipe de revisão, mais perto de uma tentativa de enganá-la do que de uma categorização equivocada de boa-fé. O acordo de desenvolvedor da Apple lhe dá amplos fundamentos para agir contra uma conta por envios desonestos ou enganosos, separadamente e de forma mais grave que uma rejeição de conteúdo comum, e um padrão de reenviar uma versão disfarçada do mesmo app rejeitado é o tipo de padrão que escala. O risco real não é que um app rejeitado desapareça. É que uma conta de desenvolvedor vinculada a uma razão social, uma conta bancária e todos os outros apps registrados sob ela seja removida de uma vez, por causa de um app que de qualquer forma nunca seria aprovado, não importa como fosse descrito.
Nada disso é um julgamento sobre o negócio em si, que pode ser inteiramente legal, bem moderado e com verificação de idade correta em sua própria jurisdição, e ainda assim falhar nesse teste, porque o teste não tem nada a ver com legalidade ou qualidade da moderação. É a política de produto de uma empresa privada, e ela é escrita para excluir a categoria por completo, não para avaliar operadores individuais dentro dela.
O que construir no lugar
A alternativa não é uma versão reduzida escolhida por falta de orçamento. É a única presença mobile que um diretório dessa categoria pode realmente manter a longo prazo, porque não é alugada de uma empresa que já declarou, por escrito, que não vai aceitá-lo. Um app web mobile, construído com um manifesto web e um service worker, pode ser adicionado à tela inicial de um telefone com seu próprio ícone, abre em tela cheia sem a interface do navegador, e se comporta como um app instalado do ponto de vista do usuário. Nada disso passa pela revisão das lojas da Apple ou do Google, porque não é distribuído por nenhuma das duas. As regras de conteúdo que se aplicam a apps em seus marketplaces simplesmente não se aplicam a um site, que é regido por regras de navegação bem mais leves e gerais em ambas as plataformas.
Notificações push fecham a maior parte da lacuna restante em relação a um app nativo. O web push no Android é maduro e funciona do mesmo jeito que uma notificação nativa. No iOS, apps web na tela inicial podem receber notificações push desde a versão 16.4, o que hoje cobre praticamente todo o parque ativo de iPhones. Um usuário que adiciona o diretório à tela inicial pode receber uma notificação de nova mensagem, aprovação de anúncio ou etapa de verificação concluída exatamente como receberia de um app baixado, sem que nenhuma das duas empresas precise revisar, aprovar ou conseguir remover essa experiência.
Isso também elimina uma dependência estruturalmente idêntica a um problema que operadores já enfrentam com provedores de infraestrutura: uma plataforma cujos termos são públicos, cuja resposta já é conhecida de antemão, e que pode encerrar a relação no seu próprio ritmo, independentemente de como o negócio se comporte. Uma ficha em uma loja para essa categoria não é um risco de combustão lenta que pode se materializar depois de uma revisão de políticas. É uma rejeição garantida, com uma regra pesquisável e citável por trás, o que a torna um dos riscos de infraestrutura mais fáceis de simplesmente evitar em vez de gerenciar.
O que os operadores devem realmente decidir
A primeira decisão não é técnica. É se um app algum dia resolveria o problema que deveria resolver. Fundadores geralmente querem uma de duas coisas: um jeito de se sentir descobríveis como os apps mainstream são, ou um jeito de enviar notificações push sem pedir permissão ao navegador. A busca nas lojas não é um canal de descoberta realista para essa categoria independentemente da aprovação, já que uma ficha tão específica seria removida antes mesmo de rankear para qualquer coisa, então o argumento da visibilidade não se sustenta nem no melhor cenário. As estratégias de tráfego orgânico e direto que já funcionam para um diretório de anúncios não são afetadas pela existência ou não de um app nativo, porque nenhuma delas passa pela busca nas lojas.
Existe uma categoria mais estreita que vale a pena conhecer, porque é genuinamente diferente de um app de marketplace público e às vezes é viável: uma ferramenta operacional para anunciantes verificados gerenciarem seu próprio anúncio, mensagens e conta, não exposta à busca pública e que não exibe por si só um diretório navegável de companhia remunerada para usuários da loja. Isso se aproxima mais de um software de gestão comum, e embora ainda exija uma leitura cuidadosa das diretrizes vigentes antes de qualquer envio, já que a linha depende exatamente do que o app mostra e para quem, não é automaticamente pego pela mesma regra que bloqueia um app de diretório voltado ao público.
Para todos os outros, a resposta é parar de tratar o ícone de app ausente como algo pelo qual se desculpar ou que precise ser resolvido em algum momento. Construir em vez disso, e bem, a experiência web mobile: um site rápido e instalável com um manifesto de verdade, um convite para adicionar à tela inicial mostrado em um momento sensato em vez de no carregamento da página, e notificações push às quais o usuário realmente adere. Essa não é a opção de reserva aqui. É a única estratégia mobile que não termina em carta de rejeição e, se levada longe demais, um aviso de encerramento de conta para um negócio que de qualquer forma nunca seria admitido.
