iOS 16.4+ 才支持 WKWebView 中 navigator.share(),需配置 WKWebViewConfiguration 并确保 HTTPS、用户手势同步触发;否则应通过原生桥接调用 UIActivityViewController 实现可靠分享。
iOS 原生 App 无法直接调用 HTML5 页面里的 share() 或 navigator.share(),因为该 API 要求页面运行在安全上下文(HTTPS + 用户手势触发),且 WKWebView 默认禁用此功能——即使你手动注入 JS,也会遇到 Navigator.share is not supported 或 NotAllowedError。
这是最常见现象,本质是 WKWebView 没启用 Web Share API。系统级开关由 WKWebViewConfiguration 控制,需在创建 WebView 时显式开启:
configuration.preferences.javaScriptCanOpenWindowsAutomatically = true(非必需,但常被误配)configuration.usesWebProcessPool = true(确保共享进程池,部分 iOS 版本下影响 API 可用性)
navigator.share() 在 WKWebView 中启用,且必须设置 configuration.allowsInlineMediaPlayback = true(某些场景下触发权限链)click、touchend)同步触发,不能异步延迟(如 setTimeout)典型表现是 JS 无报错、Promise 既不 resolve 也不 reject,实际是系统拒绝了请求。原因包括:
document.hasFocus() === false),比如 WebView 被遮盖或处于后台shareData 字段超限:iOS 对 text 长度限制较严(实测超过 2000 字符可能静默丢弃),url 必须是绝对 URL(https:// 开头),files 完全不支持dispatch_async(dispatch_get_main_queue(), ^{ ... })
绕过 HTML5 Share API 的不稳定,推荐用 JS 与原生通信触发真实分享流程:
window.webkit.messageHandlers.shareHandler.postMessage({title: "...", url: "..."})
shareHandler,收到后构造 UIActivityViewController,传入 [title, url] 作为 activityItems
UIActivityTypePostToWeibo 等已废弃,应优先使用通用类型(UIActivityTypeShareSheet)并依赖系统自动匹配已安装 Appfetch() 下载为 Blob,再通过 WKWebView 的 evaluateJavaScript 把图片 URL 传给原生,由原生下载保存到临时目录再传入 activityItems它们底层仍是调用原生分享接口,但会引入额外权限(如相册、联系人)、App Store 审核风险(尤其收集 IDFA 或过度追踪),且对 WKWebView 的 JS 注入逻辑复杂。如果你的分享需求只是文本+链接,纯原生桥接更轻量、可控、无隐私争议。唯一代价是:微信朋友圈不支持跳转外链,只能发纯文本或带缩略图的卡片——这和 navigator.share() 行为一致,不是桥接导致的缺陷。
真正卡住多数人的点,其实是 iOS 版本碎片化:iOS 15.0–16.3 的 WKWebView 根本不识别 navigator.share,哪怕配置全开;而 16.4+ 又要求页面必须由用户手势直接触发,中间夹一层 Promise 或 await 就失效。别花时间 patch JS,老老实实走原生桥接最稳。