Skip to content

Conversation

@wapacro
Copy link

@wapacro wapacro commented Nov 13, 2025

Hi there 👋

Apple proposed to amend the existing specifications around Web Push with a model for Declarative Web Push notifications and already implemented this for Safari 18.4 on macOS, iOS and iPadOS. From their blog:

Declarative Web Push allows web developers to request a Web Push subscription and display user visible notifications without requiring an installed service worker. Service worker JavaScript can optionally change the contents of an incoming notification. Unlike with original Web Push, there is no penalty for service workers failing to display a notification; the declarative push message itself is used as a fallback in case the optional JavaScript processing step fails.

Declarative Web Push is more energy efficient and more private by design. It is easier for you, the web developer to use. And it’s backwards compatible with existing Web Push notifications.

W3C is actively working on getting this standardized - the core specs are already merged at w3c/push-api#385, although it's still a working document.

This pull requests introduces the ability to (optionally) send Declarative Web Push messages with Laravel. Since these are by design backwards compatible, they can already be used even when targeting browsers other than Safari. There are also no breaking changes for existing generic Web Push deployments.

References

@joostdebruijn
Copy link
Collaborator

Hi @wapacro! Thanks for this PR. I was not aware of Declarative Web Push, so the provided resources were very useful. As I understand, Declarative Web Push requires a pre-defined format of the push message and this class is providing that. It's backwards compatible in a way that non-supporting clients can have a Javascript-handler that uses this predefined format. Am I right?

I'm willing to merge this, however as the spec is still evolving I'm not sure if this is the right time?

* @var array<string, mixed>
*/
protected array $options = [
'contentType' => 'application/json',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the documentation I saw application/notification+json, but not sure if this is now a requirement?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this comment, the absence of the content type header in the parser spec draft and that there's been no activity on the RFC 8030 side of things for years I assume the specific header will no longer be taken into account. This can obviously change in the future, but for now application/json is a safe bet that can easily be changed if needed imho. I also tested this with Safari, and it works flawlessly with the regular JSON content type.

@wapacro
Copy link
Author

wapacro commented Nov 16, 2025

Declarative Web Push requires a pre-defined format of the push message and this class is providing that. It's backwards compatible in a way that non-supporting clients can have a Javascript-handler that uses this predefined format.

Yes, that's right. For non-supporting clients it's just a regular invocation of the service worker's push event, and can be handled as usual. For supporting clients, the service worker becomes optional, which improves battery life and reduces complexity.

You are right in that the spec is not final. But looking at the W3C repository it looks to me like the format itself is mostly a done deal and already merged; the only open discussions are more on badging and the implementation from browser perspective itself (like which APIs to expose where).

And since there is already a real-life use case with Safari on iPhone, iPad and Mac computers today, I'd argue that by merging it now some apps can already benefit from the advantages of Declarative Push (while staying fully backwards compatible). Let me know what you think 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants