Sobre los textos de rechazo de esta guía. Ninguno está inventado. Los marcados 📋 Literal son texto que desarrolladores han pegado verbatim en los foros oficiales de Apple o en la comunidad de Google Play, o el texto exacto de un error ITMS-* de App Store Connect. Los marcados 📖 De la política son el texto de la guideline o de la política que la tienda cita en la cabecera del rechazo. Cuando no hay literal público localizable, la entrada lo dice en vez de inventarse una frase plausible.

El literal varía según el caso, y Apple y Google ajustan sus plantillas y sus fechas sin avisar. Esto sirve para reconocer el rechazo y saber por dónde atacarlo — no como cita jurídica. Las fechas límite vigentes están siempre en App Store Connect y en Play Console. Fuentes primarias al final.


Índice de las 100

Una sola serie de 1 a 100. 🔴 son las frecuentes, ⚪ la cola larga. Cada línea enlaza a su entrada.

App Store

  1. Guideline 1.1.6 — funciones falsas o de broma
  2. 🔴 Guideline 1.2 — Safety: User-Generated Content
  3. Guideline 1.4.1 — apps médicas
  4. Guideline 1.5 — no hay forma de contactar
  5. 🔴 Guideline 2.1 — Performance: App Completeness · crash en el arranque
  6. 🔴 Guideline 2.1 · el revisor no pasa del login
  7. 🔴 Guideline 2.1 · el backend estaba apagado
  8. 🔴 Guideline 2.1 · pantalla en blanco — y por qué casi siempre es la configuración de Firebase
  9. 🔴 Guideline 2.2 — Beta Testing · la app es una demo
  10. 🔴 Guideline 2.3.1 — Accurate Metadata · notas de review genéricas
  11. Guideline 2.3.2 — compras integradas no anunciadas
  12. 🔴 Guideline 2.3.3 — Accurate Metadata · capturas
  13. Guideline 2.3.6 — clasificación por edad mal respondida
  14. 🔴 Guideline 2.3.7 — Accurate Metadata · nombre y keywords
  15. 🔴 Guideline 2.3.8 — Accurate Metadata · metadatos no aptos para 4+
  16. Guideline 2.3.9 — derechos de las capturas y datos de personas reales
  17. 🔴 Guideline 2.3.10 — Accurate Metadata · otras plataformas
  18. Guideline 2.3.12 — «What's New» genérico
  19. Guideline 2.4.1 — la app de iPhone no corre en iPad
  20. Guideline 2.4.2 — consumo y daño al dispositivo
  21. 🔴 Guideline 2.5.1 — Software Requirements · APIs privadas y frameworks mal usados
  22. Guideline 2.5.2 — descargar código ejecutable
  23. 🔴 Guideline 2.5.4 — Software Requirements · background modes declarados y sin usar
  24. Guideline 2.5.13 — reconocimiento facial para autenticar
  25. Guideline 2.5.18 — soporte de Matter
  26. 🔴 Guideline 3.1.1 — In-App Purchase · códigos, claves, QR
  27. 🔴 Guideline 3.1.1 · monedas virtuales que caducan
  28. 🔴 Guideline 3.1.2(c) — Subscriptions · falta información en el flujo de compra
  29. Guideline 3.1.3(b) — servicios multiplataforma
  30. Guideline 3.1.5(i) — wallets solo para organizaciones
  31. Guideline 3.1.5(ii) — minería en el dispositivo
  32. Guideline 3.1.5(v) — cripto por completar tareas
  33. Guideline 3.2.2(i) — interfaz tipo App Store
  34. Guideline 3.2.2(iii) — inflar impresiones o vivir de los ads
  35. Guideline 3.2.2(iv) — recaudar para causas
  36. Guideline 3.2.2(v) — restringir arbitrariamente quién usa la app
  37. Guideline 3.2.2(vii) — manipular visibilidad en otros servicios
  38. Guideline 3.2.2(viii) — opciones binarias y derivados
  39. Guideline 3.2.2(ix) — préstamos personales
  40. Guideline 3.2.2(x) — forzar a valorar o descargar
  41. 🔴 Guideline 4.0 — Design · el cajón de sastre
  42. 🔴 Guideline 4.1 — Design: Copycats
  43. 🔴 Guideline 4.2 — Design: Minimum Functionality
  44. 🔴 Guideline 4.3(a) — Design: Spam · múltiples Bundle IDs
  45. 🔴 Guideline 4.3(b) — Design: Spam · misma feature set
  46. 🔴 Guideline 4.5.4 — Push Notifications para marketing
  47. Guideline 4.7 — mini apps, chatbots, plug-ins y emuladores
  48. 🔴 Guideline 4.8 — Design: Login Services
  49. 🔴 Guideline 5.1.1 — Privacy · purpose string insuficiente
  50. 🔴 Guideline 5.1.1 — Privacy · política de privacidad
  51. 🔴 Guideline 5.1.1(v) — Privacy · borrado de cuenta
  52. 🔴 Guideline 5.1.2 — Privacy · compartir datos con terceros
  53. 🔴 Guideline 5.1.2(i) — App Tracking Transparency
  54. Guideline 5.1.3(ii) — datos de salud en iCloud
  55. Guideline 5.1.3(iii)(iv) — investigación con sujetos humanos
  56. 🔴 Guideline 5.1.4 — Kids Category · analítica y publicidad de terceros
  57. Guideline 5.1.5 — Location Services
  58. 🔴 Guideline 5.2.1 — Legal · propiedad intelectual de terceros
  59. Guideline 5.2.2 — servicios de terceros sin permiso
  60. Guideline 5.2.3 — descargar audio o vídeo de terceros
  61. 🔴 Guidelines 5.3.1 y 5.3.2 — Sorteos, concursos y rifas
  62. Guideline 5.4 — VPN
  63. ITMS-90062 · versión no incrementada
  64. 🔴 ITMS-90683 · falta el purpose string en el Info.plist
  65. ITMS-90717 · icono con canal alfa
  66. ITMS-90809 · UIWebView
  67. 🔴 ITMS-91053 · falta la declaración de API en el privacy manifest
  68. ITMS-91061 · privacy manifest de una SDK de terceros
  69. 🔴 Missing Compliance · ITSAppUsesNonExemptEncryption

Google Play

  1. 🔴 Broken Functionality
  2. 🔴 Invalid Data Safety Form
  3. 🔴 ACCESS_BACKGROUND_LOCATION
  4. 🔴 QUERY_ALL_PACKAGES
  5. 🔴 Permisos de SMS y registro de llamadas
  6. 🔴 MANAGE_EXTERNAL_STORAGE · acceso a todos los archivos
  7. 🔴 Tipos de foreground service (Android 14)
  8. 🔴 Inadequate Prominent Disclosure
  9. 🔴 Metadata policy
  10. 🔴 Repetitive Content
  11. 🔴 Deceptive Behavior
  12. 🔴 Sorteos y promociones · Real-Money Gambling, Games, and Contests
  13. 🔴 Account deletion · in-app y enlace web
  14. 🔴 Target API level
  15. 🔴 Propiedad intelectual
  16. 🔴 Contenido de la ficha, no de la app
  17. ⚡ Accessibility API · el cambio que afecta a los agentes de IA
  18. ⚡ SMS y llamadas · se acabó verificar cuentas por llamada
  19. ⚡ Contacts Permissions · usar el selector de contactos de Android
  20. Photo and Video Permissions
  21. Impersonation
  22. Payments · saltarse Google Play Billing
  23. Subscriptions · transparencia y cancelación
  24. Ads · anuncios disruptivos
  25. Families / Designed for Families
  26. Content Ratings · app sin clasificar
  27. Financial Services · préstamos personales
  28. Health content
  29. Unapproved Substances
  30. Device and Network Abuse
  31. Child Endangerment · retirada inmediata

Antes de la lista: en qué escalón estás

En Google Play los cuatro estados no son lo mismo, y la diferencia importa:

EstadoQué pasaEfecto en la cuenta
RechazoLa app o la actualización no se publica. La versión anterior sigue disponible.Ninguno
RetiradaLa app y todas sus versiones anteriores desaparecen de Google Play.Ninguno inmediato; varias retiradas llevan a suspensión
SuspensiónPor violaciones graves o repetidas — incluidos rechazos repetidos.Cuenta como strike
TerminaciónCierre de la cuenta y de las cuentas relacionadas.Permanente

Google no publica un número de strikes: los criterios son cualitativos («graves», «repetidas», «múltiples»). Malware, fraude y apps que puedan dañar al usuario o al dispositivo van directas a terminación.

En Apple no hay escala pública equivalente, pero las guidelines avisan de que los envíos repetidos de apps spam «pueden llevar a la expulsión del Apple Developer Program».


App Store — 69

Ordenados por número de guideline. Al final, los errores de subida ITMS-* y el de compliance, que bloquean el build antes de llegar a revisión.

1 · Guideline 1.1.6 — funciones falsas o de broma

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

False information and features, including inaccurate device data or trick/joke functionality, such as fake location trackers. Stating that the app is "for entertainment purposes" won't overcome this guideline.

Por qué llega. Detectores de mentiras, medidores de radiación, «escáneres» de nada, localizadores falsos. La última frase es la clave: el descargo de «solo entretenimiento» no salva la app.

Cómo se arregla. O el dato es real y medible con el hardware del dispositivo, o la función no va.


