Casos de rechazo en App Store / Google Play y una checklist práctica para pasar la revisión

Estás a punto de publicar la app y la revisión te la devuelve. Es una barrera que muchos desarrolladores atraviesan al menos una vez.

Además, las razones por las que una revisión se detiene no se limitan a crashes o builds defectuosos. Las explicaciones de permisos, la política de privacidad, el flujo de pago, los metadatos del store o unas notas de revisión insuficientes también pueden ser la causa. No es raro que aspectos operativos fuera de la implementación terminen provocando el rechazo.

En este artículo organizo por categorías los casos de rechazo más frecuentes en App Store y Google Play, y resumo desde una perspectiva práctica qué conviene revisar antes del envío.

Público objetivo

• Personas que van a enviar una app a App Store / Google Play por primera vez
• Personas que ya sufrieron un rechazo y quieren ordenar la causa
• Personas que desarrollan con stacks cross-platform como React Native o Flutter
• Equipos que quieren preparar una checklist antes del lanzamiento

Términos que conviene fijar primero

Antes de entrar en materia, conviene ordenar brevemente los términos que aparecen más adelante. Si tienes esto claro desde el principio, la segunda mitad del artículo se lee mucho mejor.

• reviewer: La persona de Apple o Google que revisa la app. No solo comprueba el binario, sino también la descripción del store, las capturas, la información declarada y las notas de revisión.
• IAP (In-App Purchase): El mecanismo de compra dentro de la app de Apple para vender contenido digital o funciones internas.
• ATT (App Tracking Transparency): El mecanismo de iOS que pide permiso al usuario antes de hacer tracking a través de apps o sitios web de terceros.
• IDFA: Identificador usado para medición publicitaria. Si tu configuración lo utiliza, normalmente tendrás que revisar ATT y App Privacy.
• Data safety / App Privacy: Formularios de auto-declaración de recogida de datos en Google Play / App Store. Si añades un SDK y no actualizas la declaración, aparece una incoherencia.
• target SDK: Valor que indica para qué nivel de API de Android está pensada la app. minSdkVersion representa el OS mínimo soportado, así que no significa lo mismo.
• metadatos del store: El conjunto de información que se muestra o se entrega en el store, como capturas, texto descriptivo, subtítulo, categoría, clasificación por edades y campos declarativos.
• WebView: Componente que muestra una página web dentro de la app. Es útil, pero si la mayor parte de la pantalla depende de WebView, el valor nativo se percibe como débil.
• UGC (User Generated Content): Contenido generado por usuarios, como comentarios, subida de imágenes, perfiles o reseñas.
• restore purchases: El flujo para restaurar compras anteriores. Es importante para comprobar suscripciones y compras únicas.
• entitlement: Ajuste de permisos para una capability de Apple o una función específica. Muchas sirven en apps normales, pero algunos entitlements especiales requieren aprobación de Apple o condiciones extra.

Primero hay que entender la perspectiva de revisión

Para reducir rechazos, leer las guidelines no basta. Es más útil entender qué comprueba el reviewer en poco tiempo, porque eso permite priorizar mejor las acciones.

Los estados que más suelen bloquearse son estos:

• La implementación existe, pero la explicación es insuficiente
• Se solicita un permiso, pero no se ve su relación con la función
• Hay cobro, pero el precio o la vía de cancelación son ambiguos
• Las capturas o el texto no coinciden con la app real
• El reviewer no puede iniciar sesión y no logra revisar las funciones principales

Antes que la belleza visual, la revisión se fija sobre todo en seguridad, consistencia y completitud.

Ordenar primero las diferencias entre App Store y Google Play

Ambas plataformas quieren una app segura, no engañosa y no inacabada, pero los puntos donde más suelen bloquear difieren un poco.

Dicho de forma simple, App Store suele frenar más por la rigurosidad de la experiencia, los pagos y las explicaciones de privacidad, mientras que Google Play suele frenar más por los requisitos técnicos y la coherencia de la auto-declaración.

Por eso, incluso para la misma app, el orden de preparación cambia un poco.

• App Store: ajustar primero el comportamiento en dispositivo real, la pantalla de pago, los textos de permisos y las notas de revisión
• Google Play: ajustar primero target SDK, permissions, Data safety y declaración de anuncios

