iOS 17 终于让我们可以通过 Web Push API 使用推送通知了。对于开发人员来说，这比通知 API 需要做更多的工作，而通知 API 只能在 MacOS 上运行。 Apple 继续通过不实现 BeforeInstallPromptEvent 来给最终用户带来困难——您必须引导用户在您的网站上手动查找“添加到主屏幕”。然后用户必须从主屏幕图标启动您的网站。然后/然后/他们最终可以接收推送通知——您的服务器使用“订阅”发送到 Apple 的服务器，该订阅是由 Safari 和 Apple 在用户会话早期的某个时间生成的，并移交给您的服务器（通常使用 XmlHTTPRequest POST有某种味道）。
太棒了，我一切正常，并在此过程中了解了 VAPID 密钥和其他内容。并找到了一种方法来将每个用户、每个浏览器、每个设备的订阅保存在服务器上的数据库中，这样它们就不必不断地从浏览器客户端重新生成或重新发送。万岁！徽章也有效（除了 Apple 没有遵循 W3C 规范，并且你的徽章/有/里面有一个数字 - 即使你只是想告诉用户轮到他们做某事而不是有多少新消息他们有——但没有声音，没有触觉，没有……）。
但是，现在我注意到我无法再让旧的通知 API 在 MacOS 上的 Safari 中工作！
我尝试在 MacOS 上关闭 Safari 的新 Web Push API。我尝试从主 JS 客户端发送通知 - new Notification() - 以及通过服务工作者发送通知 - Registration.showNotification() - 哦，我已经尝试了一整天了。我五点起床，现在已经快到鸡尾酒时间了。为了我们美丽的 PNW 夏天，我大部分时间都放下了我的项目，所以我什至不确定/何时/旧界面停止工作。或者，如果我忽略了我为 iOS 上的 Web Push 新世界所做的一些事情。或者也许我们现在必须在 MacOS Safari 上使用 Web Push，而 Apple 忘了告诉我（不过，说真的，当他们并不真正希望你使用某些东西时，他们提供的帮助或文档很少）。
有人请帮助我。我肯定错过了什么。几个月前它使用相同的代码工作了。
蒂姆·库克，我希望你很高兴，每个人都会继续前往 App Store 购买你的“本土”产品，你可以从中赚取巨额利润 - 我的意思是，优先考虑这一点，因为围墙花园可以留住你的客户安全；）如果您不开始通过对开发人员更好而不是扼杀变革来对用户更好，欧盟可能会为您做到这一点。
好吧，好吧……猜猜我发布这篇文章后几个小时内发生了什么？我将 macOS 从 13.something 升级到 14.0。突然，推送通知又开始工作了！我很确定我使用的不是 Safari 的测试版或技术预览版。如果您不更新操作系统，为什么他们会以一种会破坏功能的方式更新浏览器？只需保持浏览器更新，直到操作系统准备好即可。希望这可以拯救某人我浪费的一天......