2 · Guideline 1.2 — Safety: User-Generated Content

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Apps with user-generated content or social networking services must include:

  • A method for filtering objectionable material from being posted to the app
  • A mechanism to report offensive content and timely responses to concerns
  • The ability to block abusive users from the service
  • Published contact information so users can easily reach you

Por qué llega. Basta con que haya un campo de texto libre que otro usuario pueda ver: comentarios, chat, nombre de perfil, una descripción. No hace falta ser una red social. Los cuatro requisitos se piden todos, y el que más se olvida es el tercero: bloquear usuarios.

Cómo se arregla. Los cuatro, y visibles para el revisor: filtro de contenido (aunque sea una lista de términos más moderación posterior), botón de reportar en cada pieza de contenido, bloquear usuario desde el perfil y desde el contenido, y contacto publicado. En las Notes for Review, la ruta exacta para llegar a cada uno — si el revisor no los encuentra, no existen.


3 · Guideline 1.4.1 — apps médicas

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Medical apps that could provide inaccurate data or information, or that could be used for diagnosing or treating patients may be reviewed with greater scrutiny.

Por qué llega. Revisión con más escrutinio no significa prohibición, significa que hay que documentar. Cualquier claim de precisión sobre una medición de salud necesita metodología que se pueda validar.

Cómo se arregla. Declarar la metodología y las fuentes de los datos, y ser explícito sobre qué no hace la app. En las Notes for Review, adjuntar la validación clínica o la del fabricante del sensor si el dato viene de hardware. Y si es producto sanitario, el marcado CE y el MDR van antes que la App Store.


4 · Guideline 1.5 — no hay forma de contactar

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

People need to know how to reach you with questions and support issues. Make sure your app and its Support URL include an easy way to contact you; this is particularly important for apps that may be used in the classroom.

Por qué llega. Support URL que apunta a la home del cliente, o a una página sin ningún medio de contacto. Es de los rechazos más tontos y más frecuentes en apps de marca.

Cómo se arregla. Una URL con email o formulario visible, y contacto también dentro de la app.


5 · Guideline 2.1 — Performance: App Completeness · crash en el arranque

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 2.1 - Performance - App Completeness We were unable to review your app as it crashed on launch.

Por qué llega. Probado en simulador, no en dispositivo. O una dependencia que solo existe en tu máquina.

Cómo se arregla. Ejecutar el build exacto que subiste en un dispositivo físico limpio, sin Xcode conectado. Si no reproduces el crash, pide el crash log en el Resolution Center: el revisor lo adjunta.


6 · Guideline 2.1 · el revisor no pasa del login

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Include detailed explanations of non-obvious features and in-app purchases in the App Review notes, including supporting documentation where appropriate. If your app requires a login, provide a demo account.

Por qué llega. Cuenta demo vacía, caducada, o con datos insuficientes para recorrer la app. Un caso documentado en los foros de Apple: la API bloqueaba por geo el tráfico fuera de la UE por cumplimiento de GDPR, y el revisor probando desde EE. UU. veía la app rota.

Cómo se arregla. Cuenta demo con datos suficientes para ver todas las funciones, sin caducidad, y con el backend accesible durante toda la revisión. Si tienes geobloqueo o rate limiting, mete las IPs de App Review en la lista blanca o desactívalo para la cuenta demo, y dilo en las notas.


7 · Guideline 2.1 · el backend estaba apagado

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info if your app includes a login. […] make sure your backend services are live and accessible during review.

Por qué llega. El staging que se apaga por la noche o el fin de semana. La revisión no ocurre cuando enviaste.

Cómo se arregla. Apuntar el build de revisión a un entorno que esté vivo 24/7 durante toda la ventana de revisión. Y no desplegar cambios rompientes en el backend mientras hay un envío en cola.


8 · Guideline 2.1 · pantalla en blanco — y por qué casi siempre es la configuración de Firebase

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política — llega bajo el mismo 2.1 que el crash:

Guideline 2.1 - Performance - App Completeness

Sin literal público. No he localizado una plantilla verbatim para esta variante: el revisor describe el síntoma que ve en el cuerpo del mensaje —pantalla en blanco, la app no carga contenido, se queda en el loader— y ese texto cambia de un caso a otro. Los desarrolladores reportan la pantalla en blanco como bug encontrado en revisión bajo 2.1, pero no hay una frase fija que citar. Si tienes el mensaje de un rechazo propio, ese es el que debe ir aquí.

Por qué llega. Este es distinto del crash: la app no cae, se queda en blanco para siempre. Y por eso no aparece en Crashlytics ni en los logs, lo que hace que el equipo no lo reproduzca y responda «a nosotros nos funciona». En Flutter la causa es casi siempre la misma cadena:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);
  runApp(const MyApp());   // ← nunca se llega aquí si el await de arriba falla
}

Si Firebase.initializeApp() lanza o no resuelve, runApp() no se ejecuta nunca. No hay árbol de widgets, no hay pantalla: blanco. Las razones por las que falla en el build de release y no en tu máquina:

  • GoogleService-Info.plist no está añadido al target Runner desde Xcode. Copiarlo a la carpeta con el Finder no lo enlaza al proyecto: hay que añadirlo con Add files sobre Runner y con Copy items if needed marcado. En local puede funcionar por caché de build; en el archive limpio, no.
  • Los ficheros de configuración están gitignoreados y el CI no los restaura. Es la práctica recomendada —ios/Runner/GoogleService-Info.plist, google-services.json y los de cada flavor van fuera del repo— pero exige un paso previo en el pipeline que los reponga desde los secretos. Si ese paso no existe, o se añadió un flavor nuevo y nadie tocó el pipeline, el build sale sin config.
  • firebase.json apunta al proyecto o al flavor equivocado. Lo genera flutterfire configure y es el que mapea cada flavor y plataforma con su app de Firebase. Si está desactualizado —o si también está gitignoreado y en CI se regenera mal— el build compila y firma perfectamente contra el Firebase de staging, o contra ninguno. Compila. Sube. Pantalla en blanco.
  • Bundle ID que no coincide con el registrado en la app de Firebase.

Cómo se arregla. El fix de fondo es no dejar que un fallo de inicialización se coma la primera pantalla:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  try {
    await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);
  } catch (e, s) {
    // Arranca igual y enseña algo. Un error visible se depura; el blanco, no.
    runApp(StartupErrorApp(error: e, stack: s));
    return;
  }
  runApp(const MyApp());
}

Y en el proceso:

  • Probar el .ipa que se sube, instalado desde TestFlight en un dispositivo limpio, no el build de flutter run
  • Verificar que GoogleService-Info.plist aparece en Build Phases → Copy Bundle Resources del target de release
  • Comprobar que firebase.json mapea el flavor de producción a la app de Firebase de producción
  • Que el paso de CI que restaura los ficheros de config falle ruidosamente si no encuentra el secreto, en vez de continuar
  • Un test de arranque en el pipeline que abra la app y compruebe que se pinta algo

9 · Guideline 2.2 — Beta Testing · la app es una demo

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Demos, betas, and trial versions of your app don't belong on the App Store – use TestFlight instead.

Por qué llega. Textos de «versión beta», «próximamente» o «demo» en la UI o en la ficha. También pantallas con datos de prueba visibles, o funciones que avisan de que aún no están listas. Y una variante que sorprende: apps que se distribuyen a testers a cambio de compensación, incluida la recompensa de una campaña de crowdfunding, no pueden ir por TestFlight.

Cómo se arregla. Quitar cualquier mención a beta, demo, trial o coming soon de la app y de la ficha. Si de verdad es una beta, va a TestFlight. Un detalle de proceso: las actualizaciones significativas del build de beta también pasan por TestFlight App Review antes de llegar a los testers, así que no vale contar con que TestFlight sea instantáneo.


10 · Guideline 2.3.1 — Accurate Metadata · notas de review genéricas

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review. All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.

Por qué llega. «Bug fixes and improvements» en una release que añade una pantalla nueva. Apple lo dice literalmente: las descripciones genéricas se rechazan.

Cómo se arregla. Una línea por función nueva, con la ruta para llegar a ella dentro de la app. Si una función está detrás de un feature flag, dilo y da la forma de activarla.


11 · Guideline 2.3.2 — compras integradas no anunciadas

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases.

Por qué llega. Capturas que muestran contenido premium sin indicar que es de pago.

Cómo se arregla. Marcar en la propia captura o en la descripción qué requiere compra.


12 · Guideline 2.3.3 — Accurate Metadata · capturas

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 2.3.3 - Performance - Accurate Metadata We noticed that your screenshots do not sufficiently reflect your app in use.

Por qué llega. Capturas del splash, del login o del título. También: capturas de iPhone tomadas en iPad, o en el marco de dispositivo equivocado.

Cómo se arregla. Capturas de la app funcionando, en el dispositivo correcto para cada tamaño declarado. En juegos, gameplay real.


13 · Guideline 2.3.6 — clasificación por edad mal respondida

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Answer the age rating questions in App Store Connect honestly so that your app aligns properly with parental controls.

Por qué llega. Se responde el cuestionario por inercia. Contenido generado por usuarios, chat sin moderar o acceso web abierto suben la clasificación, y decir 4+ con cualquiera de los tres es una discrepancia que el revisor ve.