Estudios de caso a partir de mensajes reales de bloqueo y rechazo

Aquí cito mensajes típicos de revisión de App Store y de bloqueo de publicación de Google Play para ordenar qué significa realmente cada frase y qué deberías corregir primero. Las categorías de la segunda mitad funcionan muy bien como explicación detallada de estos casos.

Case 1: crash justo después del arranque en App Store

"Descubrimos uno o más bugs en su app al revisarla en un iPhone con iOS 17.0 en Wi-Fi. En concreto, la app se cerró inmediatamente después del lanzamiento."

Esto no se trata como un fallo temporal, sino como un defecto grave que se reproduce en el dispositivo de revisión. Lo primero que hay que hacer es comprobar la reproducción en modo avión, con instalación limpia, con una cuenta vacía y en red lenta, y listar todo lo que se ejecuta justo después del arranque.

Case 2: falta Privacy Policy en App Store

"Su app recopila datos del usuario o de uso, pero no tiene una privacy policy URL."

Esto significa que la app maneja datos a través de SDKs o APIs propias, pero la explicación pública visible para el usuario es insuficiente. Lo primero que hay que hacer es publicar una URL pública en la que se indiquen los datos recogidos, la finalidad, la posible cesión a terceros y el contacto, y después alinear App Store Connect con App Privacy.

Case 3: los cobros digitales no usan IAP en App Store

"Su app incluye la posibilidad de comprar contenido digital, pero el mecanismo de compra no utiliza in-app purchase."

No es un problema de cómo se muestra el precio. El aviso dice que el método de cobro no corresponde con la naturaleza de lo que se vende. Lo primero que hay que hacer es descomponer exactamente qué se vende y mover hacia un diseño basado en IAP todo lo que sea valor digital consumido dentro de la app.

Case 4: Google Play no cumple con el requisito de target API

"Cuando publica una nueva app, debe dirigirla a Android 15 (API level 35) o superior."

Google Play no solo usa rejection mails clásicos. También puede mostrar condiciones previas como bloqueo antes de publicar. Cuando aparece este texto, el problema todavía no es la calidad de la app, sino un requisito de publicación no cumplido. Lo primero que hay que hacer es preparar un plan de actualización que cubra no solo targetSdkVersion, sino también librerías dependientes, diferencias de permisos, notificaciones y comportamiento en segundo plano.

Case 5: una nueva personal account de Google Play no puede pasar a production

"Debe ejecutar un closed test para su app con un mínimo de 12 testers que hayan permanecido opted-in de forma continua durante los últimos 14 días."

En una primera publicación, puedes quedarte bloqueado por un production gate derivado del tipo de account, aunque la calidad de la app sea buena. Una nueva personal account no puede publicar mientras no cumpla las condiciones de closed test y production access. Además, puede exigirse que el account owner complete la device verification en un Android real.

Lo primero que hay que hacer es confirmar si la cuenta objetivo es una nueva personal account y completar cuanto antes el closed test de 12 personas / 14 días, el opt-in continuado de los testers y la device verification usando la Play Console mobile app.

En App Store estos temas suelen volver como comentarios de revisión, mientras que en Google Play suelen bloquear mediante requisitos de Console o diferencias en las declaraciones. Pero, en esencia, la mayoría de casos cae en una de estas categorías: app inacabada, explicación insuficiente, declaración incoherente o requisito de publicación no cumplido.

Categoría 1: Completitud de la app

1. La app falla justo después del arranque

Errores de API en el primer inicio, fallos al inicializar la DB local o accesos a nil son de los motivos de devolución más típicos. Aquí, acceso a nil significa que la app intenta leer un objeto antes de que tenga un valor válido. Como el entorno del reviewer nunca coincide exactamente con el tuyo, conviene proteger de más la seguridad del arranque.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onAppear {
                    setupApp()
                }
        }
    }

    private func setupApp() {
        do {
            try initializeDatabase()
        } catch {
            print("DB init failed: \(error)")
        }
    }
}

Qué conviene comprobar:

• La app no falla en el primer arranque aunque todavía no exista cuenta
• La app puede arrancar incluso sin red
• Si falla la obtención de datos obligatorios, la app aún puede pasar a una pantalla de fallback

Una solución eficaz es separar el procesamiento de arranque en dos tipos:

• Lo que tiene que salir bien sí o sí antes de poder mostrar algo
• Lo que puede fallar y reintentarse más tarde

Por ejemplo, no hace falta bloquear toda la app por cargar la configuración remota o precargar recomendaciones. Si primero muestras la home o al menos una estructura mínima y luego reintentas solo lo que falló, la app se rompe mucho menos ante diferencias del entorno de revisión.

En la práctica suele ser más rápido corregirlo en este orden:

• Recoger el crash log
• Enumerar toda la inicialización que ocurre en el arranque
• Reducir el código síncrono que tiene que salir bien obligatoriamente
• Probar en dispositivo real con modo avión, instalación limpia y datos vacíos

2. Hay funciones sin implementar o siguen quedando placeholders

Pantallas que solo dicen "Coming Soon", botones que no hacen nada o enlaces rotos son señales que hacen que la app parezca inacabada.

Justo antes del envío, suele ser más seguro priorizar lo siguiente por encima de añadir nuevas funciones:

• Eliminar funciones no implementadas que ya tienen entrada en la navegación
• Quitar textos de prueba y copy temporal
• Llevar pantallas de error y estados vacíos a un nivel mínimo aceptable

3. Sin login no se puede verificar nada

Incluso en apps con login obligatorio, el rechazo es más probable si el reviewer no puede llegar a las funciones principales.

Lo que hace falta no es solo una cuenta, sino el camino de verificación más corto posible.

• Preparar una demo account
• Si hace falta 2FA, escribir los pasos
• Si hay funciones visibles solo para un rol concreto, aclararlo
• Si hacen falta sandbox data, explicar el estado inicial

La idea base es crear una situación en la que la persona de revisión pueda confirmar el valor de la app por el camino más corto. Lo ideal es ofrecer una cuenta de revisión read-only que permita ver las pantallas principales sin registro ni contacto con soporte.

Aquí, sandbox data significa datos ficticios para revisión y verificación que no afectan a usuarios reales. Historiales de pedidos, publicaciones, estado de suscripción o datos de tiendas en el mapa se revisan mucho mejor si no están vacíos.

Si la app depende de verificación por SMS o invitación, es más seguro no dejar ese problema tal cual en manos del reviewer.

• Emitir una cuenta de revisión con validez larga
• Si 2FA es obligatorio, adjuntar código de respaldo o procedimiento alternativo
• Si un estado inicial vacío impide entender el valor, precargar datos de prueba
• Usar la plantilla que aparece más adelante para describir también el camino hasta la función

Categoría 2: Privacidad y permisos

4. No existe una URL de política de privacidad

Si la app trata datos de usuario o de uso y no tiene una Privacy Policy URL, el riesgo es alto. Es menos un problema del binario en sí y más una carencia en la información de envío.

Como mínimo, conviene que la política de privacidad deje claros estos puntos:

• Qué tipos de datos se recogen
• Con qué finalidad se usan
• Si se comparten o no con terceros
• Durante cuánto tiempo se conservan
• Cómo puede el usuario pedir borrado o corrección

Lo fácil de confundir aquí es que Privacy Policy y App Privacy / Data safety no son lo mismo.

• Privacy Policy: Documento público que el usuario puede leer
• App Privacy / Data safety: Auto-declaración que se entrega al store

Tener solo una de las dos no basta. También tienen que coincidir en contenido.

La vía más rápida suele ser publicar primero una página pública que explique qué recoges, para qué lo usas y cómo pueden contactarte. Después, compara eso con el inventario de SDKs y actualiza las declaraciones en App Store Connect / Play Console.

5. La app solicita permisos que no usa

Permisos como ubicación, contactos, micrófono o cámara generan desconfianza si no están claramente atados a una función. En muchos casos, una librería introduce permisos innecesarios como efecto colateral.

import { Alert } from 'react-native'
import * as Location from 'expo-location'

async function requestLocationForMap() {
  const { status } = await Location.requestForegroundPermissionsAsync()
  if (status !== 'granted') {
    Alert.alert('Se necesita permiso de ubicación para mostrar tiendas cercanas en el mapa')
    return
  }

  // Flujo de visualización del mapa
}

La idea clave es solicitar solo los permisos que realmente se usan, y en el momento en que se usan.

El truco práctico es no limitarse a buscar peticiones de permisos en el código, sino revisar también las declaraciones que llegan a través de dependencias. En Android eso significa AndroidManifest.xml; en iOS, Info.plist junto con los SDKs instalados. De lo contrario, es fácil dejar permisos involuntarios.

6. El texto del permiso es demasiado abstracto

Frases como "para mejorar la experiencia" no explican para qué sirve realmente el permiso. El texto debe estar ligado a una función concreta.

Buenos ejemplos:

• Para mostrar tiendas cercanas en el mapa
• Para tomar una foto de perfil
• Para usar la cámara para escanear códigos de barras

Ejemplos débiles:

• Para mejorar la experiencia
• Para mejorar la comodidad
• Para mejorar la calidad del servicio

<key>NSLocationWhenInUseUsageDescription</key>
<string>Se utiliza para mostrar tiendas cercanas en el mapa</string>

<key>NSCameraUsageDescription</key>
<string>Se utiliza para tomar una foto de perfil</string>

7. App Tracking Transparency no está bien resuelto

Si la app usa IDFA, hace falta coherencia entre el diálogo ATT y la declaración App Privacy. Además, la app debe estar diseñada para funcionar incluso si el usuario no concede permiso de tracking.

Aquí, ATT es el mecanismo que pide autorización antes de acceder a IDFA, muy usado en medición publicitaria y attribution. En la práctica basta con entenderlo así: si has metido un SDK de anuncios, si un SDK de analítica lee IDFA o si sigues al usuario a través de datos de terceros, esta zona recibirá más atención en la revisión.

import AppTrackingTransparency

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            break
        case .denied, .restricted, .notDetermined:
            break
        @unknown default:
            break
        }
    }
}

En la práctica, el orden razonable de corrección es este:

• Inventariar qué SDKs usan IDFA o tracking
• Reevaluar si el tracking es realmente necesario
• Si no lo es, quitar la configuración o la dependencia correspondiente para volver innecesario ATT
• Si sí lo es, alinear el diálogo ATT, App Privacy y la explicación dentro de la app
• Confirmar que las funciones principales funcionan aunque el permiso se deniegue

Categoría 3: Pagos y modelo de negocio

8. Se dirige el contenido digital a un pago externo

Si la app vende bienes digitales o desbloqueos de funciones dentro de la app, App Store espera en principio el uso de IAP. Dirigir al usuario hacia pagos web o compras en sitios externos tiene muchas probabilidades de bloquearse.

La idea importante es esta:

• Los bienes físicos y servicios presenciales suelen poder usar pago externo
• El contenido digital y las funciones premium deberían usar IAP en principio
• Si una Reader App muestra enlaces a creación o gestión de cuenta en un sitio externo, necesita External Link Account Entitlement
• Incluso cuando existe la excepción Reader App, las categorías y condiciones de implementación son bastante limitadas

Si dudas sobre si usar IAP, ayuda pensar si lo que vendes es valor digital que se consume dentro de la app.

• Casos más cercanos a IAP: quitar anuncios, funciones premium, moneda de juego, artículos ilimitados, acceso ilimitado a vídeo
• Casos que suelen permitir pago externo: productos físicos, ride hailing, clases presenciales, delivery de comida, reservas hoteleras

Si ya dirigías a facturación externa y eso fue lo que bloqueó la revisión, normalmente tienes que moverte en una de estas direcciones:

• Replantear el cobro alrededor de IAP
• Confirmar con rigor si la app encaja realmente en las condiciones de Reader App
• Separar bienes digitales y servicios físicos y reorganizar el flujo dentro de la app

9. La explicación de la suscripción es débil

En suscripciones, si el precio, el ciclo de renovación, el auto-renew o la vía de cancelación quedan ambiguos, la interfaz parece débil desde la perspectiva de protección del usuario.

Como mínimo, la paywall o la descripción del store deberían dejar claros estos puntos:

• Nombre del plan, duración y qué incluye
• El importe total a cobrar aparece claramente; si es anual, la cifra anual debe verse como la principal
• Se entiende el ciclo de renovación y que es auto-renew
• Se entiende el precio normal después del trial gratuito
• Hay enlaces a Terms of Service y Privacy Policy
• Existe una vía de sign in o restore purchases para suscriptores existentes
• Se entiende cómo cancelar

Un fallo habitual es destacar en grande el equivalente mensual y hacer difícil de entender el importe real que se cobra y las condiciones de renovación. Para un plan anual es más seguro mostrar claramente el total anual y dejar el cálculo mensual como dato complementario.

Para revisar una pantalla de suscripción, suele servir esta estructura:

• Nombre del plan
• Momento del cobro
• Importe total
• Precio normal después del trial
• Ruta de restauración
• Términos del servicio y política de privacidad
• Pantalla de gestión o vía de cancelación

Por ejemplo, una frase como "7 días gratis y luego renovación automática por 7.200 JPY al año" reduce malentendidos en revisión porque deja claro en una sola oración qué pasa tras el periodo gratis.

Para que la pantalla de compra sea más resistente en revisión, también ayuda resolver dentro de la propia pantalla las preguntas en las que más se suelen perder los usuarios:

• Qué plan está seleccionado ahora
• Cuánto se cobrará en este momento
• Cuánto costará cuando termine el periodo gratuito
• Hasta cuándo hay que cancelar para evitar el siguiente cobro
• Dónde puede restaurar la compra un suscriptor existente

// React Native por sí solo no puede abrir directamente la system-provided UI de StoreKit,
// así que este es un ejemplo de fallback cuando no puedes hacer bridge con una implementación nativa de iOS.
import { Linking, Text, TouchableOpacity } from 'react-native'

function SubscriptionSettings() {
  return (
    <TouchableOpacity
      onPress={() => Linking.openURL('https://apps.apple.com/account/subscriptions')}
    >
      <Text>Gestionar suscripción</Text>
    </TouchableOpacity>
  )
}

Si puedes implementar la parte nativa en iOS, resulta más natural abrir la system-provided management UI con showManageSubscriptions(in:), como indica Apple.

10. La excepción Reader App se interpreta de forma demasiado amplia

La excepción Reader App parece cómoda, pero su alcance es bastante limitado. La función principal debe ser realmente revistas, periódicos, libros, audio, música o vídeo, y la app debe usarse para acceder a contenidos o suscripciones comprados fuera de la aplicación.

Además, mostrar enlaces de creación o gestión de cuenta hacia un sitio externo exige External Link Account Entitlement. Las apps que ofrecen IAP en iOS / iPadOS / tvOS no pueden acogerse a ese entitlement, así que es incorrecto asumir que, por ser Reader App, puedes dirigir libremente a pagos externos.

El vídeo, la música o los libros se tratan de forma distinta a las funciones de app o la moneda de juego. Si envías la app sin aclarar bien en qué categoría cae, el criterio será más inestable.

Si hay dudas, es más seguro ordenar si vendes contenido o funcionalidad, y dónde está el flujo de compra, y explicarlo también en la ficha store y en las notas de revisión.

En la práctica, estas tres preguntas Yes / No ayudan a decidir antes del envío:

• La función principal, ¿es realmente ofrecer revistas, periódicos, libros, audio, música o vídeo?
• La estructura, ¿está pensada para acceder a contenido ya comprado fuera de la app?
• La versión de iOS, ¿evita ofrecer IAP?

Si una sola de estas tres preguntas queda ambigua, es más seguro no diseñar la app apoyándote en la excepción Reader App.

Categoría 4: Diseño y calidad de la experiencia

11. La UI se desvía demasiado de lo esperado por la plataforma

Sistemas de navegación completamente propios, ausencia de una ruta de vuelta o contrastes difíciles de leer reducen la percepción de usabilidad. En revisión suele ser mejor priorizar una interacción alineada con la plataforma antes que una originalidad visual excesiva.

12. Parece que la app solo envuelve un WebView

Una app que en la práctica solo muestra un sitio web puede verse como una experiencia nativa con poco valor.

Patrones de riesgo:

• Casi toda la pantalla es un WebView
• No hay funciones específicamente nativas
• No funciona nada sin conexión
• No hay valor propio de app como integración con el device o notificaciones

Para evitar parecer un simple wrapper, conviene dejar muy claro el valor de integración con el device mediante compartir, notificaciones, cámara, almacenamiento local, UX offline y similares.

WebView en sí no es el problema. El problema es presentar una app nativa cuyo contenido parece casi igual al sitio web. Si usas WebView, conviene aportar valor nativo en al menos uno de estos puntos:

