9 min de lectura

App rechazada en App Store: motivos comunes y cómo resolverlo

Un rechazo de Apple no es el fin del lanzamiento. Aprende a leer el mensaje de App Review, corregir los lineamientos que más se repiten (2.1, 2.3, 4.2, 4.3, 5.1.1 y 3.1.1), responder bien y decidir si apelar.

Portada: App rechazada en App Store, con tarjeta Revisión de la app que muestra estado Rechazada y los lineamientos 2.1, 4.3 y 5.1.1

Subiste tu build, esperaste la revisión y en App Store Connect aparece el aviso de problemas sin resolver: tu app fue rechazada en App Store. No es el fin del lanzamiento. Apple te dice qué lineamiento incumpliste (por ejemplo «Guideline 2.1 - Information Needed» o «Guideline 4.3(a) - Design - Spam») y te deja responder antes de volver a enviar. En esta guía verás cómo leer el mensaje de rechazo, qué significan los lineamientos que más se repiten, cómo responder a App Review y cuándo vale la pena apelar.

Por qué Apple rechaza una app y dónde ver el motivo

Apple compara cada envío de App Store Connect con los Lineamientos de revisión de apps (App Review Guidelines). Si algo no cumple, recibes un correo, pero el detalle está en App Store Connect:

  1. Entra a Apps y elige la app.
  2. Arriba de la página verás un enlace que indica que hay problemas sin resolver. Haz clic.
  3. En la sección In Progress, pulsa Resolve junto al envío rechazado.
  4. Lee el mensaje: trae el lineamiento, una explicación y, a veces, capturas o crash logs.

Para responder necesitas el rol de Account Holder, Admin o App Manager. Si todavía no te mueves con soltura por el panel, repasa qué es App Store Connect y cómo usarlo.

Un dato útil antes de entrar en pánico: Apple indica que más del 40 % de los problemas sin resolver tienen que ver con el lineamiento 2.1 (integridad de la app). La mayoría se arregla completando información o corrigiendo fallos.

Motivos más comunes de una app rechazada en App Store

Guideline 2.1: integridad de la app (App Completeness e Information Needed)

Es el rechazo más frecuente. Llega en dos sabores:

  • 2.1(a) - Performance - App Completeness: la app se cerró, había un botón que no hacía nada, texto de relleno («lorem ipsum», «próximamente»), enlaces rotos o un backend apagado. Apple exige que envíes la versión final, probada en dispositivo real.
  • 2.1 - Information Needed: el revisor no pudo usar la app. Casi siempre falta una cuenta de demostración, la contraseña no funciona o el inicio de sesión depende de un código SMS que el revisor no recibe.

Cómo solucionarlo: en App Review Information escribe una cuenta demo que no caduque, con datos precargados y todas las funciones desbloqueadas (también las de pago). Mantén el servidor encendido y explica en las notas los flujos no obvios. Si el problema era solo de información, puedes reenviar la misma build sin subir una nueva.

Para cazar fallos antes de enviar, prueba la build con testers en TestFlight.

Guideline 2.3: metadatos precisos

La ficha debe reflejar lo que la app hace. Rechazos típicos:

  • 2.3.3: las capturas solo muestran la pantalla de inicio de sesión o el logo, en vez de la app en uso.
  • 2.3.7: el nombre supera 30 caracteres o los metadatos incluyen precios, marcas de terceros o palabras clave irrelevantes.
  • 2.3.10: mencionas otras plataformas («también en Android») o muestras imágenes de otros sistemas.

Cómo solucionarlo: corrige la ficha en App Store Connect. Al tratarse de metadatos, normalmente no necesitas una build nueva.

Guideline 4.2: funcionalidad mínima

Apple rechaza apps que son solo un sitio web dentro de una vista web, un catálogo de enlaces o material publicitario (4.2.2). Si tu app envuelve tu web, añade funciones nativas (notificaciones útiles, modo sin conexión, widgets) y explícalas en las notas para el revisor.

Guideline 4.3: spam (4.3(a) y 4.3(b))

  • 4.3(a): enviaste varias apps casi iguales con distintos bundle ID (una por ciudad, por cliente o por sede). Apple sugiere una sola app con las variantes dentro.
  • 4.3(b): la app no se distingue de otras muy comunes. Apple cita categorías saturadas como linternas, fondos de pantalla, temporizadores simples o adivinación.

Cómo solucionarlo: une las variantes en una app o demuestra en tu respuesta qué hace la tuya que no hagan las demás. Cambiar solo el ícono y el nombre no basta.

Guideline 5.1.1: privacidad y recopilación de datos