Cómo se arregla. Rehacer el cuestionario con el comportamiento real de la app. Apple avisa de que una clasificación errónea puede acabar en una consulta de un regulador, no solo en un rechazo.


14 · Guideline 2.3.7 — Accurate Metadata · nombre y keywords

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Choose a unique app name, assign keywords that accurately describe your app, and don't try to pack any of your metadata with trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system. App names must be limited to 30 characters.

Por qué llega. El clásico «MiApp - Gestión, Facturas, CRM, Contabilidad y Clientes». Pasa de 30 caracteres y además es keyword stuffing.

Cómo se arregla. Nombre de 30 caracteres o menos. El subtítulo es de 30 más y ahí sí cabe posicionamiento. Las keywords, en su campo, sin marcas ajenas.


15 · Guideline 2.3.8 — Accurate Metadata · metadatos no aptos para 4+

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Metadata should be appropriate for all audiences, so make sure your app and in-app purchase icons, screenshots, and previews adhere to a 4+ age rating even if your app is rated higher.

Por qué llega. La app puede ser 17+; la captura, no. Pilla a apps de citas, salud y juegos.

Cómo se arregla. Revisar iconos, capturas y previews —incluidos los de las compras integradas— con el criterio de 4+.


16 · Guideline 2.3.9 — derechos de las capturas y datos de personas reales

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

You are responsible for securing the rights to use all materials in your app icons, screenshots, and previews, and you should display fictional account information instead of data from a real person.

Por qué llega. Capturas con datos de un usuario real de staging: nombre, foto, email, un número de pedido. Muy frecuente cuando las capturas se hacen con la cuenta de un empleado.

Cómo se arregla. Datos ficticios en todas las capturas, y derechos documentados sobre las fotos e iconos.


17 · Guideline 2.3.10 — Accurate Metadata · otras plataformas

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Make sure your app is focused on the experience of the Apple platforms it supports, and don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality.

Por qué llega. El badge de Google Play en una captura, un «también en Android» en la descripción, un icono de Play Store en la pantalla de compartir.

Cómo se arregla. Quitarlo de la app y de todos los metadatos. Sin excepciones.


18 · Guideline 2.3.12 — «What's New» genérico

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps must clearly describe new features and product changes in their "What's New" text. Simple bug fixes, security updates, and performance improvements may rely on a generic description, but more significant changes must be listed in the notes.

Por qué llega. Es el hermano público del 2.3.1: aquí no son las notas para el revisor, es el texto que ve el usuario. Un «mejoras de rendimiento» en una release que añade una pantalla es rechazo.

Cómo se arregla. Genérico solo si de verdad son bugs y rendimiento. Cualquier cambio significativo, listado.


19 · Guideline 2.4.1 — la app de iPhone no corre en iPad

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

To ensure people get the most out of your app, iPhone apps should run on iPad whenever possible.

Por qué llega. El revisor prueba en iPad aunque declares solo iPhone, y si se ve roto lo reporta. En Flutter aparece como layouts que se estiran mal.

Cómo se arregla. O soporte de iPad decente, o al menos que la app en modo compatibilidad no se rompa. Y si de verdad es iPhone-only por una razón de hardware, decirlo en las notas.


20 · Guideline 2.4.2 — consumo y daño al dispositivo

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Design your app to use power efficiently and be used in a way that does not risk damage to the device.

Por qué llega. Localización en segundo plano permanente, polling agresivo, animaciones a pantalla completa sin pausar, cámara abierta sin necesidad. El revisor lo nota porque el dispositivo se calienta.

Cómo se arregla. Medir con el Energy Log de Xcode antes de enviar. Suele ser un timer que nadie cancela.


21 · Guideline 2.5.1 — Software Requirements · APIs privadas y frameworks mal usados

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Apps may only use public APIs and must run on the currently shipping OS. […] Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. For example, the HomeKit framework should provide home automation services; and HealthKit should be used for health and fitness purposes and integrate with the Health app.

Por qué llega. Dos cosas distintas. La primera: uso de API no pública — casi nunca es tuyo, es una dependencia. Se detecta en la subida, no en la revisión, así que llega en minutos con un código de error. La segunda, más traicionera: usar un framework para algo que no es su propósito. HealthKit para guardar datos que no son de salud, HomeKit para telemetría de dispositivos que no son de domótica.

Cómo se arregla. Para la API privada, localizar la dependencia que la referencia y actualizarla o sustituirla. Para el uso del framework: si HealthKit o HomeKit están en el proyecto, la descripción de la ficha tiene que mencionar esa integración, y el uso tiene que encajar con su propósito. Si no encaja, el framework no es el sitio: usa almacenamiento propio.


22 · Guideline 2.5.2 — descargar código ejecutable

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.

Por qué llega. Es el número que mata las actualizaciones OTA de lógica: bundles de JavaScript, código descargado que cambia comportamiento, motores de reglas que llegan del servidor. Configuración remota (feature flags que activan código ya presente en el binario) es otra cosa y sí se permite.

Cómo se arregla. La línea es: ¿el código estaba en el binario que revisó Apple? Si el servidor manda algo que añade o cambia funcionalidad, no pasa. Si solo enciende o apaga lo que ya estaba, sí.


23 · Guideline 2.5.4 — Software Requirements · background modes declarados y sin usar

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 2.5.4 - Performance - Software Requirements Your app declares support for location in the UIBackgroundModes key in your Info.plist file but does not have any features that require persistent location.

📖 De la política

Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.

Por qué llega. El caso típico: la app usa geofencing, beacons o registro de fichajes, y alguien activó el background mode de location pensando que era necesario. Para esos casos no lo es. Y en Flutter suele venir de un plugin de geolocalización que lo añade al Info.plist por su cuenta al integrarlo.

Cómo se arregla. Si no necesitas actualizaciones de ubicación persistentes y en tiempo real, quita location de UIBackgroundModes y usa el significant-change location service o el region monitoring service, que es lo que Apple propone en el propio rechazo y además gasta mucha menos batería. Revisa el Info.plist fusionado del build de release, no el del repo: los plugins añaden claves.


24 · Guideline 2.5.13 — reconocimiento facial para autenticar

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps using facial recognition for account authentication must use LocalAuthentication (and not ARKit or other facial recognition technology) where possible, and must use an alternate authentication method for users under 13 years old.

Por qué llega. Implementar biometría con ARKit o con una SDK de terceros en vez de con LocalAuthentication. Y el segundo requisito, que casi nadie ve: método alternativo para menores de 13.

Cómo se arregla. LocalAuthentication y un camino alternativo de login.


25 · Guideline 2.5.18 — soporte de Matter

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps that support Matter must use Apple's support framework for Matter to initiate pairing.

Por qué llega. Nicho, pero relevante si hacéis IoT: el emparejamiento Matter tiene que iniciarse con el framework de Apple, no con uno propio.


26 · Guideline 3.1.1 — In-App Purchase · códigos, claves, QR

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 3.1.1 - Business - Payments - In-App Purchase Your app unlocks or enables additional functionality with mechanisms such as promo codes, data transfer codes, license keys, augmented reality markers, or QR codes, which is not appropriate for the App Store.

Por qué llega. El flujo típico de SaaS: el usuario paga en la web y mete un código en la app. Para Apple eso es desbloquear contenido sin IAP.

Cómo se arregla. O el desbloqueo pasa por IAP, o la app es «reader» y no ofrece ningún camino a la compra dentro (y entonces tampoco puede enlazar a ella, salvo bajo las excepciones vigentes). Es una decisión de modelo de negocio, no un fix técnico: decidirla antes de construir.


27 · Guideline 3.1.1 · monedas virtuales que caducan

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.

Por qué llega. Créditos que caducan a los 12 meses, muy común en apps de suscripción con bolsa de consumo.

Cómo se arregla. Los comprados con IAP no caducan. Si necesitas caducidad, sepáralos de los comprados: los de regalo o promocionales sí pueden caducar.


28 · Guideline 3.1.2(c) — Subscriptions · falta información en el flujo de compra

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 3.1.2 - Business - Payments - Subscriptions The submission did not include all the required information for apps offering auto-renewable subscriptions.

📖 De la política · 3.1.2(c)

Before asking a customer to subscribe, you should clearly describe what the user will get for the price. How many issues per month? How much cloud storage? What kind of access to your service?

Por qué llega. Es el rechazo más mecánico de todos y el que más veces se repite, porque la lista es larga y basta con que falte un elemento. Lo que tiene que estar visible:

  • Título de la suscripción auto-renovable
  • Duración del periodo
  • Precio, y el precio de la renovación
  • Qué contenido o servicio se entrega en cada periodo
  • Información de renovación automática
  • Enlace funcional a los Términos de Uso (EULA)
  • Enlace funcional a la política de privacidad

Cómo se arregla. Todo eso dentro de la app, en el propio flujo de compra, «clara y visiblemente y sin requerir ninguna acción adicional del usuario, como abrir un enlace». Es decir: el texto no puede estar detrás de un «ver detalles». Los dos enlaces tienen que estar además en los metadatos de App Store Connect. Y funcionales: un 404 en el EULA es un rechazo por este mismo número.


29 · Guideline 3.1.3(b) — servicios multiplataforma

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app.

Por qué llega. Es la cara amable del 3.1.1 y la que resuelve el caso SaaS: el usuario puede consumir en la app lo que compró en la web. La condición es que eso mismo esté también disponible como IAP dentro.

Cómo se arregla. Si no quieres IAP, entonces la app no puede desbloquear nada comprado fuera. Si quieres ambas cosas, ofrece las dos vías.


30 · Guideline 3.1.5(i) — wallets solo para organizaciones

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps may facilitate virtual currency storage, provided they are offered by developers enrolled as an organization.

Por qué llega. Cuenta de desarrollador individual publicando un wallet. Rechazo automático.


31 · Guideline 3.1.5(ii) — minería en el dispositivo

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps may not mine for cryptocurrencies unless the processing is performed off device (e.g. cloud-based mining).


32 · Guideline 3.1.5(v) — cripto por completar tareas

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Cryptocurrency apps may not offer currency for completing tasks, such as downloading other apps, encouraging other users to download, posting to social networks, etc.

Por qué llega. Cualquier mecánica de airdrop por referidos entra aquí.


33 · Guideline 3.2.2(i) — interfaz tipo App Store

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection.

Por qué llega. Pantallas de «nuestras otras apps» montadas como catálogo, o directorios de apps de terceros.


34 · Guideline 3.2.2(iii) — inflar impresiones o vivir de los ads

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Artificially increasing the number of impressions or click-throughs of ads, as well as apps that are designed predominantly for the display of ads.

Por qué llega. Dos cosas: el fraude de clics, y la app cuyo propósito real es enseñar anuncios. La segunda pilla a apps de utilidad mínima monetizadas con intersticiales.


35 · Guideline 3.2.2(iv) — recaudar para causas

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1(vi) above, collecting funds within the app for charities and fundraisers.

Por qué llega. Botón de donación dentro de una app de marca. La vía correcta es enlazar fuera o cumplir los requisitos de nonprofit aprobado.


36 · Guideline 3.2.2(v) — restringir arbitrariamente quién usa la app

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Arbitrarily restricting who may use the app, such as by location or carrier.

Por qué llega. Y aquí sí toca a proyectos enterprise: apps internas de empleado publicadas en la App Store pública que exigen un email corporativo. Para el revisor, eso es restringir arbitrariamente.

Cómo se arregla. Una app de empleados no va a la App Store pública: va por Custom App Distribution (Apple Business Manager) o por el Apple Developer Enterprise Program. Es una decisión de distribución que hay que tomar al empezar el proyecto, no al enviar.


37 · Guideline 3.2.2(vii) — manipular visibilidad en otros servicios

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Artificially manipulating a user's visibility, status, or rank on other services unless permitted by that service's Terms and Conditions.

Por qué llega. Apps de crecimiento en redes sociales: seguidores, likes, automatización de publicaciones.


38 · Guideline 3.2.2(viii) — opciones binarias y derivados

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps that facilitate binary options trading are not permitted on the App Store. […] Apps that facilitate trading in contracts for difference ("CFDs") or other derivatives (e.g. FOREX) must be properly licensed in all jurisdictions where the service is available.

Por qué llega. Opciones binarias, prohibidas sin más. CFD y FOREX, permitidos pero con licencia en cada jurisdicción donde se distribuya. Eso obliga a limitar la disponibilidad por país a lo que cubre la licencia.


39 · Guideline 3.2.2(ix) — préstamos personales

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps offering personal loans must clearly and conspicuously disclose all loan terms, including but not limited to equivalent maximum Annual Percentage Rate (APR) and payment due date. Loan apps may not charge a maximum APR higher than 36%, including costs and fees, and may not require repayment in full in 60 days or less.

Por qué llega. Dos límites duros: 36 % de TAE máxima incluyendo costes y comisiones, y nada de reembolso íntegro en 60 días o menos. Los productos de payday quedan fuera por diseño. Google Play tiene el mismo umbral del 36 % en EE. UU. — ver la entrada 96.


40 · Guideline 3.2.2(x) — forzar a valorar o descargar

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps must not force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality, content, or use of the app.

Por qué llega. Muros de «valora para continuar» o «invita a un amigo para desbloquear».

Cómo se arregla. Recompensar a quien envía la invitación se permite; a quien la recibe por descargar o registrarse, no — eso influye directamente en las reseñas y en el ranking.


41 · Guideline 4.0 — Design · el cajón de sastre

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store. […] Apps that stop working or offer a degraded experience may be removed from the App Store at any time.

Por qué llega. Es el número que usa el revisor cuando algo no funciona bien pero no encaja en ningún otro: controles que se salen de la pantalla, texto cortado, la app no gira cuando dice soportar landscape, botones que no responden, el teclado tapando el campo activo. En Flutter aparece mucho con el safe area de los dispositivos con notch y con Dynamic Type.

Cómo se arregla. Probar en el dispositivo más pequeño y en el más grande que soportas, con el texto al tamaño máximo de accesibilidad y en las dos orientaciones si declaras las dos. El literal suele traer una captura del revisor: es la pista más útil y hay que pedirla si no viene.

Ojo a la segunda frase de la política: una app que deja de funcionar puede retirarse en cualquier momento, no solo en revisión. Una API que se apaga o un backend que se abandona son motivo de retirada.


42 · Guideline 4.1 — Design: Copycats

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 4.1 - Design - Copycats This app or its metadata appears to be attempting to misrepresent itself as another popular app or game already available on the App Store or a third-party platform. Apps submitted to the App Store should be unique and should not attempt to deceive users into thinking they are downloading something they are not.

Por qué llega. A veces es un falso positivo: tu propia versión Android o una app anterior tuya bajo otra cuenta. El texto de Apple menciona explícitamente «a third-party platform».

Cómo se arregla. Si es tuyo, documentarlo: certificado de marca, capturas de la ficha de Play con el mismo nombre de desarrollador, o cesión de derechos. En el Resolution Center, con adjuntos.


43 · Guideline 4.2 — Design: Minimum Functionality

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store. […] Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are primarily marketing materials or advertisements will be rejected.

Por qué llega. WebView de la web corporativa. También agregadores de contenido sin funcionalidad nativa: «apps that only include links, images, or content aggregated from the Internet» no se diferencian de navegar en el móvil.

Cómo se arregla. Funcionalidad nativa real: notificaciones con valor, funcionamiento offline, cámara, Face ID, widgets, atajos. Y en el Resolution Center, nombrar qué capacidades de iOS usa la app y para quién.


44 · Guideline 4.3(a) — Design: Spam · múltiples Bundle IDs

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Don't create multiple Bundle IDs of the same app (for example, submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city).

Por qué llega. La estrategia de una app por ciudad, por cliente o por idioma.

Cómo se arregla. Una app con selector. Si de verdad necesitas builds separados por cliente (white label), el camino es el Apple Developer Enterprise Program o el Custom App Distribution, no la App Store pública.


45 · Guideline 4.3(b) — Design: Spam · misma feature set

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 4.3 - Design - Spam Upon further review, we noticed that your app provides the same feature set as other apps submitted to the App Store; it simply varies in content or language, which is considered a form of spam.

Por qué llega. Apple nombra las categorías que mira con lupa: citas, linternas, efectos de sonido, fondos de pantalla, temporizadores simples y adivinación.

Cómo se arregla. Es el rechazo más difícil de revertir porque es de criterio. Lo que funciona es demostrar diferenciación funcional real, no de contenido: un dato propio, una integración que nadie tiene, un flujo distinto. Si el único diferencial es el idioma o el catálogo, no hay respuesta que lo salve.


46 · Guideline 4.5.4 — Push Notifications para marketing

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app's UI, and you provide a method in your app for a user to opt out from receiving such messages.

Por qué llega. Tres cosas distintas en un solo número: la app no puede depender de las push para funcionar, no pueden llevar datos sensibles, y para promociones hace falta opt-in explícito con texto de consentimiento en la UI de la app más una forma de salirse dentro de la app.

Cómo se arregla. El permiso de notificaciones de iOS no es el opt-in de marketing: son dos consentimientos separados. Hace falta un toggle propio para comunicaciones comerciales, con su texto, y visible en Ajustes de la app. Si el onboarding pide push «para no perderte nada», eso es marketing y necesita el segundo consentimiento.


47 · Guideline 4.7 — mini apps, chatbots, plug-ins y emuladores

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps may offer certain software that is not embedded in the binary, specifically HTML5 and JavaScript mini apps and mini games, streaming games, chatbots, and plug-ins. […] You are responsible for all such software offered in your app, including ensuring that such software complies with these Guidelines and all applicable laws.

Por qué llega. Es la excepción al 2.5.2, con una contrapartida grande: respondes de todo lo que se sirve dentro. Si tu app aloja mini apps de terceros o un chatbot que genera contenido, el contenido es tuyo a efectos de revisión.

Cómo se arregla. Moderación y control sobre lo que se puede servir, y demostrable ante el revisor.


48 · Guideline 4.8 — Design: Login Services

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 4.8 - Design - Login Services The app uses a third-party login service, but does not appear to offer an equivalent login option with the following features:

  • The login option limits data collection to the user's name and email address.
  • The login option allows users to keep their email address private as part of setting up their account.
  • The login option does not collect interactions with the app for advertising purposes without consent.

Next Steps: Revise the app to offer an equivalent login option that meets all of the above requirements.

Por qué llega. Login con Google o Facebook sin una alternativa equivalente.

Cómo se arregla. Sign in with Apple cumple los tres requisitos, pero no es obligatorio: cualquier opción que los cumpla vale — por ejemplo email + contraseña propio que no comparta datos con terceros. Lo más rápido suele ser Sign in with Apple.


49 · Guideline 5.1.1 — Privacy · purpose string insuficiente

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage We noticed that your app requests the user's consent to access their camera, microphone, and location but does not clarify the use of this feature in the permission modal alert.

Por qué llega. «Esta app necesita acceso a la cámara.» No dice para qué.

Cómo se arregla. El purpose string tiene que describir el uso y dar un ejemplo. El propio ejemplo de Apple: "Our app uses the camera to capture photos for updating and sharing on your gardener profile." Cuidado con dos cosas: NSCameraUsageDescription no cubre el micrófono, y NSLocationWhenInUseUsageDescription no cubre la ubicación en segundo plano.


50 · Guideline 5.1.1 — Privacy · política de privacidad

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner. The privacy policy must clearly and explicitly: identify what data, if any, the app/service collects, how it collects that data, and all uses of that data […] explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user's data.

Por qué llega. El enlace está en App Store Connect pero no dentro de la app. O la política no dice cómo revocar el consentimiento ni pedir el borrado.

Cómo se arregla. Enlace accesible dentro de la app (típicamente en Ajustes), y que el texto cubra los tres puntos: qué datos, para qué, y cómo se revoca o se borra.


51 · Guideline 5.1.1(v) — Privacy · borrado de cuenta

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Guideline 5.1.1(v) - Data Collection and Storage The app supports account creation but does not include an option to initiate account deletion. Apps that support account creation must also offer account deletion to give users more control of the data they've shared while using an app.

Por qué llega. El que más veces pilla a un equipo con la release lista. No vale un email a soporte ni un formulario en la web: tiene que iniciarse dentro de la app.

Cómo se arregla. Flujo de borrado dentro de la app. El borrado no tiene que ser instantáneo, pero el plazo y qué pasa con los datos tienen que quedar claros al usuario. Ojo: Google Play pide lo mismo y además un enlace web — ver la entrada 82.


52 · Guideline 5.1.2 — Privacy · compartir datos con terceros

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Unless otherwise permitted by law, you may not use, transmit, or share someone's personal data without first obtaining their permission. […] You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so.

Por qué llega. La mención explícita a IA de terceros es reciente y afecta a cualquier app que mande texto o imágenes del usuario a un modelo alojado fuera.

Cómo se arregla. Declararlo y pedir permiso explícito antes del primer envío. Y no reutilizar datos recogidos para un propósito en otro sin consentimiento nuevo. Datos de HealthKit, HomeKit, ClassKit, MovementDisorder y de mapeo facial o de profundidad (ARKit, Camera, Photos) no pueden usarse para marketing ni publicidad, ni por ti ni por terceros.


53 · Guideline 5.1.2(i) — App Tracking Transparency

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

You must receive explicit permission from users via the App Tracking Transparency APIs to track their activity.

Por qué llega. Cualquier SDK que use el IDFA o que cruce datos con otras apps o webs cuenta como tracking: redes de publicidad, atribución, algunas de analítica. Y el rechazo llega igual si el SDK está integrado y el prompt de ATT no aparece — aunque tú no lo estés usando todavía.

Cómo se arregla. Llamar a ATTrackingManager.requestTrackingAuthorization antes de que cualquier SDK toque el IDFA, y que la declaración de privacidad de App Store Connect diga que hay tracking. Dos errores frecuentes: pedir el permiso y arrancar el SDK sin esperar la respuesta, y contar los datos de una SDK de atribución como «analítica» en el nutrition label.


54 · Guideline 5.1.3(ii) — datos de salud en iCloud

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps must not write false or inaccurate data into HealthKit or any other medical research or health management apps, and may not store personal health information in iCloud.

Por qué llega. Sincronizar con CloudKit por comodidad. Prohibido para información personal de salud, sin matices.


55 · Guideline 5.1.3(iii)(iv) — investigación con sujetos humanos

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps conducting health-related human subject research must obtain consent from participants or, in the case of minors, their parent or guardian. […] must secure approval from an independent ethics review board.

Por qué llega. Cualquier estudio, aunque sea un piloto con un hospital, necesita consentimiento y aprobación de un comité ético independiente. La documentación se adjunta en la revisión.


56 · Guideline 5.1.4 — Kids Category · analítica y publicidad de terceros

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Apps intended primarily for kids should not include third-party analytics or third-party advertising. This provides a safer experience for kids.

Por qué llega. Basta con que la app esté pensada principalmente para niños; no hace falta estar en la categoría Kids del App Store. Y «analítica de terceros» incluye Firebase Analytics, que va dentro de casi cualquier proyecto Flutter por defecto al integrar Firebase.

Cómo se arregla. Fuera analítica y publicidad de terceros, o analítica propia. En casos limitados se permiten si el servicio cumple los mismos términos de la guideline 1.3, lo que en la práctica significa negociar un acuerdo específico con el proveedor — no es la vía rápida. Si la app es para colegios o para menores, decidir esto antes de meter el SDK, porque sacarlo después implica rehacer la medición entera.


57 · Guideline 5.1.5 — Location Services

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Use Location Services in your app only when it is directly relevant to the features and services provided by the app. Location-based APIs shouldn't be used to provide emergency services or autonomous control over vehicles, aircraft, and other devices, except for small devices such as lightweight drones and toys […] Ensure that you notify and obtain consent before collecting, transmitting, or using location data.

Por qué llega. Relevante si hacéis IoT o movilidad: control autónomo de vehículos vía ubicación está fuera, salvo dispositivos pequeños. Y aviso más consentimiento antes de recoger.


🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Don't use protected third-party material such as trademarks, copyrighted works, or patented ideas in your app without permission, and don't include misleading, false, or copycat representations, names, or metadata in your app bundle or developer name. Apps should be submitted by the person or legal entity that owns or has licensed the intellectual property and other relevant rights.

Por qué llega. La última frase es la que afecta a una agencia: la app la tiene que enviar quien posee o ha licenciado los derechos. Publicar la app de un cliente desde la cuenta de desarrollador de la agencia es exactamente el patrón que este número persigue, y llega meses después del lanzamiento, cuando alguien reclama.

Cómo se arregla. La app del cliente se publica desde la cuenta de desarrollador del cliente, con la agencia como usuario invitado con el rol que necesite. Si por lo que sea hay que publicarla desde la cuenta de la agencia, que exista una licencia escrita de la marca y del contenido, y guardarla: es lo que hay que adjuntar cuando llegue la reclamación. Y revisar el nombre de desarrollador que se muestra en la ficha, que también entra en este número.


59 · Guideline 5.2.2 — servicios de terceros sin permiso

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

If your app uses, accesses, monetizes access to, or displays content from a third-party service, ensure that you are specifically permitted to do so under the service's terms of use. Authorization must be provided upon request.

Por qué llega. APIs no oficiales, scraping, mostrar contenido de un servicio ajeno. La última frase es la que duele: te pueden pedir la autorización y hay que tenerla.


60 · Guideline 5.2.3 — descargar audio o vídeo de terceros

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps should not facilitate illegal file sharing or include the ability to save, convert, or download media from third-party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc.) without explicit authorization from those sources.


61 · Guidelines 5.3.1 y 5.3.2 — Sorteos, concursos y rifas

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política · 5.3.1

Sweepstakes and contests must be sponsored by the developer of the app.

📖 De la política · 5.3.2

Official rules for sweepstakes, contests, and raffles must be presented in the app and make clear that Apple is not a sponsor or involved in the activity in any manner.

Por qué llega. Dos requisitos separados y se rechaza por cualquiera de los dos.

El de 5.3.2 es el que pilla a todo el mundo: hay que decir explícitamente en las bases que Apple no es patrocinador ni está vinculada de ninguna forma. No basta con tener bases legales correctas ni con enlazarlas desde la web: tienen que estar dentro de la app y accesibles en todo momento.

El de 5.3.1 es más sutil y aparece en cuanto el sorteo es de una marca cliente: el patrocinador tiene que ser el desarrollador de la app. Un tercero puede ser anunciante, proveedor del premio o host, pero no patrocinador — el patrocinador es quien responde del concurso. Si la app es de Dribba y el sorteo lo organiza la marca, hay que revisar quién figura como sponsor en las bases y quién publica la app. El rechazo típico llega cuando el revisor no ve suficientemente claro que sea el desarrollador quien lo patrocina.

Cómo se arregla.

  • Bases completas dentro de la app, alcanzables desde el propio sorteo y desde Ajustes, no solo en un enlace externo
  • Frase explícita del tipo: «Apple no patrocina este sorteo ni está vinculada a él de ninguna manera»
  • El desarrollador que publica la app figura como patrocinador en las bases
  • Y en las Notes for Review, la ruta para llegar a las bases

Y ojo con el ámbito legal: las bases de un sorteo en España tienen requisitos propios —fiscalidad del premio, protección de datos, depósito ante notario según el caso— que no tienen nada que ver con Apple. Eso lo revisa un abogado, no el equipo de producto.


62 · Guideline 5.4 — VPN

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps offering VPN services must utilize the NEVPNManager API and may only be offered by developers enrolled as an organization.

Por qué llega. Dos requisitos duros: la API concreta y cuenta de organización. Y hay que declarar con claridad qué datos de usuario se recogen.