• Navegación o ajustes nativos
• Funciones del device como compartir, notificaciones, cámara o guardar archivos
• Explicaciones offline o visualización en caché
• Interacción propia de la app que no exista en la versión web

13. Los anuncios o el flujo de pago son excesivos

Si la publicidad llama más la atención que el contenido, si el layout provoca taps accidentales o si se usan demasiados interstitials difíciles de cerrar, eso perjudica tanto la revisión como las valoraciones. La monetización puede existir, pero hay que comprobar en dispositivo real que no rompe la experiencia.

Categoría 5: Metadatos del store e información declarada

La revisión no solo mira la app en sí, sino también la descripción del store y las declaraciones. Si ahí hay desviaciones respecto a la realidad, la app puede bloquearse incluso si la implementación es correcta.

Elementos que conviene revisar:

• Capturas de pantalla
• Descripción de la app
• Subtítulo
• Clasificación por edades
• App Privacy / Data safety
• Declaración sobre presencia de anuncios

Lo especialmente peligroso es describir funciones que aún no están implementadas. También conviene evitar anunciar funciones previstas para el futuro.

Categoría 6: UGC y categorías de alto riesgo

14. Hay UGC pero no existe un flujo de moderación

Si la app gestiona contenido generado por usuarios, no basta con tener una función de publicación. Como mínimo, conviene ofrecer estas vías:

• Función de reporte
• Función de bloqueo
• Términos de uso
• Canal de contacto
• Política de actuación ante contenido infractor

Si hay UGC pero no se ven mecanismos de defensa, la parte de revisión tiende a preocuparse por el riesgo operativo.

15. Falta responsabilidad explicativa en salud, finanzas o infancia

Apps médicas o de salud, de finanzas o inversión, dirigidas a niños o con uso continuo de localización se revisan con más dureza que una categoría general. Conviene asumir un listón más alto en precisión, cumplimiento legal, claridad sin ambigüedad y visibilidad del contacto.

Especialmente en estas categorías, un texto que parece útil a nivel comercial puede jugar en contra. Las expresiones sobre salud o inversión deben evitar garantías de resultado, equívocos o expectativas excesivas.

En la práctica, se reducen accidentes revisando estas preguntas:

• Salud o medicina: ¿evitas afirmar de forma categórica un diagnóstico o tratamiento?
• Finanzas: ¿evitas prometer beneficios o alimentar expectativas excesivas?
• Infantil: ¿los enlaces externos, anuncios o flujos de pago no son demasiado agresivos?
• Localización continua: ¿es realmente necesaria la recogida permanente o existe una alternativa?

En esta categoría importa más comprobar si estás exagerando y si cumples con tu deber de explicación que añadir nuevas funciones.

Cómo leer las frases de rechazo más habituales

Los mensajes de revisión suelen ser cortos y abstractos, así que leerlos tal cual no siempre deja claro qué hay que corregir. En la práctica, se vuelven más accionables si se reinterpretan de esta manera.

La clave aquí es leer el texto de revisión como si fuera una especificación. Aunque parezca abstracto, la mayoría de los casos se clasifican como app inacabada, explicación insuficiente o declaración incoherente.

Puntos fáciles de pasar por alto en Google Play

Requisitos de primer lanzamiento para una nueva personal account

Si vas a publicar por primera vez en Google Play, esto es especialmente importante. Una personal developer account recién creada tiene requisitos a nivel de cuenta para poder avanzar hacia production, aparte del contenido de la app.

Dos de los más representativos son estos:

• Deben participar de forma continua al menos 12 testers en el closed test
• Debe completarse la device verification de Android usando la Play Console mobile app

Esto funciona menos como un correo clásico de rechazo y más como un bloqueo dentro de Play Console que no te deja avanzar a production. Es decir, aunque la app esté lista, no podrás publicarla si no se cumplen las condiciones del lado de la cuenta.

Puntos en los que más se atasca un primer lanzamiento:

• Hay suficientes testers, pero no se cumple el opt-in continuado durante 14 días
• Los testers se han unido, pero el uso real o el feedback son escasos
• El account owner no ha completado la device verification
• Se asume que un internal test es suficiente y se pasa por alto el requisito de closed test

Si es tu primera publicación, es más seguro despejar estos requisitos muy pronto en paralelo con las verificaciones de implementación.

