Web push en Safari para macOS: qué cambia respecto a Chrome y Firefox

Safari para macOS recibe notificaciones web push desde Safari 16.1 en macOS 13 Ventura, con el mismo estándar que Chrome y Firefox y sin que la persona tenga que instalar nada. Las diferencias están en los detalles: el permiso solo se puede pedir desde un clic, cada push tiene que mostrar una notificación, varias opciones de diseño se ignoran y los ajustes de macOS deciden si el aviso llega a verse.

En resumen:

• Requisitos: macOS 13 Ventura o posterior, Safari 16.1 o superior y una web con HTTPS. No hace falta cuenta de Apple Developer.
• La suscripción tiene que empezar directamente en el clic, sin esperas antes.
• Safari muestra título y texto; ignora imágenes, botones y requireInteraction, y icon y tag no tienen efecto.
• Si llega una push y no se muestra ninguna notificación, Safari revoca la suscripción.
• Si el aviso consta como entregado y no lo ves, revisa Concentración y el estilo de alerta en los ajustes de macOS.

Versiones compatibles y requisitos

Web push llegó al Mac con Safari 16.1 en macOS 13 Ventura, en octubre de 2022; en macOS anteriores Safari no lo ofrece, aunque el navegador esté actualizado. Usa el estándar, así que no necesitas una integración aparte para Safari ni unirte al Apple Developer Program, como confirma WebKit en Meet Web Push. Los tutoriales que hablan de «Website Push ID» y certificados describen el sistema antiguo de Safari, que una web nueva no necesita.

A diferencia del iPhone, donde primero hay que añadir la web a la pantalla de inicio (lo contamos en web push en iPhone), en el Mac no hay que instalar nada: la persona se suscribe desde una pestaña normal. Si además la añade al Dock (macOS 14 Sonoma o posterior), esa web app tiene su propio permiso, que se acepta dentro de la web app.

Con castly no hay nada específico de Safari que configurar: el mismo SDK y el mismo service worker de una línea, importScripts('https://castly.sh/sdk/v1/sw.js') en /castly-sw.js, sirven para todos los navegadores.

El permiso, solo desde un clic

Safari solo deja pedir permiso de notificaciones como respuesta a un gesto de la persona, como pulsar un botón. Y hay un matiz que rompe muchas integraciones: la suscripción tiene que empezar directamente en el manejador del clic. Si antes esperas a otra cosa, como cargar preferencias de tu servidor, Safari puede dejar de relacionar la petición con el clic y rechazarla.

// Bien: lo primero que ocurre tras el clic es la suscripción
boton.addEventListener('click', async () => {
  await Castly.subscribe({ userId: usuario.id });
  const prefs = await fetch('/api/preferencias').then((r) => r.json());
  await Castly.setTags(prefs);
});

// Mal: la espera previa puede romper la relación con el gesto
boton.addEventListener('click', async () => {
  const prefs = await fetch('/api/preferencias').then((r) => r.json());
  await Castly.subscribe({ tags: prefs });
});

El aviso de suscripción que configuras en el panel ya funciona así: muestra tu mensaje y pide el permiso cuando la persona pulsa su botón. Ten en cuenta que en Safari › Ajustes › Sitios web › Notificaciones la persona puede impedir que los sitios web pidan permiso; en ese caso no verá tu petición.

Cómo se ven las notificaciones en el Mac

Safari entrega los avisos al Centro de notificaciones de macOS: aparecen como tira o alerta en una esquina de la pantalla, quedan guardados en el Centro de notificaciones y, al pulsarlos, abren la URL del aviso. Pero ignora buena parte de las opciones que otros navegadores sí muestran:

Diseña cada aviso para que se entienda solo con título, texto y enlace: si envías image con la API, Chrome la mostrará y Safari no. Y como tag no reemplaza nada, tres actualizaciones del mismo pedido son tres notificaciones en el Mac: envía solo los cambios que importan.

Ajustes de macOS que pueden ocultarlas

Que un aviso llegue al Mac no garantiza que la persona lo vea. macOS trata cada web con permiso como una app más: en Ajustes del Sistema › Notificaciones aparece en la lista de apps, y allí se decide el estilo (ninguno, tiras o alertas), si se guarda en el Centro de notificaciones y si suena.

