Por qué una app de anuncios para adultos nunca pasa la revisión de las tiendas, y qué construir en su lugar
Tarde o temprano, quien lleva un directorio de anuncios se hace la misma pregunta que se hace cualquier fundador de un servicio móvil en los primeros meses: ¿necesita una app? Parece el paso siguiente obvio. Un icono en la pantalla de inicio, notificaciones push para un mensaje nuevo o un anuncio verificado, algo que se vea más serio que una web. Alguien del equipo empaqueta el sitio, lo envía, y unos días después llega un rechazo que no tiene nada que ver con un fallo o una etiqueta de privacidad olvidada. Se rechaza por lo que es el negocio, no por algo que se pueda corregir y reenviar.
Eso es lo que conviene entender antes de invertir tiempo de desarrollo en ello. Apple y Google no deciden aplicación por aplicación si tu directorio en concreto está bien gestionado, bien moderado o cumple del todo la ley de tu país. Decidieron hace años, por escrito, que esta categoría de negocio no tiene cabida en sus plataformas, punto. Lo que sigue es lo que dicen realmente las normas, por qué no existe una configuración de un mercado limpio, legal y con verificación de edad que las esquive, y cómo es una presencia móvil que no depende de que ninguna de las dos empresas cambie de opinión.
Lo que dicen realmente las normas
Las App Store Review Guidelines de Apple abordan esto directamente en Objectionable Content, sección 1.1.4. El texto no es vago: las apps no pueden contener "material abiertamente sexual o pornográfico", y la norma continúa diciendo que esto "incluye apps de 'hookup' y otras apps que puedan incluir pornografía o usarse para facilitar la prostitución, o la trata y explotación de personas". Fíjate en lo que hace esa frase. No prohíbe imágenes explícitas, que un directorio de anuncios no necesita mostrar de todos modos. Prohíbe las apps que facilitan la prostitución como función, sin importar cómo estén redactados o recortados los anuncios. Un directorio de fotos de perfil elegantes y totalmente vestidas con un formulario de reserva sigue siendo una app que facilita lo que nombra la norma.
La política de Google Play es, si cabe, todavía más explícita al nombrar la categoría. Su regla sobre contenido sexual establece que Google no permite apps ni contenido que "promuevan o soliciten un acto sexual a cambio de una compensación", y la política enumera como ejemplo concreto las apps que "promueven entretenimiento de tipo sexual, servicios de acompañantes, u otros servicios que puedan interpretarse como ofrecer o solicitar actos sexuales a cambio de una compensación". Los servicios de acompañantes se nombran directamente, no se dan por sobreentendidos. Google va un paso más allá y prohíbe por separado los "acuerdos de citas remuneradas o arreglos sexuales en los que se espera o se sobreentiende que una parte aporte dinero, regalos o apoyo económico a la otra", el arreglo conocido como sugar dating. Esa cláusula adicional existe porque algunos operadores intentaron describir el mismo negocio con un lenguaje más suave, y Google cerró ese hueco de forma específica en lugar de dejarlo a la interpretación.
Merece la pena ver por qué las apps de citas normales no se ven afectadas por nada de esto. Tinder, Bumble y apps similares se mantienen en ambas tiendas porque nada en su función anunciada implica una compensación por un arreglo sexual. Esa es la línea que trazan ambas plataformas, y es una línea funcional, no una línea de tono. Una app de citas puede ser tan explícita como quiera su marketing, y un directorio de anuncios puede ser tan clínico y profesional como quieran sus fundadores, y el resultado no cambia, porque la pregunta que se hace no es "¿esto parece respetable?" sino "¿esto facilita arreglos sexuales remunerados?". Un directorio responde que sí a esa pregunta por diseño, que es el producto entero.
Por qué no hay una forma ingeniosa de evitarlo
Los operadores nuevos suelen probar una de dos cosas antes de aceptarlo. La primera es describir la app con un lenguaje vago y neutro respecto a la categoría en la ficha de la tienda, llamándola app de "descubrimiento social" o "compañía premium" mientras la funcionalidad real sigue encajando en el patrón prohibido en cuanto un revisor la abre. Esto no funciona, porque los equipos de revisión de ambas tiendas abren la app, recorren los flujos, y en categorías ambiguas suelen crear una cuenta de prueba y explorar los anuncios como lo haría un usuario real. Una descripción cuidada no cambia lo que el revisor ve en pantalla treinta segundos después.
El segundo intento es una división: una app "limpia" que solo permite ver perfiles, junto con un pago web o un enlace externo donde ocurre de verdad la reserva o el pago, bajo la teoría de que mantener la compensación fuera de la app evita la norma. Esto malinterpreta lo que realmente evalúan ambas políticas. La norma de Apple sobre apps con contenido generado por usuarios está redactada con la amplitud suficiente para atrapar apps que existen principalmente para dirigir a los usuarios hacia la actividad restringida aunque la transacción se complete en otro sitio, y los enlaces salientes se siguen durante la revisión precisamente porque este patrón es común en muchas categorías restringidas, no solo en esta. Una app que existe para explorar un catálogo de anuncios de compañía remunerada es la app que se está revisando, no el paso de pago al final.
Hay un segundo coste al intentar cualquiera de los dos rodeos que pesa más que un simple rechazo. Un rechazo directo, en el que la app está categorizada honestamente y simplemente cae bajo una norma de contenido, se trata en ambas plataformas exactamente como eso: un rechazo. Describir una app de una manera en sus metadatos mientras funciona de otra una vez instalada se lee de forma distinta para un equipo de revisión, más cerca de un intento de engañarlos que de una categorización errónea de buena fe. El acuerdo de desarrollador de Apple le da amplio margen para actuar contra una cuenta por envíos deshonestos o engañosos, algo separado y más grave que un rechazo de contenido ordinario, y un patrón de reenviar una versión disfrazada de la misma app rechazada es el tipo de patrón que escala. El riesgo real no es que desaparezca una app rechazada. Es que se retire de golpe una cuenta de desarrollador vinculada a una razón social, una cuenta bancaria y todas las demás apps registradas bajo ella, por una app que de todos modos nunca iba a aprobarse, se describiera como se describiera.
Nada de esto es un juicio sobre el negocio de fondo, que puede ser del todo legal, estar bien moderado y tener una verificación de edad correcta en su propia jurisdicción, y aun así no superar esta prueba, porque la prueba no tiene nada que ver con la legalidad ni con la calidad de la moderación. Es la política de producto de una empresa privada, y está escrita para excluir la categoría por completo, no para evaluar a los operadores concretos que hay dentro de ella.
Qué construir en su lugar
La alternativa no es una versión reducida elegida por falta de presupuesto. Es la única presencia móvil que un directorio de esta categoría puede mantener de verdad a largo plazo, porque no se alquila a una empresa que ya ha declarado, por escrito, que no te va a aceptar. Una app web móvil, construida con un manifiesto web y un service worker, se puede añadir a la pantalla de inicio del teléfono con su propio icono, se abre a pantalla completa sin la interfaz del navegador, y se comporta como una app instalada desde el punto de vista del usuario. Nada de esto pasa por la revisión de las tiendas de Apple o Google, porque no se distribuye a través de ninguna de las dos. Las normas de contenido que se aplican a las apps de sus mercados sencillamente no se aplican a un sitio web, que se rige por normas de navegación mucho más ligeras y generales en ambas plataformas.
Las notificaciones push cierran la mayor parte de la diferencia que queda con una app nativa. El push web en Android está maduro y funciona igual que una notificación nativa. En iOS, las apps web en la pantalla de inicio pueden recibir notificaciones push desde la versión 16.4, que a estas alturas cubre prácticamente todo el parque activo de iPhone. Un usuario que añade el directorio a su pantalla de inicio puede recibir una notificación por un mensaje nuevo, la aprobación de un anuncio o un paso de verificación completado exactamente igual que lo haría desde una app descargada, sin que ninguna de las dos empresas tenga nunca que revisarla, aprobarla ni poder retirarla.
Esto también elimina una dependencia estructuralmente idéntica a un problema que los operadores ya afrontan con los proveedores de infraestructura: una plataforma cuyas condiciones son públicas, cuya respuesta ya se conoce de antemano, y que puede terminar la relación según su propio calendario sin importar cómo se comporte el negocio. Una ficha en una tienda para esta categoría no es un riesgo de combustión lenta que pueda materializarse tras una revisión de políticas. Es un rechazo garantizado, con una norma buscable y citable detrás, lo que lo convierte en uno de los riesgos de infraestructura más fáciles de evitar directamente en lugar de gestionar.
Qué deben decidir realmente los operadores
La primera decisión no es técnica. Es si una app iba a resolver alguna vez el problema que debía resolver. Los fundadores suelen querer una de dos cosas: una forma de sentirse localizables como lo son las apps convencionales, o una forma de enviar notificaciones push sin pedirle permiso al navegador. La búsqueda en las tiendas no es un canal de descubrimiento realista para esta categoría al margen de la aprobación, ya que una ficha tan específica se retiraría antes incluso de posicionarse para nada, así que el argumento de la visibilidad no se sostiene ni en el mejor de los casos. Las estrategias de tráfico orgánico y directo que ya funcionan para un directorio de anuncios no se ven afectadas por que exista o no una app nativa, porque ninguna de ellas pasa por la búsqueda en las tiendas.
Hay una categoría más estrecha que merece la pena conocer, porque es realmente distinta de una app de mercado público y a veces es viable: una herramienta operativa para que anunciantes verificados gestionen su propio anuncio, sus mensajes y su cuenta, no expuesta a la búsqueda pública y que no muestra por sí misma un directorio explorable de compañía remunerada a los usuarios de la tienda. Esto se acerca más a un software de gestión ordinario, y aunque igualmente requiere una lectura cuidadosa de las normas vigentes antes de enviarla, ya que la línea depende exactamente de qué muestra la app y a quién, no queda atrapada automáticamente por la misma norma que bloquea una app de directorio de cara al público.
Para todos los demás, la respuesta es dejar de tratar el icono de app ausente como algo por lo que disculparse o que arreglar tarde o temprano. Construir en su lugar, y bien, la experiencia web móvil: un sitio rápido e instalable con un manifiesto real, un aviso para añadir a la pantalla de inicio mostrado en un momento sensato en lugar de al cargar la página, y notificaciones push a las que el usuario se suscribe de verdad. Eso no es aquí el plan B. Es la única estrategia móvil que no termina en una carta de rechazo y, si se insiste lo suficiente, un aviso de cierre de cuenta para un negocio que de todos modos nunca iba a ser admitido.