Retraso en la actualización del target SDK

Los requisitos de Google Play sobre target API level cambian continuamente. Por eso hace falta una práctica operativa: comprobar en Play Console el requisito vigente en el momento del envío, no el número que era actual cuando se escribió este artículo.

Lo fácil de confundir aquí es la diferencia entre targetSdkVersion y minSdkVersion.

• targetSdkVersion: Hasta qué punto asumes soporte para comportamientos nuevos de Android
• minSdkVersion: Hasta qué versiones antiguas de Android sigues dando soporte

Es decir, aunque no subas minSdkVersion, Google Play puede bloquear la publicación solo porque targetSdkVersion no alcanza el requisito vigente.

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    defaultConfig {
        targetSdkVersion rootProject.ext.targetSdkVersion
        minSdkVersion 24
    }
}

La clave es no quedarse en cambiar el número. Subir el target SDK puede modificar el modelo de permisos, las restricciones en background, el comportamiento de notificaciones, los foreground services, el acceso a archivos y más. Al actualizarlo conviene revisar en conjunto:

• Compatibilidad de Android Gradle Plugin y dependencias
• Diferencias de comportamiento en los diálogos de permisos
• Restricciones sobre notificaciones y trabajo en segundo plano
• Pruebas en los principales devices objetivo

Quedan permisos sensibles en el manifest

Si quedan permisos sensibles sin uso en el manifest, solo eso ya crea una carga de explicación. En especial conviene revisar con cuidado CONTACTS, CALL_LOG, SMS y READ_PHONE_STATE.

<!-- No declares permisos que no uses -->
<!-- <uses-permission android:name="android.permission.READ_CONTACTS" /> -->
<!-- <uses-permission android:name="android.permission.READ_CALL_LOG" /> -->

Data safety no coincide con la implementación

Es más frecuente de lo que parece añadir un Analytics SDK o un SDK de anuncios y dejar obsoleta la declaración de Console. Cada cambio de SDK debería incluir Data safety como parte de la actualización obligatoria.

Data safety es la sección de Google Play donde declaras qué datos recopila o comparte la app y para qué se usan. App Privacy del lado de Apple sigue una lógica parecida, y cualquier desajuste con la implementación reduce la confianza.

La forma más segura de resolverlo es no rellenarlo de memoria, sino hacer inventario:

• Enumerar los SDK incluidos
• Confirmar qué tipo de datos maneja cada uno
• Listar también los datos que envían tus propias APIs
• Compararlo con lo declarado en Play Console / App Store Connect
• Si cambió algo, actualizar también la política de privacidad

Pedir permisos en el momento en que se usan

Un diseño que lanza varios diálogos de permisos nada más abrir la app suele dejar mala impresión tanto al usuario como al reviewer.

La mejor política es esta:

• Pedir el permiso cuando el usuario llega a la función
• Mostrar justo antes una explicación breve de pre-permission
• Preparar un camino alternativo para el caso de deny

Esto ayuda no solo frente a la revisión, sino también a mejorar la tasa de aceptación.

Qué escribir en las notas de revisión

El campo de notas de revisión suele infravalorarse, pero es un lugar importante para reducir la confusión del reviewer. Tiene mucho efecto en apps con login obligatorio, apps que usan permisos y apps que dependen de devices externos.

Contenido útil para incluir:

• Datos de la demo account
• Pasos para llegar a las funciones principales
• Explicación de qué pantalla usa cada permiso
• Aclaraciones si hace falta 2FA o un rol concreto
• Aclaraciones si existe dependencia de servidor o device externo

Ejemplo de plantilla breve:

Cuenta de revisión:
Email: reviewer-demo@example.com
Password: xxxxxxxx

Flujo principal de prueba:
1. Iniciar sesión con la cuenta de revisión
2. Abrir la pestaña Map para probar el permiso de ubicación
3. Abrir Settings > Subscription para verificar la guía de cancelación

Pauta de respuesta después de un rechazo

Tras un rechazo, lo importante no es responder con emoción, sino clasificar correctamente el problema señalado.

El orden básico de trabajo es este:

1. Releer el mensaje tal como fue escrito
2. Confirmar las condiciones de reproducción
3. Clasificarlo como defecto de implementación, explicación insuficiente o error de declaración
4. Añadir capturas o vídeo si hace falta