• Estilo «Ninguno». El aviso no aparece en pantalla, aunque puede quedar en el Centro de notificaciones.
• Concentración. Mientras un modo de Concentración está activo, incluido No molestar, los avisos de las apps no permitidas se silencian y esperan en el Centro de notificaciones. Puede estar programado, por ejemplo, por la noche o en horario de trabajo.
• Pantalla compartida. Al compartir o duplicar la pantalla, macOS oculta las notificaciones salvo que se permita en esos mismos ajustes.
• Permiso por sitio. En Safari › Ajustes › Sitios web › Notificaciones cada web aparece con Permitir o Denegar.

Dos lecturas para tu producto: para lo crítico, ofrece también otro canal, como el email. Y cuando alguien diga «no me llegan», mira primero si el panel marca ese aviso como entregado en su dispositivo: si es así, la causa está en estos ajustes, no en el envío.

Cada push tiene que mostrar una notificación

Safari no admite push invisibles. Al suscribirse, la web promete que cada mensaje terminará en una notificación visible, y si el service worker recibe uno y no la muestra, Safari revoca la suscripción. Dos ideas que parecen razonables y fallan en Safari: no mostrar el aviso si la persona ya tiene tu web abierta, y usar push para sincronizar datos en segundo plano.

El service worker de castly muestra una notificación por cada push enviada desde tu proyecto, así que esta regla está cubierta. Si añades su línea a un service worker propio que gestiona otras push, esas también deben terminar en algo visible. Una suscripción revocada así aparece después como suscripción caducada.

Declarative Web Push

Desde Safari 18.5, que también se instala en Sonoma y Ventura, Safari entiende Declarative Web Push: el propio mensaje describe la notificación y el navegador la muestra sin ejecutar JavaScript, con lo que siempre hay algo visible y se ahorra batería. Los navegadores que no lo entienden pasan el mensaje al service worker, pero Chrome y Firefox aún no lo admiten por completo: hoy es una mejora de Safari, no un sustituto del service worker. Los detalles están en Meet Declarative Web Push.

Cómo probarlo en tu Mac

1. Suscríbete como un usuario. Abre tu web con HTTPS en Safari y pulsa tu botón de activar avisos.
2. Usa dispositivos de prueba. Desde el Playground del panel puedes suscribir tu navegador como dispositivo de prueba y enviarle una push sin molestar a nadie más, o hacerlo por API con { "type": "test" }.
3. Sigue el recorrido. En el detalle de la notificación verás el dispositivo pasar por enviada, entregada y clic.
4. Comprueba el clic y repite la primera vez. Confirma que el aviso abre la página correcta, y quita tu web en Safari › Ajustes › Sitios web › Notificaciones para volver a ver la petición de permiso.
5. Prueba el Dock aparte. Si tus usuarios añaden la web al Dock, repite el recorrido dentro de la web app, que tiene su propio permiso.

Si todavía no tienes la integración, la guía rápida te lleva hasta la primera push en unos minutos.

Preguntas frecuentes

¿Necesito una cuenta de Apple Developer para enviar push a Safari?

No. Desde Safari 16.1, Safari usa el Web Push estándar, igual que Chrome y Firefox, y el antiguo sistema con Website Push ID y certificados no hace falta para webs nuevas.

¿Por qué Safari dejó de recibir mis notificaciones?

Las causas más comunes son que la persona retiró el permiso, que borró los datos del sitio o que una push llegó sin mostrar notificación y Safari revocó la suscripción. En esos casos el suscriptor suele aparecer como caducado tras el siguiente envío.

¿Se ven las imágenes y los botones de mis notificaciones en Safari?

No. Safari para macOS no muestra image ni actions, así que el aviso tiene que entenderse con el título y el texto. Las imágenes siguen apareciendo en los navegadores que las admiten.

¿Qué versión de macOS hace falta?

macOS 13 Ventura o posterior, con Safari 16.1 o superior. Para Declarative Web Push hace falta Safari 18.5 o posterior.