本文详解如何在 iOS 上通过 WebKit 消息通道向原生层发起推送权限请求，解决 PWA 被添加到主屏幕后无法触发系统通知弹窗的问题。核心在于绕过 Safari 的 Web Push 限制，利用 WKWebView 提供的 messageHandlers 主动调用原生能力。
本文详解如何在 ios 上通过 webkit 消息通道向原生层发起推送权限请求，解决 pwa 被添加到主屏幕后无法触发系统通知弹窗的问题。核心在于绕过 safari 的 web push 限制，利用 wkwebview 提供的 `messagehandlers` 主动调用原生能力。
在 iOS 平台上，PWA（Progressive Web App）即使已“添加到主屏幕”并以全屏模式运行，其通知行为仍受严格限制：标准的 Notification.requestPermission() 在 iOS Safari 及 PWA 环境中完全无效，不会弹出系统授权弹窗。这是因为 Apple 尚未支持 Web Push API（如 Service Worker + PushManager），而是要求所有通知必须经由原生层（即 WKWebView 容器）桥接处理。
因此，正确路径不是依赖 Web 标准 API，而是与原生 iOS 应用协同——前提是你的 PWA 是通过 Xcode 打包、使用 WKWebView 加载，并已启用 Push Notifications 功能（在 Apple Developer Account 中配置证书与 entitlements，且 App ID 开启「Push Notifications」服务）。
关键实现逻辑如下：
- 检测原生桥接能力：检查 window.webkit.messageHandlers 是否存在且暴露了指定 handler（如 'push-permission-request'）；
- 主动触发原生权限请求：通过 postMessage 向原生端发送指令，由 Swift/Objective-C 代码调用 UNUserNotificationCenter.requestAuthorization；
- 避免误用 Web API：切勿调用 Notification.requestPermission()，它在 iOS PWA 中静默失败，无任何提示。
✅ 正确的 JavaScript 实现示例：
// 检测是否运行在支持消息桥接的 iOS 原生容器中
if (
window.webkit &&
window.webkit.messageHandlers &&
window.webkit.messageHandlers['push-permission-request']
) {
// 标记为具备 iOS 推送能力
(window as any).iOSPushCapability = true;
}
// 触发原生层发起系统通知授权请求
if ((window as any).iOSPushCapability) {
window.webkit.messageHandlers['push-permission-request'].postMessage('push-permission-request');
}⚠️ 注意事项：
- 此方案仅适用于通过 Xcode 构建、嵌入 WKWebView 的原生壳应用（如使用 Capacitor、Cordova 或自研容器），不适用于纯 Safari 浏览器或未集成原生桥接的 PWA；
- 原生端需在 WKWebViewConfiguration 中注册对应 messageHandlerName，并在收到消息后调用 UNUserNotificationCenter.current().requestAuthorization；
- 必须确保 App 已配置有效的 APNs 证书与推送 entitlement，否则即使授权成功，也无法接收远程通知；
- 用户首次调用后，系统将显示标准 iOS 授权弹窗（如题图所示），授权状态可通过原生回调同步回 Web 层。
总结：iOS PWA 的通知不是“网页功能”，而是“原生能力外溢”。开发者需放弃纯前端思维，转向混合架构设计——Web 层负责触发与展示，原生层负责系统交互与权限管理。唯有如此，才能真正打通从 PWA 到 iOS 系统通知的完整链路。