63 · ITMS-90062 · versión no incrementada

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📋 Literal

ITMS-90062: This bundle is invalid. The value for key CFBundleShortVersionString [X.X.X] in the Info.plist file must contain a higher version than that of the previously approved version.

Por qué llega. Se subió el build sin tocar la versión. Trivial y consume un ciclo de subida.

Cómo se arregla. Automatizarlo en el pipeline: la versión y el build number no se tocan a mano.


64 · ITMS-90683 · falta el purpose string en el Info.plist

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

ITMS-90683: Missing purpose string in Info.plist - Your app's code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the [app].app bundle should contain a NSCameraUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data.

Por qué llega. Casi siempre por una SDK de terceros que referencia la API, aunque tu código no la use. Se rechaza igual.

Cómo se arregla. Añadir la clave que pide el error. Si no sabes de dónde sale, strings sobre el binario o busca el símbolo en los frameworks embebidos. No es un rechazo de App Review: es un rechazo en la subida, llega en minutos.


65 · ITMS-90717 · icono con canal alfa

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📋 Literal

ITMS-90717: Invalid App Store Icon. The App Store Icon in the asset catalog in 'Runner.app' can't be transparent nor contain an alpha channel.

Por qué llega. El icono de 1024×1024 salió con transparencia. En Flutter es un clásico de flutter_launcher_icons con un PNG de origen con alfa.

Cómo se arregla. Aplanar el icono sobre fondo opaco antes de generar los tamaños.


66 · ITMS-90809 · UIWebView

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📋 Literal

ITMS-90809: Deprecated API Usage. UIWebView is no longer accepted.

Por qué llega. Casi nunca es tu código: es una dependencia antigua. En Flutter, un plugin sin mantener.

Cómo se arregla. Localizar la dependencia (grep -r UIWebView sobre los pods y frameworks embebidos) y actualizarla o sustituirla por WKWebView.


67 · ITMS-91053 · falta la declaración de API en el privacy manifest

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

ITMS-91053: Missing API declaration - Your app's code in the "[fichero]" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults.

Por qué llega. Desde el 1 de mayo de 2024, los envíos deben incluir un array NSPrivacyAccessedAPITypes en el privacy manifest con las razones aprobadas para las required reason APIs. Las categorías más frecuentes: UserDefaults y FileTimestamp.

Cómo se arregla. Un PrivacyInfo.xcprivacy en el bundle con las categorías y sus razones. El nombre del fichero es obligatorio, exactamente ese. Las SDK de terceros deben traer el suyo; si una no lo trae, actualízala o sustitúyela — el envío es tu responsabilidad.


68 · ITMS-91061 · privacy manifest de una SDK de terceros

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📋 Literal

ITMS-91061: Missing privacy manifest — Your app includes "<path/to/SDK>", which includes, an SDK that was identified in the documentation as a privacy-impacting third-party SDK.

Por qué llega. Es el hermano del ITMS-91053, pero aquí el manifest que falta es de la SDK, no tuyo. Apple mantiene una lista de SDK con impacto en privacidad y todas tienen que traer el suyo firmado.

Cómo se arregla. Actualizar la SDK a una versión que incluya PrivacyInfo.xcprivacy. Si el mantenedor no la ha publicado, no hay workaround limpio: hay que sustituirla o esperar. Conviene revisarlo antes de la semana de la release.


69 · Missing Compliance · ITSAppUsesNonExemptEncryption

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal (no es un rechazo de revisión: bloquea el build antes)

Missing Compliance — You must provide export compliance information for this build before you can submit it for review.

Por qué llega. App Store Connect está haciendo una pregunta de control de exportación de EE. UU.: ¿usa la app cifrado y, si lo usa, del tipo que exige papeleo? Si el Info.plist no responde, el build se queda bloqueado y no se puede seleccionar. No es un rechazo de App Review, pero cuesta el mismo día de calendario y suele aparecer justo cuando quieres subir la release.

Cómo se arregla. Si la app no usa cifrado no exento —el caso de la gran mayoría, que solo usan HTTPS— basta con ITSAppUsesNonExemptEncryption a NO en el Info.plist, o App Uses Non-Exempt EncryptionNO en las Custom iOS Target Properties si el proyecto genera el plist. El siguiente archive deja de preguntar.

Dos detalles: el build que ya está subido no recoge la clave retroactivamente, así que a ese hay que responderle la pregunta a mano en App Store Connect para desbloquearlo; y si la app usa cifrado propio, entonces sí hace falta documentación legal y una revisión de ese cifrado antes de poder seleccionar builds. Si hay dudas sobre si el cifrado es exento, que lo revise un abogado: es una declaración ante control de exportación, no una casilla de Xcode.


Google Play — 31

Agrupados por tipo: funcionamiento, permisos, datos, contenido y requisitos técnicos.

70 · Broken Functionality

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Issue found: Violation of Broken Functionality policy App installs, but doesn't load. Make sure to fix all broken experiences within your app.

y en otra variante:

Your app contains content that isn't compliant with the Broken Functionality policy.

Por qué llega. En vigor desde el 31 de agosto de 2024, y es el rechazo que más ha crecido. Dispara con mucho más que crashes:

  • Crash en el arranque
  • Enlace de política de privacidad roto — sí, solo eso
  • Un permiso que la app pide y no necesita
  • Apps estáticas sin funcionalidad propia: solo texto, solo un PDF, un único fondo de pantalla
  • Apps que no instalan o no cargan

Cómo se arregla. El rechazo suele llegar sin decir qué lo causó, lo que hace que la gente reenvíe a ciegas y acumule rechazos —que escalan a suspensión—. Antes de reenviar, pide el detalle desde la página de Ayuda del Play Console. Y comprueba lo obvio primero: que el enlace de privacidad devuelve 200 y que no queda ningún permiso heredado de una SDK que ya no usas.


71 · Invalid Data Safety Form

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Invalid Data Safety Form

Por qué llega. Discrepancia entre lo declarado y lo que la app hace de verdad. La causa casi nunca es tu código: son las SDK. AdMob, Firebase Analytics y las de crash reporting recogen datos en segundo plano, y cualquier dato que salga del dispositivo desde una librería tuya hay que declararlo, aunque nunca toque tu servidor. Otro clásico: interacciones in-app e historial de búsqueda cuentan como app activity y casi nadie lo declara.

Cómo se arregla. Inventario de SDK con qué recoge cada una, y el formulario reconstruido a partir de eso. Y un punto en el checklist de release: si cambia una versión de SDK, se revisa el formulario. La responsabilidad de la declaración es tuya, no de la SDK.


72 · ACCESS_BACKGROUND_LOCATION

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Apps should request the minimum scope necessary (for example, using foreground instead of background device location permissions) to provide the feature or service that requires location, and users should reasonably expect that an app's feature or service needs the level of location requested. Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app.

Por qué llega. El permiso que más se pide «por si acaso». Google rechaza si no hay justificación convincente ligada a la funcionalidad principal.

Cómo se arregla. O se elimina y se pasa a foreground, o se rellena la declaración explicando la función principal que lo necesita, con vídeo de la función en uso. La prueba a superar: sin ese permiso la funcionalidad principal no existe.


73 · QUERY_ALL_PACKAGES

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

You must be able to adequately justify why a less intrusive method of app visibility will not sufficiently enable your app's policy-compliant user-facing core functionality. Core functionality is defined as the main purpose of the app, and without this core ability to search for all apps on the device, the app is "broken" or becomes unusable.

Por qué llega. Suele venir de una SDK (antifraude, seguridad, algunos SDK de pago) que lo mete en el manifest sin que tú lo sepas.

Cómo se arregla. Usos permitidos: buscadores de dispositivo, antivirus, gestores de ficheros y navegadores. Si no eres uno de esos, quítalo del manifest. Localízalo con el manifest fusionado (app/build/outputs/logs/manifest-merger-*-report.txt) para saber qué dependencia lo introduce.


74 · Permisos de SMS y registro de llamadas

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Apps lacking default SMS, Phone, or Assistant handler capability may not declare use of these permissions in the manifest, including placeholder text in the manifest.

Por qué llega. El uso permitido es muy estrecho: ser el manejador por defecto de SMS, teléfono o asistente. Y la app tiene que estar registrada activamente como manejador por defecto antes de pedir el permiso. Lo que pilla a la gente: el permiso no puede ni figurar en el manifest, ni como texto de relleno. Un plugin de verificación por SMS que lea el código automáticamente entra aquí.

Cómo se arregla. Para autoverificación de OTP, la vía es la SMS Retriever API o SMS User Consent, que no necesitan READ_SMS. Si el uso sí es legítimo, hay que completar el Permissions Declaration Form y esperar aprobación. Existe un régimen de excepciones para APKs antiguos publicados antes del 1 de enero de 2019 que representen un porcentaje bajo de la base instalada, pero es un parche de transición, no una solución.


75 · MANAGE_EXTERNAL_STORAGE · acceso a todos los archivos

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Google Play policy treats access to user files and directories as sensitive and high risk access, so we restrict use of the MANAGE_EXTERNAL_STORAGE permission on Android 11+. All apps that target R and request broad access to shared storage ("All files access") must successfully pass an appropriate access review prior to publishing.

