Establish current Apple PWA push capabilities and constraints #3

New issue

Closed

opened 2026-10-20 21:29:32 +00:00 by phg · 1 comment

phg commented

2026-10-20 21:29:32 +00:00

Owner

Part of #1

Question

What can prevouch reliably offer as optional PWA push notifications on current Apple platforms, and what UX and implementation constraints follow?

Research current Apple/WebKit primary documentation, including newer declarative Web Push behavior where applicable, installed versus browser contexts, OS/browser version requirements, permission gesture and installation requirements, service workers, delivery limits, subscription lifecycle, and standards/VAPID/server requirements. Compare the ordinary standards-based path with Apple-specific developments and identify fallbacks and unsupported states for the prototype. Distinguish notification delivery from reliable proof that a member received or used a voucher.

Record source dates, supported versions, and the date checked; do not call an old announcement the latest implementation without checking newer official material. Resolve with a sourced Markdown note on a research branch and a resolution comment. Leave notification policy and stack selection to their decision tickets.

Part of #1 ## Question What can prevouch reliably offer as optional PWA push notifications on current Apple platforms, and what UX and implementation constraints follow? Research current Apple/WebKit primary documentation, including newer declarative Web Push behavior where applicable, installed versus browser contexts, OS/browser version requirements, permission gesture and installation requirements, service workers, delivery limits, subscription lifecycle, and standards/VAPID/server requirements. Compare the ordinary standards-based path with Apple-specific developments and identify fallbacks and unsupported states for the prototype. Distinguish notification delivery from reliable proof that a member received or used a voucher. Record source dates, supported versions, and the date checked; do not call an old announcement the latest implementation without checking newer official material. Resolve with a sourced Markdown note on a research branch and a resolution comment. Leave notification policy and stack selection to their decision tickets.

phg added the

wayfinder:research

ready-for-agent

labels

2026-10-20 21:29:33 +00:00

phg added a new dependency

2026-10-20 21:29:44 +00:00

#9 Define delivery addresses, email templates, and notification preferences

phg referenced this issue

2026-10-20 21:29:45 +00:00

Plan prevouch: specification and four-design prototype #1

phg self-assigned this

2026-10-20 21:29:46 +00:00

phg commented

2026-10-20 21:37:10 +00:00

Author

Owner

Resolution: the research question is sufficiently answered from Apple/WebKit and W3C/IETF primary sources, checked 2026-10-20.

Current official stable releases are Safari 27.0 and iOS/iPadOS/macOS 27.0.1. The note distinguishes those from feature minimums: mobile Home Screen push in 16.4, Declarative Web Push in iOS/iPadOS 18.4 and macOS Safari 18.5, the iOS/iPadOS 26 installation change, and Safari 26.2's mutable-payload correction. Ordinary iPhone/iPad Safari tabs remain outside documented push support; macOS Safari websites can subscribe without installation.

Declarative Web Push permits subscriptions without a service worker and provides a visible fallback if optional worker processing fails. Permission still requires user interaction. VAPID, encrypted Web Push transport, subscription reconciliation, delivery limits and prototype states are documented. Push-service acceptance is not proof of device delivery, human reading, email receipt or voucher redemption.

Caveats: documentation research, not device testing. Subscription-change event evidence is dated; OS 27 lifecycle, reinstall and navigation behavior need later integration tests. Notification triggers, content, email fallback policy, device routing and stack selection remain for their decision tickets. No product policy or implementation was changed. The parent will update the canonical map.

Resolution: the research question is sufficiently answered from Apple/WebKit and W3C/IETF primary sources, checked **2026-10-20**. - [Research note at commit 9fe4a418a0d3baca0530e4ff8cb41615e48eca6b](https://git.s1q.dev/MISChaufen/prevouch/src/commit/9fe4a418a0d3baca0530e4ff8cb41615e48eca6b/docs/research/apple-web-push.md) - [Published research/apple-web-push branch](https://git.s1q.dev/MISChaufen/prevouch/src/branch/research/apple-web-push) Current official stable releases are Safari 27.0 and iOS/iPadOS/macOS 27.0.1. The note distinguishes those from feature minimums: mobile Home Screen push in 16.4, Declarative Web Push in iOS/iPadOS 18.4 and macOS Safari 18.5, the iOS/iPadOS 26 installation change, and Safari 26.2's mutable-payload correction. Ordinary iPhone/iPad Safari tabs remain outside documented push support; macOS Safari websites can subscribe without installation. Declarative Web Push permits subscriptions without a service worker and provides a visible fallback if optional worker processing fails. Permission still requires user interaction. VAPID, encrypted Web Push transport, subscription reconciliation, delivery limits and prototype states are documented. Push-service acceptance is not proof of device delivery, human reading, email receipt or voucher redemption. Caveats: documentation research, not device testing. Subscription-change event evidence is dated; OS 27 lifecycle, reinstall and navigation behavior need later integration tests. Notification triggers, content, email fallback policy, device routing and stack selection remain for their decision tickets. No product policy or implementation was changed. The parent will update the canonical map.

phg closed this issue

2026-10-20 21:37:26 +00:00