Permissión Request Flows

Nunca solicites permisos en el primer arranque, antes de que el usuario haya experimentado nada de la app. El contexto correcto es el instante en que el usuario activa la función que lo necesita: toca "Tomar foto", abre el mapa, graba una nota de voz. Ahí la conexion entre permiso y beneficio es inmediata y racional, no especulativa. Las solicitudes en frio al inicio rinden mal: los prompts ATT de arranque frio rondan tasas por debajo del 15 % de aceptación.

El dialogo nativo de iOS y Android es binario y casi irreversible: si el usuario rechaza, la única vía de recuperación pasa por Ajustes del sistema. Antes de invocarlo, presenta tu propia pantalla puente con lenguaje de marca, icono y beneficio claro, y dos salidas ("Continuar" / "Ahora no"). Esa capa filtra a quienes rechazarian por sorpresa y solo lleva al dialogo nativo a usuarios ya predispuestos a aceptar, preservando el único intento real que da el sistema.

El purpose string del sistema ("La app necesita acceso a tu ubicación") describe la necesidad de la app, no el valor del usuario. La formula efectiva es "[App] usa [recurso] para que puedas [beneficio específico]". La razón importa de forma medible: NN/g hallo que la razón más convincente produjo un 81 % más de solicitudes aprobadas que la menos convincente, y que dar cualquier razón sube la aprobación un 12 % sobre no dar ninguna. El copy del prompt no es decoración: es la palanca.

Pedir permisos "por si acaso" o en lote durante el onboarding es una de las causas principales de desinstalación: cada permiso no justificado genera desconfianza inmediata. Aplica el principio de mínimo privilegio: solicita unicamente el permiso que la función activa requiere en este momento, nada más. Una app de delivery pide ubicación al iniciar el flujo de pedido, no al crear la cuenta; las notificaciones, la camara y los contactos llegan cada uno en su propio momento de valor.

Un usuario que rechaza un permiso no es un usuario perdido, es uno que aún no confia lo suficiente. Deshabilita o restringe unicamente la función específica que lo requiere, muestra un estado explicativo y ofrece un path claro hacia Ajustes si cambia de opinion. Nunca muestres un error genérico ni bloquees funcionalidades no relacionadas: degradar con gracia es un requisito de UX establecido tanto por Material Design 3 como por Apple HIG.

Las notificaciones tienen la relación valor/costo más desfavorable para el usuario, por eso son el permiso con mayor rechazo. Nunca las pidas al inicio del onboarding: espera a que el usuario complete al menos una acción de valor (primer entrenamiento, primer pedido, primer logro), creando un contrato implicito de reciprocidad. Los benchmarks de OneSignal 2024 lo confirman: el opt-in varia enormemente por categoría y momento, desde 20.6 % en juegos iOS hasta 56.7 % en business Android.

El permiso no es solo técnico: es una cesión de confianza. Dile al usuario exactamente que haras con el dato y, sobre todo, que NO haras: "Tu ubicación se usa para mostrarte tiendas cercanas. No la almacenamos ni la compartimos." La ambiguedad activa el instinto de rechazo, y los usuarios con alto alfabetismo digital son especialmente sensibles a cualquier vaguedad que perciban como cobertura legal. La especificidad es lo que convierte una petición en un acuerdo.

El texto del pre-prompt debe ser corto (máximo 3 líneas de cuerpo), con el beneficio en el titular y sin urgencia fabricada ni miedo ("si no lo activas, esto no funcionara"). NN/g documenta como dark pattern etiquetar el botón de aceptar como "Recomendado": eleva la conversión a corto plazo pero erosiona la confianza. El CTA principal es la acción positiva, pero el rechazo debe ser igualmente visible y no punitivo: un "Ahora no" neutro, nunca un "Reducir funciones" que castigue.