Incluso cuando la decisión parece equivocada, normalmente se resuelve antes completando la explicación. En la práctica, conviene tratar la apelación como último recurso.

En la respuesta real, suele ser más eficaz escribir de forma breve y clara qué ha cambiado que dar una defensa larga.

Gracias por la revisión.

Hemos identificado el problema como [implementation / metadata / clarification].
Hemos realizado los siguientes cambios:
1. Corregido [issue]
2. Actualizado [metadata or review notes]
3. Añadido [account / explanation / screenshot]

Cómo verificar:
1. Iniciar sesión con la cuenta de revisión
2. Abrir [screen name]
3. Tocar [action]

Si es necesario, podemos proporcionar capturas adicionales o una grabación de pantalla.

Si lo reduces a lo esencial, bastan tres puntos: causa, qué se cambió y cómo se verifica. Cuanto más se alarga el ciclo de revisión en un equipo, más tienden a mezclarse esos tres puntos y complicar la comunicación.

Qué hacer en las 48 horas previas al envío

Justo antes del release, la tentación de añadir una función más es fuerte. Pero si el objetivo es mejorar la tasa de aprobación, suele ser más eficaz dedicar la recta final a verificar que a implementar.

48 horas antes

• Revisar la descripción del store, las capturas, la clasificación por edades y Data safety / App Privacy
• Inventariar los SDKs en uso y la lista de permisos
• Preparar la cuenta del reviewer y las notas de revisión

24 horas antes

• Verificar el arranque en el último iPhone OS, una versión anterior de iOS y varios devices Android
• Probar modo avión, red lenta y estado tras instalación limpia
• Recorrer de punta a punta pagos, login, solicitud de permisos y baja de cuenta

6 horas antes

• Hacer una última comprobación de que las capturas siguen coincidiendo con la app real
• Confirmar que no hay diferencias entre las declaraciones del store y la configuración del SDK
• Completar las notas de revisión con el camino a las funciones principales y cualquier contexto necesario

Solo con repetir este flujo de 48 horas en cada release ya suele ser mucho más fácil reducir el porcentaje de rechazo.

Operación para evitar que se repita

Incluso después de haber pasado una revisión, los mismos problemas tienden a reaparecer cuando se añaden funciones o cambian los SDKs. Tanto en desarrollo individual como en equipo, estas prácticas reducen el riesgo:

• Si añades un SDK, actualiza permissions, Data safety y App Privacy como un mismo paquete
• Limita la descripción del store a funciones realmente implementadas
• Cuando agregues un permiso nuevo, revisa en el PR la pantalla donde se usa y el texto que lo explica
• Convierte la checklist previa al release en issue o plantilla reutilizable
• Registra internamente el texto del rechazo y cómo se respondió para reutilizarlo en futuras notas de revisión

La mayor ganancia a largo plazo consiste en no tratar la respuesta a revisión como algo que haya que reinventar cada vez.

Checklist antes del envío

Es más fácil detectar huecos si separas la checklist en formas que puedan usarse tal cual para cada store. Incluso los puntos comunes aparecen incluidos en cada tabla.

Checklist antes del envío a App Store

Checklist antes del envío a Google Play

Resumen

Lo que más suele bloquear la revisión de una app no son los bugs simples, sino los desajustes entre implementación y explicación y las carencias de preparación operativa.

Los cuatro puntos más importantes son estos:

• El reviewer puede verificar las funciones principales sin confundirse
• Las razones de los permisos y de la recogida de datos están explicadas de forma concreta
• Las reglas de cobro y las declaraciones del store están correctamente alineadas
• Los metadatos del store coinciden con la implementación real

Cuanto más se acerca el release, más fuerte es la tentación de añadir una función más. Pero si tu objetivo es mejorar la tasa de aprobación, suele ser más eficaz dedicar el último día a agotar la checklist.

Enlaces de referencia

• App Store Review Guidelines
• Auto-renewable subscriptions
• Google Play Policy Center
• Human Interface Guidelines
• In-App Purchase (Human Interface Guidelines)
• Distributing reader apps with a link to your website
• App testing requirements for new personal developer accounts
• Device verification requirements for new developer accounts
• Target API level requirements for Google Play apps
• App Tracking Transparency