Los casos más comunes:

  • 5.1.1(i): falta la política de privacidad, el enlace no abre o no explica qué datos recoges, con quién los compartes y cómo se eliminan. Debe estar enlazada en App Store Connect y dentro de la app.
  • Textos de permiso: el texto que acompaña un permiso (cámara, ubicación, fotos) es vago. Cada clave de permiso en el Info.plist necesita una frase clara de para qué la usas.
  • 5.1.1(v): tu app permite crear cuenta pero no eliminarla desde la app.

Cómo solucionarlo: publica una política completa en una URL pública y enlázala en Ajustes o Acerca de. Aquí tienes los requisitos de la política de privacidad para App Store. Si la app tiene registro, añade un botón visible de «Eliminar cuenta».

Guideline 3.1.1: compras dentro de la app

Si desbloqueas contenido digital (suscripciones, niveles, monedas o versión premium), Apple exige usar su sistema de compras dentro de la app. No sirven claves de licencia ni pagos externos para eso; los bienes físicos y servicios consumidos fuera de la app son otra historia.

Cómo responder a App Review paso a paso

  1. Lee el mensaje y los adjuntos: ¿el problema es de código o de metadatos?
  2. Corrige antes de discutir. Si el revisor tiene razón, arregla y explica el cambio.
  3. Pulsa Reply to App Review en la pantalla del envío, escribe tu respuesta y, si ayuda, adjunta capturas o un video corto con el flujo.
  4. Sé concreto: qué corregiste, en qué build y dónde encontrar la función.
  5. Reenvía. Si cambiaste código, sube una build con un número de build nuevo; si solo era metadatos, reenvía la misma.

Un ejemplo de respuesta breve:

Hola, gracias por la revisión. Actualizamos la cuenta demo en App Review Information (usuario: revisor@tuapp.com). El backend estará activo durante toda la revisión. La opción «Eliminar cuenta» está en Perfil › Ajustes › Eliminar cuenta. Reenviamos la build 1.0.3 (14), probada en un iPhone con la última versión de iOS.

Cuándo apelar, pedir una revisión acelerada o una cita

  • Apelar al App Review Board: solo si crees que el revisor entendió mal la app o que el trato fue injusto. Apple pide razones específicas de por qué cumples los lineamientos, una sola apelación por envío y responder antes cualquier solicitud de información pendiente.
  • Revisión acelerada: para corregir un error crítico (incluye los pasos para reproducirlo) o para un lanzamiento atado a un evento con fecha.
  • Actualizaciones de corrección de errores: si envías un bug fix y Apple detecta otros problemas, puede ofrecerte resolverlos en el siguiente envío, siempre que no haya riesgos legales o de seguridad. Basta con responder al mensaje aceptándolo.
  • Cita con App Review: Apple ofrece videollamadas de 30 minutos para resolver dudas sobre los lineamientos.

Checklist rápido para que no te vuelvan a rechazar

  • Build probada en dispositivo real, sin texto de relleno ni enlaces rotos.
  • Cuenta demo funcional y backend encendido.
  • Notas para App Review que explican funciones no obvias y compras dentro de la app.
  • Capturas que muestran la app en uso y metadatos sin precios ni otras plataformas.
  • Política de privacidad enlazada en la ficha y en la app, y opción para eliminar la cuenta.
  • Textos de permiso claros en el Info.plist.

Si quieres la lista completa, sigue el checklist para publicar una app en App Store. Y para saber cuánto puede tomar cada estado, revisa cuánto tarda en publicarse una app; Apple indica que suele revisar al menos la mitad de los envíos en menos de 24 horas y el 90 % en menos de 48.

Preguntas frecuentes

¿Qué hago si mi app fue rechazada en App Store?

Abre el envío en App Store Connect, lee el lineamiento citado, corrige el problema y responde con Reply to App Review explicando el cambio. Luego reenvía: con build nueva si tocaste código o con la misma si solo eran metadatos.

¿Tengo que subir una build nueva después de un rechazo?

No siempre. Si el rechazo fue por metadatos o por información faltante (como la cuenta demo), puedes reenviar la misma build. Si el problema estaba en la app, necesitas una build con un número de build nuevo.

¿Qué significa «Guideline 2.1 - Information Needed»?

Que el revisor necesita algo para continuar: normalmente una cuenta demo que funcione, instrucciones para llegar a una función o documentación que lo respalde. Responde con esos datos y reenvía.

¿Rechazar mi app afecta mi cuenta de desarrollador?

Un rechazo normal no. Lo que sí pone en riesgo la cuenta, según los lineamientos, es el mal comportamiento reiterado: enviar spam repetido, intentar engañar a la revisión o copiar apps de otros.

Prueba AppConsol antes de tu próximo envío

Uno de los rechazos más fáciles de evitar es el de privacidad. Con el generador de política de privacidad de AppConsol creas gratis una política con el nombre de tu app y los SDK que usas, lista para pegar en App Store Connect y enlazar dentro de la app. Explora el resto de herramientas para capturas, íconos y fichas en AppConsol.

Sigue aprendiendo