
Los motivos más comunes y cómo resolverlos rápido.
+300
Proyectos entregados
15+
Años de experiencia
100%
Equipo senior
Apple rechaza entre el 15% y el 20% de las apps en primera revisión. Google Play tiene una tasa menor pero también rechaza apps — y en ambas stores los rechazos pueden volver en actualizaciones. Los motivos más frecuentes son: privacidad y permisos (el más común en iOS desde iOS 14.5), funcionalidad incompleta o con crashes, contenido que viola las políticas de la store, y problemas de metadatos o capturas de pantalla engañosas. El rechazo que más duele es el que llega justo antes del lanzamiento.
Resolver un rechazo requiere entender exactamente qué pide el reviewer — algo que no siempre es obvio en los mensajes automatizados de las stores. Dribba ha resuelto rechazos de App Store y Google Play para decenas de apps: desde implementación incorrecta de App Tracking Transparency hasta rechazos por flujos de pago no conformes con las políticas de compras in-app. Si tu app fue rechazada, cuéntanos el motivo — probablemente ya hemos resuelto el mismo antes.
Guía completa
El rechazo de una app en App Store o Google Play es una de las situaciones más estresantes del desarrollo mobile, especialmente cuando llega justo antes de una fecha de lanzamiento comprometida con marketing, inversores o clientes corporativos. Los datos agregados del sector son elocuentes: Apple rechaza entre el 15% y el 20% de las primeras subidas a revisión; Google Play tiene una tasa de rechazo menor pero con picos importantes cuando aparecen nuevas políticas (privacidad, permisos, pagos); y ambas tiendas pueden rechazar una actualización aunque la versión anterior estuviera aprobada, porque las políticas evolucionan y lo que era válido hace dieciocho meses puede no serlo hoy. La buena noticia es que la mayoría de rechazos son por causas identificables y resolubles en días, no semanas —si se sabe exactamente qué buscar y qué responder al reviewer.
Las causas más frecuentes de rechazo en App Store son, por orden de incidencia: privacidad y permisos (Apple desde iOS 14.5 ha endurecido tremendamente el control sobre datos del usuario, permisos de cámara, ubicación, contactos, tracking con ATT, y el etiquetado de Privacy Nutrition Labels debe ser preciso —inexactitudes son motivo de rechazo inmediato); metadatos engañosos (screenshots que no reflejan la app real, descripción que promete funcionalidades que no existen, iconos o branding que imitan a otras apps); flujos de compra no conformes (usar pasarelas externas para contenido digital en lugar de In-App Purchase, suscripciones sin la información requerida, botón para gestionar suscripción no accesible); funcionalidad incompleta o crashes durante la revisión (apps que se caen, pantallas vacías, funcionalidades que dependen de backend que no responde); contenido inapropiado o no licenciado (música, personajes, marcas sin permisos); y uso inadecuado de APIs (especialmente Camera, HealthKit, Contacts). En Google Play los rechazos más habituales son por privacidad, permisos declarados mal, target SDK no actualizado y contenido que infringe políticas.
El proceso correcto para resolver un rechazo rápido combina análisis técnico y comunicación precisa con el reviewer: primero, interpretar el mensaje de rechazo localizando las «guideline references» específicas (Apple cita números de guideline como 4.0 Design, 5.1.1 Privacy, 3.1.1 In-App Purchase) —la clave está en entender exactamente qué guideline se viola; segundo, auditar la funcionalidad descrita revisando código, flujos UX y configuración para identificar el punto concreto que falla; tercero, resolver técnicamente (a veces es un cambio de código, a veces un ajuste de metadatos, a veces una mejora del flujo de permisos, a veces una clarificación en la descripción); cuarto, preparar respuesta al reviewer explicando el cambio realizado y la justificación de por qué ahora sí cumple la política citada —Apple permite responder antes del resubmit para resolver ambigüedades; quinto, resubmit con nueva build y esperar segundo review que, si se hizo bien el trabajo, suele aprobarse en 24-48 horas.
Los errores típicos que alargan el proceso son: entrar en pánico y hacer cambios masivos sin identificar la causa raíz (genera nuevos rechazos en cascada); discutir con el reviewer sin argumentos técnicos concretos (los reviewers no responden a opiniones, responden a evidencia); subestimar la importancia de los metadatos (descripción, screenshots, privacy labels son motivo frecuente de rechazo cuando se editan sin rigor); y no actualizar target SDK o librerías que contenían vulnerabilidades conocidas (Google Play fuerza target SDK anualmente). Dribba ha resuelto rechazos en App Store y Google Play para decenas de apps: App Tracking Transparency mal implementada, flujos de IAP no conformes, apps con funcionalidad parcialmente dependiente de regiones no aprobadas, integración de contenido de terceros sin licencia, y una variedad de casos que el equipo ya ha visto. Si tu app acaba de ser rechazada y necesitas resolverlo rápido, una primera llamada de 30 minutos normalmente identifica la causa real y propone ruta más corta para resolverlo. Los presupuestos para resolución de rechazo típica se sitúan entre 1.500€ y 8.000€ según complejidad; casos especialmente complejos con reescritura de flujos completos pueden llegar a 15.000-25.000€.
Servicios relacionados
Preguntas frecuentes
Los 5 motivos más frecuentes son: (1) privacidad y permisos — App Tracking Transparency mal implementado o permisos sin justificación clara en el contexto de uso; (2) pagos — uso de sistemas de pago externos sin cumplir las políticas de Apple o flujos que evitan las compras in-app; (3) contenido — material que viola las community guidelines; (4) funcionalidad incompleta — la app tiene crashes o funciones que no funcionan en la revisión; (5) metadatos — capturas de pantalla o descripción engañosas respecto a la funcionalidad real.
Depende del motivo. Problemas de metadatos se resuelven en 1–3 días. Problemas de implementación técnica (privacidad, pagos, permisos) requieren 1–2 semanas de desarrollo más el tiempo de re-review de Apple — normalmente 24–48 horas, aunque puede llegar a 1 semana en periodos de alta demanda.
Sí. Apple y Google Play revisan cada actualización y pueden rechazar funcionalidades que no cumplan las políticas vigentes, incluso si la versión anterior fue aprobada. Las políticas evolucionan — en especial las de privacidad, pagos y contenido generado por IA — y lo que era válido hace 18 meses puede no serlo hoy. Una auditoría técnica antes de cada actualización significativa evita sorpresas.
Es frecuente. Los mensajes de rechazo de Apple son a menudo genéricos y no especifican exactamente qué código o flujo viola la política. El proceso correcto es: (1) revisar el mensaje buscando las guideline references específicas; (2) auditar la funcionalidad descrita; (3) preparar una respuesta al reviewer con el cambio realizado y la justificación. Si hay ambigüedad, Apple permite enviar respuestas antes de resubmit. Dribba gestiona este proceso de principio a fin.
¿Tienes un proyecto?
Sin compromiso, sin letra pequeña. Una valoración honesta de tu idea con el equipo que lo ejecutará.