---
title: "Prepara tu app para la revisión en las stores"
description: "Consejos para que tu aplicación sea aprobada en App Store y Google Play Store"
---

Este artículo describe el proceso que siguen las stores al revisar las aplicaciones enviadas, y ofrece consejos para conseguir una aprobación más rápida. La información se basa en las guías oficiales de envío:

* [Guías de envío de App Store](https://developer.apple.com/app-store/review/guidelines/)
* [Guías de envío de Google Play Store](https://play.google/developer-content-policy/)

:::important
Ambas stores siguen un proceso de revisión similar. Cuando una política solo aplica a una de ellas, el artículo menciona la store por su nombre.
:::

Los usuarios de Adapty deben prestar especial atención al cumplimiento de los requisitos relacionados con [paywalls y compras in-app](#iap-related-requirements), ya que son de los motivos de rechazo más frecuentes.

## Antes de empezar \{#before-you-begin\}

Confirma que tu aplicación está lista para el envío.

Adapty ofrece una [lista de verificación para el lanzamiento](release-checklist) para preparar tu app para su publicación.

Google Play Store exige a los editores nuevos que [prueben la app](https://support.google.com/googleplay/android-developer/answer/14151465?hl=en) antes de enviarla. La prueba debe contar con al menos 12 personas y durar un mínimo de 14 días consecutivos. Este requisito se introdujo en 2025 para reducir el número de apps con errores que llegan al equipo de revisión de Google.

## Resumen del proceso de revisión \{#review-process-overview\}
####  Paso 1: El análisis automatizado \{#step-1-the-automated-screening\}

Tanto App Store como Google Play Store siguen un proceso de revisión en dos pasos. Justo después del envío, tu app pasa por un análisis automatizado que puede tardar varias horas.

Ambas stores analizan tu app en busca de malware, y Google hace especial hincapié en este proceso. Busca indicadores de comportamiento malicioso, como contacto con servidores sospechosos y acceso injustificado a datos del usuario. Si tu aplicación se considera potencialmente dañina, se marca y se pasa a un analista de seguridad humano. La [documentación de Google Play Protect](https://developers.google.com/android/play-protect/cloud-based-protections#machine-learning) contiene una lista aproximada de las comprobaciones realizadas en este paso.

Las stores también verifican la presencia de los metadatos necesarios, la ausencia de dependencias dañinas o muy desactualizadas, y la integridad de tu build.

#### Paso 2: La revisión humana \{#step-2-the-human-review\}

Una vez que tu app supera el análisis automatizado, la examina un revisor humano. Este paso puede tardar varios días, según la complejidad de tu app y la cola de revisión en ese momento. Las apps que procesan datos sensibles tardan más en revisarse.

## Requisitos generales \{#general-requirements\}

### Estabilidad \{#stability\}

Las aplicaciones que se cierran inesperadamente durante la revisión son rechazadas. Los revisores pueden simular intencionalmente condiciones de red poco fiables, por lo que la app debe ser capaz de gestionarlas correctamente.

### Completitud \{#completeness\}

Tanto Apple como Google imponen un requisito de *completitud* ("funcionalidad mínima") sobre el contenido de la store.

* Los marcadores de posición, las pantallas de "próximamente" y las funcionalidades rotas dan lugar a rechazos en apps de iOS.
* Google es [más flexible](https://support.google.com/googleplay/android-developer/answer/9898783?hl=en), especialmente si tu aplicación está en [Acceso Anticipado](https://knowledge.workspace.google.com/admin/users/access/turn-early-access-apps-on-or-off-for-users).
* Ambas stores **rechazan apps** con poca o ninguna funcionalidad. Esto incluye apps que muestran una sola imagen, un archivo PDF o una página web.

La falta de contenido entra en la misma categoría.

* Si la app no cumple lo que anuncias, será rechazada.
* Si configuras una compra in-app en tu dashboard pero no la incluyes en el build, la app será rechazada.

### Precisión de los metadatos \{#metadata-accuracy\}

La información engañosa, inexacta o inconsistente en la descripción, capturas de pantalla y otros metadatos puede llevar al rechazo.

No uses tu ficha en la store para anunciar funcionalidades futuras de la app.

Si la app no está diseñada para el público en general, el revisor buscará documentación adicional que explique sus flujos de trabajo. Incluye instrucciones claras en los metadatos de la app.

### Clasificación de contenido \{#content-rating\}

El contenido de tu app debe coincidir con la clasificación que has declarado.

### Aspectos legales \{#legal-aspects\}

* La política de privacidad de tu app debe ser accesible desde dentro de la app. Puedes usar el [botón de enlace](paywall-buttons#links) del Paywall Builder.
* Exige a los usuarios que lean y acepten cualquier acuerdo legal **antes** de que entre en vigor.
* Indica la presencia de publicidad en tu app. No hacerlo puede resultar en un rechazo.
* Si tu app de iOS incluye compras in-app, debes aceptar el **Paid Apps Agreement** en tu dashboard de App Store Connect.

### Autenticación \{#authentication\}

Si parte del contenido de tu app solo está disponible tras autenticarse, proporciona credenciales de acceso válidas al revisor de la store. No poder acceder al contenido de forma completa justifica un rechazo.

Si tu app permite a los usuarios crear una cuenta, también debe permitirles eliminarla. Dirigir a los usuarios a soporte por correo electrónico o a un sitio web no cumple este requisito.

### Acceso y privacidad \{#access-and-privacy\}

Los metadatos de la app deben indicar claramente el motivo de cada permiso solicitado. Los permisos más sensibles (por ejemplo, acceso a mensajes de texto y registros de llamadas) pueden requerir una demostración en vídeo.

El mismo principio aplica a los datos sensibles del usuario: si los solicitas, explica por qué.

## Requisitos relacionados con las compras in-app \{#iap-related-requirements\}

Las infracciones de política de negocio son uno de los motivos de rechazo más habituales. Si los principales métodos de monetización de tu aplicación son las suscripciones y las compras in-app, estará sujeta a un escrutinio mayor.

### Requisitos del paywall \{#paywall-requirements\}

Los revisores de apps esperan paywalls sencillos y fáciles de entender.

Si se sospecha que estás manipulando a los usuarios, la app es rechazada. Si varias revisiones encuentran evidencias de prácticas engañosas, tu cuenta puede ser desactivada y tu app [suspendida](https://support.google.com/googleplay/android-developer/community-guide/287283557/app-suspended-for-repeated-rejections?hl=en). Google Play utiliza un [sistema de sanciones](https://support.google.com/googleplay/android-developer/answer/9899234?hl=en) que puede llevar a que todas tus apps sean eliminadas.

Sigue estas prácticas en el diseño de tu paywall:

- **Sé transparente y directo.**

    Muestra el precio exacto, la frecuencia de facturación, los beneficios y las condiciones de cancelación de los productos antes de invitar al usuario a comprar.

    Diferencia claramente entre compras únicas y productos que requieren pagos recurrentes.

    Si un producto incluye una prueba gratuita, indica claramente su duración y condiciones.

    No uses un lenguaje intencionalmente confuso para engañar al usuario.

    

- **Sé coherente.**

    Los precios de los productos deben coincidir en la ficha de App Store, las pantallas dentro de la app, las pantallas de gestión de suscripciones y el contenido de marketing. Cualquier discrepancia de precios, por pequeña que sea, es motivo de rechazo.

    El Paywall Builder de Adapty sincroniza automáticamente los precios entre tu paywall y tu producto en App Store Connect. Si tu paywall está codificado manualmente, debes [obtener el precio de cada producto](fetch-paywalls-and-products) desde su array de datos.

- **Muestra todos los niveles en igualdad de condiciones.**

    No preselecciones la opción más cara ni ocultes las más baratas.

- **Evita los "dark patterns".**

    No generes una falsa sensación de urgencia o escasez.

    No fuerces a los usuarios a realizar compras haciendo que las funcionalidades gratuitas sean incómodas o difíciles de encontrar intencionalmente.

    

### Garantía de acceso \{#access-guarantee\}

La aplicación debe garantizar el derecho de los usuarios a acceder a sus compras.

* **Acceso inmediato**

    Una compra exitosa debe desbloquear el acceso al producto de forma inmediata, sin retrasos visibles.

    Los estados intermedios de autorización de pago no deben generar errores ni romper la experiencia de usuario.

    Una compra exitosa debe ocultar el paywall de inmediato. Si sigues mostrando el paywall tras una compra, impides que el usuario acceda al contenido que ha pagado.

* **Restauración del acceso**

    El usuario debe poder restaurar el acceso al producto desde un nuevo dispositivo. Coloca el botón de restaurar en un lugar visible.

    Si creaste el paywall con el [Paywall Builder](adapty-paywall-builder), el botón de restaurar activa automáticamente el proceso de restauración. Si [implementaste un paywall manual](ios-implement-paywalls-manually), añade código que ejecute el método [restorePurchases](restore-purchase). Adapty restaurará el nivel de acceso del usuario, **salvo** que uses el SDK en [modo observador](observer-vs-full-mode).

    La app debe ser capaz de reconocer las compras in-app realizadas desde la página de la store del producto o desde cualquier otro lugar de la store.

### Métodos de pago apropiados \{#appropriate-payment-methods\}

Ambas stores prohíben la venta de bienes físicos con compras in-app y exigen la facturación dentro de la store para la mayoría de los bienes digitales.

El requisito de facturación dentro de la store no aplica en algunas jurisdicciones geográficas, incluidas EE. UU. y la UE. Según el país, puede que puedas [saltarte la facturación dentro de la store por completo](https://support.google.com/googleplay/android-developer/answer/16497028) o [presentar al usuario una elección](https://support.google.com/googleplay/android-developer/answer/13821247) entre la facturación de la store y la facturación alternativa.

Algunas categorías de apps (como lectores de e-books o apps de citas) pueden ser elegibles para métodos de pago alternativos incluso fuera de estas regiones. Consulta las guías oficiales de las stores para más detalles.

:::tip
A diferencia de [Google](https://support.google.com/googleplay/android-developer/answer/13821247), Apple no ofrece una lista definitiva de países que permiten métodos de facturación alternativos. A medida que nuevas jurisdicciones aprueben leyes similares, la disponibilidad irá aumentando. Lee la documentación correspondiente a tu país en particular antes de continuar.
:::

Ten en cuenta que ambas stores aplican sus propias normas para las integraciones con proveedores de pago, y siguen cobrando comisiones por las transacciones que usan estos servicios.

## Cómo gestionar un rechazo \{#handling-rejection\}

Si tu aplicación es rechazada, el revisor indicará qué directriz(ces) ha infringido. Lee la directriz completa y corrígela:

* [Guías de envío de App Store](https://developer.apple.com/app-store/review/guidelines/)
* [Guías de envío de Google Play Store](https://play.google/developer-content-policy/)

Si crees que el rechazo fue injusto, tienes derecho a apelar. Aporta pruebas de cumplimiento y contacta con la store.

* No actualices la app mientras está siendo revisada.
* Cada vez que envíes tu aplicación para revisión, puede que te toque un revisor diferente. Esto puede jugar a tu favor o en tu contra.
* No corrijas los problemas uno a uno. Envía la app para revisión cuando todas las correcciones estén listas.
* Si Google Play rechazó tu aplicación por infracciones de política, actualiza los datos en cuestión en todos los canales, incluso si están pausados o inactivos.
* Las revisiones posteriores suelen tardar menos que la primera.
* La revisión urgente puede estar disponible para errores críticos y plazos inminentes — úsala con moderación.

## Después de la revisión: supervisión continua \{#after-the-review-continuous-monitoring\}

Ambas stores continúan supervisando tu aplicación incluso después de que supere el proceso de revisión.

Si la función de tu app cambia tras la aprobación (por ejemplo, debido a código cargado de forma dinámica), será marcada y dada de baja. Una avalancha de comentarios negativos de los usuarios también es motivo de un escrutinio adicional.

Entre 2024 y 2025, Google [eliminó el 47% de las apps de su Play Store](https://techcrunch.com/2025/04/29/google-play-sees-47-decline-in-apps-since-start-of-last-year/) para aumentar su calidad media.

Abandonar tu app también conlleva riesgos. Tanto [Google](https://www.cnet.com/tech/mobile/google-play-store-will-hide-apps-that-havent-been-updated-in-years/) como [Apple](https://developer.apple.com/support/app-store-improvements/#:~:text=Developers%20of%20apps%20that%20have,launch%20will%20be%20removed%20immediately.) dan de baja apps que no reciben actualizaciones ni descargas.

## Ver también \{#see-also\}

* [Pruebas en sandbox](test-purchases-in-sandbox)
* [Lista de verificación para el lanzamiento](release-checklist)