Por qué llega. Es la salida fácil cuando el scoped storage de Android 11 rompe algo, y es una salida cara: exige pasar una revisión de acceso antes de publicar. Lo piden muchas apps que en realidad solo necesitan leer o escribir un tipo de fichero concreto.

Cómo se arregla. Casi siempre se puede evitar: MediaStore para media, el Storage Access Framework (ACTION_OPEN_DOCUMENT) para ficheros que el usuario elige, el directorio propio de la app para el resto. Si de verdad hace falta —gestores de ficheros, antivirus, apps de backup— hay que pasar la revisión y además pedir al usuario que active «All files access» en Ajustes especiales de forma clara.


76 · Tipos de foreground service (Android 14)

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Issue found: Violation of Permissions and APIs that Access Sensitive Information policy — Foreground service permissions

Por qué llega. Desde Android 14 (API 34) hay que declarar un tipo para cada foreground service en el manifest y pedir el permiso de foreground service correspondiente a ese tipo, además de FOREGROUND_SERVICE. Y hay que declararlo también en Play Console, en Policy → App content. Es un rechazo que llegó en masa con la subida a API 34 y sube otra vez con la de API 35.

Un caso que desconcierta: apps rechazadas por un permiso de foreground service que no usan. Viene de una dependencia que lo declara.

Cómo se arregla. Un tipo por servicio, con el permiso que le toca, y la declaración de Play Console rellenada con la descripción de para qué se usa cada uno. Para saber qué se está declarando de verdad, mirar el manifest fusionado, no el del módulo. Si un tipo viene de una librería que ya no usas, elimínala: declarar un servicio que no existe también es motivo de rechazo.


77 · Inadequate Prominent Disclosure

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

Issue found: Inadequate Prominent Disclosure

Por qué llega. El aviso previo al permiso tiene que cumplir cuatro condiciones y casi nadie cumple las cuatro. La política exige que la revelación:

  • esté dentro de la app, no solo en la descripción de la ficha ni en la web
  • aparezca en el uso normal de la app, sin que el usuario tenga que entrar en un menú o en Ajustes
  • describa qué dato se accede o recoge, y cómo se usa o se comparte
  • no viva únicamente en la política de privacidad o en los términos, ni vaya mezclada con avisos de otra cosa

Y tiene que ir inmediatamente antes de la petición de permiso en tiempo de ejecución. El error clásico: pedir el permiso del sistema a pelo, y explicar el motivo después, o solo en el purpose string.

Cómo se arregla. Una pantalla propia antes del prompt del sistema, con el dato, el uso y dos opciones — aceptar y rechazar-ahora-pero-poder-aceptar-luego. Y si el usuario deniega o revoca, la app degrada con elegancia: se desactiva la función que necesitaba el permiso, no se bloquea la app.


78 · Metadata policy

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

We don't allow apps with misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata, including but not limited to the app's description, developer name, title, icon, screenshots, and promotional images.

Por qué llega. Keywords repetidas o no relacionadas, longitud excesiva, formato raro (emojis o mayúsculas en el título), repetición.

Cómo se arregla. Título descriptivo sin relleno, descripción que describa la app y no una lista de términos. También cae aquí el nombre del desarrollador si es engañoso.


79 · Repetitive Content

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

We don't allow apps that offer a low-value or disruptive user experience, including apps with copy-paste content or clones of existing apps, apps that are functionally identical to others the developer has published, and repetitive listing practices of uploading many similar apps under one developer account.

Por qué llega. El equivalente del 4.3 de Apple. Muy habitual en white label y en catálogos generados.

Cómo se arregla. Consolidar en una app configurable. Google publica una guía específica de buenas prácticas para desarrolladores de white label — leerla antes de subir la segunda variante, no después de la décima.


80 · Deceptive Behavior

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Your app must always maintain honesty and transparency, and must never mislead users. All metadata, including the store listing, screenshots, and title, must precisely reflect the app's functionality.

Por qué llega. El caso más común: capturas que muestran funciones que la app no tiene — mockups de roadmap, pantallas de la versión de escritorio, funciones detrás de un paywall que el revisor no ve.

Cómo se arregla. Capturas de lo que hay hoy en producción. Si una función está en la ficha, tiene que ser alcanzable en la revisión.


81 · Sorteos y promociones · Real-Money Gambling, Games, and Contests

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Developers must specify a fixed number of winners, fixed entry deadline, and prize award date, per promotion, within the official terms of a program offering drawings, sweepstakes, or other similar style promotions.

Por qué llega. Google no pide el disclaimer de Apple, pide concreción: número fijo de ganadores, fecha límite de participación fija y fecha de entrega del premio, por promoción y dentro de las bases oficiales. Un «sortearemos entre todos los participantes durante el verano» no cumple ninguna de las tres.

Además, si la app maneja puntos o recompensas de fidelidad, hay que documentar de forma conspicua el ratio de acumulación y de canje, en la app y en las bases.

Cómo se arregla. Las tres cifras fijas en las bases, y las bases dentro de la app. Si la app facilita juego con dinero real, hay que usar además las herramientas de Play Console para bloquear a menores y no puede estar en Designed for Families.

Un aviso de alcance: Google trata los sorteos promocionales y el juego con dinero real en la misma página de política, así que conviene verificar caso a caso qué parte aplica a una promoción sin dinero real.


82 · Account deletion · in-app y enlace web

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

If an app allows users to create an account, it must allow users to request for their account to be deleted in the app and through a web resource. […] Some users may have uninstalled the app or be unable to access the in-app experience, so developers must ensure users can request data deletion via the web link without needing to re-download the app.

Por qué llega. Aquí Google va más allá que Apple: además del flujo dentro de la app, exige un recurso web donde pedir el borrado sin reinstalar. Mucha gente cumple el 5.1.1(v) de Apple y da esto por hecho.

Cómo se arregla. Flujo in-app + una URL pública de solicitud de borrado, declarada en Play Console. Al borrar la cuenta hay que borrar los datos asociados, con las excepciones legítimas de seguridad, prevención del fraude y cumplimiento normativo.

Sobre plazos: los cambios anunciados el 15 de abril de 2026 dan al menos 30 días para adaptarse. Google ajusta estas fechas, así que el plazo vigente está siempre en Play Console.


83 · Target API level

🔴 Frecuente — de los que llegan una y otra vez.

📋 Literal

App must target Android 15 (API level 35) or higher

Por qué llega. Las apps existentes tienen que targetear API 35 antes del 31 de agosto de 2026. Las que se queden en API 34 o inferior solo estarán disponibles en dispositivos con una versión de Android igual o inferior a su target: no se retiran, dejan de ser descubribles en el mercado nuevo.

Cómo se arregla. Subir targetSdk y resolver los cambios de comportamiento de la versión. Si no llegas, hay formulario de extensión hasta el 1 de noviembre de 2026 en Play Console. Los usuarios que ya la tienen instalada pueden seguir usándola y reinstalándola.


84 · Propiedad intelectual

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

We don't allow apps that infringe on the intellectual property rights of others.

Por qué llega. Puede que te pidan pruebas de que tienes derecho a usar el material. Google nombra: imágenes de películas, series, videojuegos, portadas de discos y arte de cómics o dibujos animados.

Cómo se arregla. Documentación de la licencia o cesión, adjunta en la apelación. Si el material es de un cliente, pide el contrato antes de subir la app, no cuando llegue el rechazo.


85 · Contenido de la ficha, no de la app

🔴 Frecuente — de los que llegan una y otra vez.

📖 De la política

Content that is lewd or profane – including content which may contain profanity, slurs, explicit text, or adult/sexual keywords in the store listing or in-app – violates policies.

Por qué llega. Se revisa la ficha, no solo el binario. Pilla a apps de citas, salud sexual y humor.

Cómo se arregla. Revisar título, descripción corta, descripción larga y capturas con el mismo criterio que la app.


86 · ⚡ Accessibility API · el cambio que afecta a los agentes de IA

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política (actualización de política)

Any use of this API that enables an app to autonomously initiate, plan, and execute actions is prohibited.

Por qué importa ahora. Google ha aclarado la política de AccessibilityService para prohibir el uso que permite a una app iniciar, planificar y ejecutar acciones de forma autónoma. Es decir: los agentes que operan la interfaz del dispositivo por su cuenta. La razón que da Google es que ese patrón cambia ajustes sin permiso, elude los controles de privacidad de Android y usa la interfaz de forma engañosa.

Si estás construyendo automatización sobre el dispositivo, esto es una restricción de diseño, no un detalle de compliance.

Cómo se arregla. Las apps que no cumplen el atributo IsAccessibilityTool tienen además que cumplir prominent disclosure y consentimiento (entrada 77), describiendo qué datos se acceden vía la API y para qué. Y un detalle que desconcierta: hay rechazos por un AccessibilityService que ya se eliminó en la última versión — el manifest fusionado sigue declarándolo desde una dependencia.


87 · ⚡ SMS y llamadas · se acabó verificar cuentas por llamada

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política (actualización de política)

The SMS and Call Log Permissions policy will no longer permit account verification via phone call. To securely verify accounts, use the Digital Credentials API instead, either directly or through a verification provider built upon it, or the SMS Retriever API.

Por qué importa ahora. Si tenéis onboarding con verificación por llamada perdida o por llamada automática, hay que migrarlo. Las vías admitidas son la Digital Credentials API o la SMS Retriever API.


88 · ⚡ Contacts Permissions · usar el selector de contactos de Android

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

