App Rating Prompt

Tanto iOS (SKStoreReviewController) como Android (In-App Review API) ofrecen un flujo de calificación estandar que mantiene al usuario dentro de la app sin redirigirlo a la tienda. Al usar la API nativa, el sistema gobierna la frecuencia por su cuenta y garantiza que el prompt no se muestre en exceso. Un modal propio no respeta esas cuotas y produce experiencias rotas: el usuario ve un botón "Califica" pero el dialogo nunca aparece porque la cuota ya se agoto. Google es explicito: no expongas un CTA que dispare la API, porque el usuario puede haber alcanzado su cuota y el flujo no se mostrara.

El instante de mayor disposición para dejar una buena reseña coincide con el momento inmediatamente posterior a un logro dentro de la app: completar una tarea, un nivel, un entrenamiento. Apple lo dice literal: pide la calificación cuando el usuario sienta satisfacción, justo después de completar una acción, y sin interrumpir su actividad. Pedirla en el lanzamiento o durante el onboarding, antes de que el usuario perciba valor, baja la cantidad y la calidad de las reseñas. Y mostrar el prompt tras un fallo técnico o un mensaje de error solo cosecha reseñas negativas y dana la relación.

El review gating es la practica de preguntar primero "Te gusta la app?" y, según la respuesta, enviar a los satisfechos a la tienda y a los insatisfechos a un formulario de soporte, bloqueando su acceso a la reseña publica. Apple y Google lo prohiben explicitamente. Google Play: tu app no debe hacer ninguna pregunta antes ni durante el rating card, incluyendo opiniones ("Te gusta la app?") o predictivas ("La calificarias con 5 estrellas?"). Apple, guideline 3.2.2(x): las apps no deben forzar al usuario a calificar o resenar para acceder a funcionalidad; manipular reseñas puede costar la expulsión del Apple Developer Program.

El sistema gestiona la frecuencia por ti cuando usas la API nativa. Apple lo fija literal: StoreKit muestra el dialogo de calificación como máximo tres veces dentro de un periodo de 365 días por dispositivo; las llamadas extra se ignoran en silencio. Google Play aplica una cuota temporal no publicada, así que invocar launchReviewFlow más de una vez en un periodo corto (por ejemplo, menos de un mes) puede no mostrar nada. Diseña tu lógica de disparo eligiendo pocos hitos de alto valor al año, en lugar de llamar en cada sesión confiando en que el sistema filtrara: eso agota las tres oportunidades anuales en las primeras semanas.

Mostrar el dialogo de calificación mientras el usuario esta en una tarea exigente (un pago, un formulario, un juego activo) eleva la fricción y puede provocar abandono. Apple lo resume: asegurate de no interrumpir su actividad. El prompt debe dispararse solo en un estado de reposo satisfecho: cuando el usuario acaba de completar algo y aún no inicio la siguiente acción. Un retraso corto de 1 a 2 segundos después del evento de exito es preferible a lanzar el dialogo en el fotograma exacto del resultado, que además suele pisar animaciones de confirmación.

El texto del prompt no debe sugerir, implicita ni explicitamente, que el usuario deje 5 estrellas ni que recibira algo a cambio de una reseña positiva. Copys como "Dale 5 estrellas y desbloquea premium" o "Nos darias la calificación más alta?" violan directamente las politicas de Apple y Google. Google Play prohibe incluso las preguntas predictivas del tipo "La calificarias con 5 estrellas?". Ofrecer recompensas, descuentos o moneda in-app a cambio de reseñas viola ambas politicas aunque no exijas que la reseña sea positiva. El copy debe invitar a una opinion genuina, reconociendo que toda retroalimentación es valiosa, sin presión emocional ni material.

La alternativa legitima al review gating es ofrecer, después de que el usuario haya visto el prompt nativo (no antes), un punto de contacto con soporte para quien quiera reportar un problema. Esto no reemplaza ni condiciona el flujo de rating: ambos caminos coexisten. El usuario insatisfecho puede calificar publicamente y además pedir ayuda, lo que mejora la percepción de marca y la calidad del feedback accionable. La clave es el orden: primero el flujo nativo, luego, de forma sutil, la oferta de soporte. Apple recomienda además que tu información de contacto sea fácil de encontrar para dar una vía directa de ayuda.

El dialogo nativo del sistema (SKStoreReviewController / In-App Review) ya es accesible por diseño, pero la lógica de tu app puede romper la experiencia. Si lanzas el prompt mientras el foco de VoiceOver o TalkBack esta en mitad de un flujo critico, la persona con discapacidad visual queda desorientada y el foco se interrumpe abruptamente. La pantalla de exito que precede al prompt debe tener una etiqueta accesible clara ("Nivel 5 completado. Felicitaciones.") y el disparo debe esperar a que el lector termine de leerla. Los escaneres automáticos solo detectan cerca del 30-40% de los problemas WCAG; el orden de lectura y el comportamiento interactivo exigen prueba manual con lector real.