Notificaciones push en una app: cuándo usarlas y cómo diseñarlas

Las notificaciones push en una app son mensajes que el sistema operativo muestra en el celular aunque la aplicación esté cerrada. Parecen un detalle, pero afectan el alcance de un proyecto: requieren configuración en los servidores, permisos del usuario y decisiones sobre qué se envía, a quién y cuándo. Esta página explica cuándo conviene usarlas, cómo diseñarlas para no molestar y qué preguntar antes de incluirlas.

Qué hace la función

El servidor de la app le pide al servicio de notificaciones de la plataforma (el de Android o el de iOS) que entregue un mensaje a un dispositivo concreto. El teléfono lo muestra en la pantalla de bloqueo o en la barra de avisos, y al tocarlo se abre la app en la pantalla correspondiente. Para que funcione, la app registra el dispositivo y guarda un identificador, que cambia si se reinstala o se restablece.

Push, email o SMS: cuál usar

Canal	Ventajas	Limitaciones
Push	Inmediato, sin costo por mensaje en el canal de la plataforma, abre la app directo	Requiere app instalada y permiso del usuario; puede desactivarse sin que te enteres
Email	Llega a quien aún no instaló la app; admite contenido largo	Menos inmediato; puede ir a spam
SMS	No necesita app ni datos	Texto corto; suele tener costo por envío

Para avisos críticos, como la confirmación de un turno, conviene combinar canales: push como primera vía y email como respaldo. Las alternativas fuera de la app se tratan en recordatorios por email, SMS y WhatsApp. Mateturnos, por ejemplo, notifica por email y Telegram; es un ejemplo de que push no es la única forma de avisar (ver el caso).

Casos de uso

• Aviso de que un turno fue confirmado, cambiado o cancelado.
• Estado de un pedido o una orden de trabajo.
• Mensaje nuevo en un chat.
• Recordatorio con un horario cercano.
• Novedad puntual: un cupón por vencer, un cambio de horario del local.

Decisiones de diseño

Permiso: pedirlo en el momento adecuado

En iOS la app debe pedir permiso explícito para mostrar notificaciones. En Android, las versiones recientes también lo piden; las anteriores lo daban por defecto. Los requisitos varían por versión, por lo que conviene verificar los vigentes. Si el permiso se rechaza, volver a pedirlo suele ser difícil: el usuario tiene que cambiarlo en los ajustes. Por eso conviene explicar el beneficio antes de mostrar el cuadro del sistema, y pedirlo cuando el usuario ya vio la utilidad, no al abrir la app por primera vez.

Segmentación

No todos los mensajes son para todos. Podrías segmentar por rol, por sede, por tipo de servicio o por preferencias que el usuario elige. Cuanto más fino, más datos y lógica hay que mantener.

Preferencias del usuario

Una pantalla donde cada persona decide qué avisos recibe reduce las desactivaciones totales. Es una funcionalidad pequeña con mucho impacto en la relación con el usuario.

Transaccional frente a promocional

Un aviso de un turno confirmado es útil; una promoción cada día cansa. Separar ambos tipos permite que el usuario silencie uno y conserve el otro.

Buenas prácticas para no molestar

• Enviá solo lo que el usuario espera o necesita en ese momento.
• Evitá los horarios de descanso; si el aviso no es urgente, programalo.
• Texto corto con la información concreta (qué, cuándo) y no un mensaje genérico.
• Que cada notificación lleve a la pantalla relacionada, no al inicio.
• Limitá la frecuencia y agrupá los avisos similares.

Android, iOS y web: diferencias generales

Ambas plataformas dependen de sus propios servicios y de permisos del usuario, y ambas imponen reglas sobre el uso de notificaciones y el ahorro de batería. En Android hay más control sobre canales y categorías de notificación; en iOS el sistema es más restrictivo con el permiso y con la entrega en segundo plano. En una PWA, la disponibilidad de push depende del navegador y de la versión del sistema, y en iOS tiene condiciones particulares. Si esta función es esencial, revisá la comparación en app móvil o PWA y verificá las condiciones vigentes.

Impacto en el alcance

Incluir push suma trabajo en tres frentes: la app (registro del dispositivo, permisos, manejo del toque), el servidor (cuándo y a quién se envía) y la configuración con cada plataforma, incluidas las cuentas de desarrollador y credenciales. Si hay segmentación, preferencias o envío masivo desde un panel, el alcance crece. Dependiendo del volumen, el servicio de envío puede tener costos; verificá las condiciones del proveedor que se elija.

Riesgos

• Entrega no garantizada: el sistema puede demorar o descartar mensajes (ahorro de batería, sin conexión).
• Información sensible visible en la pantalla de bloqueo.
• Tokens desactualizados que generan envíos que nunca llegan.
• Que sea el único canal para algo importante.

Qué preguntar antes de incluirlas

1. ¿Qué aviso concreto justifica la notificación? ¿Qué pasa si no llega?
2. ¿Se necesita segmentar o alcanza con avisos individuales?
3. ¿Quién puede enviar mensajes manuales, y con qué aprobación?
4. ¿Cuál es el canal de respaldo?
5. ¿Qué datos pueden aparecer en el texto?

Si querés evaluar si las notificaciones push corresponden a tu proyecto, escribinos desde el formulario de contacto; trabajamos desde Rosario y las vemos como parte del alcance de la primera versión.