We don't allow unauthorized publishing or disclosure of people's non-public contacts.

Por qué llega. Google introdujo la política de permisos de contactos para gobernar el acceso amplio a la agenda: las apps que no necesitan acceso amplio tienen que usar el Android Contact Picker.

Cómo se arregla. Si solo necesitas que el usuario elija un contacto, el picker resuelve y evita el permiso.


89 · Photo and Video Permissions

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps that target Android 13 or later (API level 33+) may only request the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions if system pickers (like the Android Photo Picker), are not sufficient for your app to provide core functionality.

Por qué llega. Es el equivalente del MANAGE_EXTERNAL_STORAGE para media, y la fecha de cumplimiento fue el 22 de enero de 2025. Un detalle que pilla a mucha gente: tener un selector propio no te habilita automáticamente — hay que presentar la declaración en Play Console explicando por qué el Photo Picker no basta.

Cómo se arregla. Photo Picker si es una selección puntual. Si necesitas acceso persistente o frecuente, hay que pasar la revisión de acceso demostrando el caso de uso principal.


90 · Impersonation

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

We don't allow apps that mislead users by impersonating someone else.

Por qué llega. Nombre de desarrollador, icono o ficha que sugieren ser otra empresa. En una agencia aparece por accidente: publicar la app de un cliente con el nombre de desarrollador de la agencia puede leerse como suplantación de la marca del cliente — y es el mismo problema que el 5.2.1 de Apple (entrada 58).


91 · Payments · saltarse Google Play Billing

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Developers offering products within a game downloaded on Google Play or providing access to app functionality must use Google Play's billing system.

Por qué llega. Es el 3.1.1 de Apple con otra redacción. Hay excepciones y programas alternativos según jurisdicción, y cambian: no es un detalle que se decida en la semana de la release.


92 · Subscriptions · transparencia y cancelación

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

You must be transparent about your subscription offerings — clearly and accurately describe the terms, including price, frequency of billing, and how to cancel.

Por qué llega. Mismo patrón que el 3.1.2(c) de Apple: precio, frecuencia y cómo cancelar, claros antes de la compra.


93 · Ads · anuncios disruptivos

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

We don't allow apps that contain deceptive or disruptive ads. Ads must not interfere with normal app usage or device operation.

Por qué llega. Intersticiales que aparecen sin acción del usuario, anuncios que tapan controles, anuncios fuera de la app, botones de cierre que no cierran. Es de los rechazos más rápidos porque el revisor lo ve en el primer minuto.


94 · Families / Designed for Families

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

The Families Policy Requirements policy prohibits anonymous chat apps from targeting children.

Por qué llega. El programa Designed for Families tiene requisitos propios que se suman a todo lo demás: contenido, anuncios, SDK permitidas y clasificación. Y hay incompatibilidades duras — una app con publicidad de juego con dinero real no puede estar inscrita.

Cómo se arregla. Decidir el público objetivo al empezar. Entrar en Families a mitad de proyecto suele obligar a cambiar SDK de analítica y de publicidad.


95 · Content Ratings · app sin clasificar

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Google Play does not allow unrated apps.

Por qué llega. El cuestionario de clasificación (IARC) sin completar, o completado y desactualizado después de añadir chat o contenido de usuarios.


96 · Financial Services · préstamos personales

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

In the United States, we do not allow apps for personal loans where the Annual Percentage Rate (APR) is 36% or higher.

Por qué llega. Mismo umbral del 36 % que Apple (entrada 39), pero aquí acotado a EE. UU. Las apps de servicios financieros tienen además requisitos de declaración y de licencia por país.


97 · Health content

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

We don't allow apps that expose users to harmful health content and services.

Por qué llega. Claims de tratamiento sin evidencia, promoción de terapias no probadas, contenido que desincentiva tratamiento médico. Relevante para healthtech y wellness.


98 · Unapproved Substances

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Google Play doesn't allow apps that promote or sell unapproved substances, irrespective of any claims of legality.

Por qué llega. Suplementos, nootrópicos, cannabinoides. La frase final es la importante: que sea legal en tu país no basta.


99 · Device and Network Abuse

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

We don't allow apps that interfere with, disrupt, damage, or access in an unauthorized manner the user's device, other devices or computers, servers, networks, application programming interfaces (APIs), or services.

Por qué llega. Modificar ajustes del sistema sin consentimiento, instalar otras apps sin que el usuario lo pida, consumo de red no declarado. También cae aquí el uso de la API de instalación de paquetes.


100 · Child Endangerment · retirada inmediata

Poco frecuente — existe y se rechaza por él, pero es cola larga.

📖 De la política

Apps that do not prohibit users from creating, uploading, or distributing content that facilitates the exploitation or abuse of children will be subject to immediate removal from Google Play, including all child sexual abuse materials.

Por qué llega. Es la única de la lista sin gradación: no hay rechazo previo ni aviso, es retirada inmediata. Si tu app tiene contenido generado por usuarios, la moderación no es una función que se pospone al siguiente sprint — es la condición para estar en la tienda.

Cómo se arregla. Moderación activa, mecanismo de reporte, y política de uso que prohíba explícitamente ese contenido. Es el mismo requisito que la guideline 1.2 de Apple (entrada 2), con la diferencia de que aquí la consecuencia de fallar no es un rechazo.


Cómo responder

A Apple: tres niveles, en este orden

1 · Resolution Center. El sitio por defecto. La regla que más cambia el resultado: explica cómo cumple tu app la guideline que citan, no por qué crees que la guideline no debería aplicar. Cita el número. Si el rechazo pide información, dala antes de hacer cualquier otra cosa. Si el revisor entendió mal una función, explica cómo estaba pensada que funcionase.

2 · App Review Board. Si después del Resolution Center sigues pensando que es un error, puedes apelar para que se reevalúe. Las reglas de Apple:

  • Sé específico sobre cómo la app cumple las guidelines
  • Una sola apelación por envío rechazado
  • Responde primero a cualquier petición de información

3 · Revisión acelerada. Solo por circunstancias excepcionales: un bug crítico o un lanzamiento que coincide con un evento con el que estás directamente relacionado. No es para llegar a una fecha de marketing autoimpuesta, y gastarla mal quema el crédito para la próxima vez.

Plazos. Apple revisa el 90 % de los envíos en menos de 24 horas. El 10 % restante no tiene plazo garantizado; los primeros envíos y las actualizaciones grandes son los que más caen ahí.

A Google: por el correo, y con cuidado

Google dirige el proceso por el email de notificación: hay que seguir las instrucciones de ese correo, o usar la herramienta de apelación. También se puede pedir ayuda desde la página de Ayuda del Play Console. Reinstalan la app si hubo error y confirman que no viola las políticas.

Dos cosas que conviene tener presentes:

  • Pide el detalle antes de reenviar. Los rechazos de Broken Functionality llegan sin explicación concreta, y reenviar a ciegas suma rechazos que escalan a suspensión.
  • No dan asesoramiento legal. Lo dicen explícitamente en su documentación.

Checklist antes de enviar

Las dos tiendas

  • No crashea en dispositivo físico, con el build exacto que se sube
  • El enlace de política de privacidad devuelve 200 y es accesible dentro de la app
  • Cada permiso está justificado por una función que el revisor puede ver
  • Las capturas muestran la app de hoy funcionando, no el login ni un roadmap
  • Ficha sin marcas ajenas, sin precios y sin relleno de keywords
  • Si hay creación de cuenta, hay borrado de cuenta

App Store

  • Cuenta demo con datos suficientes para recorrer toda la app, sin caducidad
  • Backend accesible 24/7 durante toda la ventana de revisión
  • Notes for Review con una línea por función nueva, con la ruta para llegar
  • Borrado de cuenta iniciable dentro de la app
  • Nombre de 30 caracteres o menos
  • Iconos, capturas y previews aptos para 4+
  • Sin nombres, iconos ni imágenes de otras plataformas o tiendas
  • Todo desbloqueo de contenido pasa por IAP; las monedas compradas no caducan
  • Purpose strings con ejemplo de uso, uno por API sensible
  • PrivacyInfo.xcprivacy al día, incluidas las SDK de terceros
  • Si hay login de terceros, hay opción equivalente (4.8)

Google Play

  • targetSdk 35 o superior (fecha límite: 31/08/2026)
  • Formulario de Data safety reconstruido desde el inventario de SDK
  • Ubicación en segundo plano: justificada con vídeo, o eliminada
  • QUERY_ALL_PACKAGES fuera del manifest fusionado, salvo uso permitido
  • Enlace web de solicitud de borrado de cuenta, además del flujo in-app
  • Derechos documentables sobre todo el material con copyright
  • AAB firmado con Play App Signing

Lo que suele estar detrás

Ninguno de los marcados 🔴 es una discusión de criterio, salvo el 4.3(b) de Apple y el de Repetitive Content de Google. El resto son cosas verificables antes de enviar que se saltan porque la release va con prisa: el backend que se apagó, la nota de review genérica, el borrado de cuenta que nadie implementó, el permiso heredado de una SDK que ya no se usa, el formulario de Data safety de hace tres versiones.

Si tu app está rechazada ahora mismo, así lo abordamos nosotros. Si aún no has enviado, empieza por los requisitos para subir una app a la App Store y por cuánto cuesta publicar en Google Play.


Fuentes

Apple

Google